Vectorworks, Inc Employee Vlado Posted October 11, 2010 Vectorworks, Inc Employee Share Posted October 11, 2010 Hey, how many of you would be interested in switching to C#, VisualBasic, Python, Java, F# or what ever language there is these days? For more complex projects for example? Thanks, Vlado Quote Link to comment
Pat Stanford Posted October 11, 2010 Share Posted October 11, 2010 I am perfectly happy with VS. If you want to add another language fine, but don't break all of the work that has been done over the years. Quote Link to comment
Guest Mark Flamer Posted October 11, 2010 Share Posted October 11, 2010 Vlado, I would jump for joy if I could develop in C# for VectorWorks! A real OO language! Please! Please! Quote Link to comment
Vectorworks, Inc Employee Matt Panzer Posted October 11, 2010 Vectorworks, Inc Employee Share Posted October 11, 2010 Hi Vlado, While I'm very comfortable with VS, I'm always open to other options. Especially if it means more power, speed and flexibility. I'm assuming your proposing something that would work similar to VS and not the SDK (with all it's overhead)? If this were done, what would happen to VS and all the existing VS plug-ins? If it is eventually done away with, I'd worry that many developers may not be able to afford the time to port them over. Matt Quote Link to comment
Vectorworks, Inc Employee Vlado Posted October 11, 2010 Author Vectorworks, Inc Employee Share Posted October 11, 2010 I'm not thinking of breaking or removing VectorScript. My thoughts are more for big project VS can be very clumsy. So, would a VS developer be inclined to switch in that case? I saw some people are already thinking SDK, but hesitate due to the complexity associated with C++. Quote Link to comment
Assembly Posted October 11, 2010 Share Posted October 11, 2010 Please do not replace VS. Quote Link to comment
maarten. Posted October 12, 2010 Share Posted October 12, 2010 Ow, yes please!!! The last couple of weeks, i bumped a lot on the boundaries of VS so an other language with more options but less hard to learn then C++ sounds very good to me . But again like the rest already mentioned, don't replace or remove VS. Quote Link to comment
Vectorworks, Inc Employee Matt Panzer Posted October 12, 2010 Vectorworks, Inc Employee Share Posted October 12, 2010 In that case Vlado, I'm all for it BIG TIME! As you know, I was involved in a fairly complex VS project and it was determined that the final product would require the SDK. We continued working on a prototype in VS, but it was an extremely frustrating task due to the limitations of VS. The big question is, what language would you use so I can start studying. :-) Quote Link to comment
Dieter @ DWorks Posted October 12, 2010 Share Posted October 12, 2010 I think the solution is to let NV change the sdk, so that we can use any of the .net languages. Quote Link to comment
Ryan McCuaig Posted October 13, 2010 Share Posted October 13, 2010 I would support Ruby or Python as the next generation of Vectorscript. C#, Java, or C-like, strongly-typed, finicky languages should be confined to the SDK. Most of what I've wanted to do can be done in Vectorscript; I just find the syntax (especially loops) cumbersome compared to Ruby, the inconsistent API syntax can be trying, and the need for variable declarations no longer seems necessary. In principle, there's plenty of room for two environments: 1. the hand-holding, garbage-collected, weakly-typed, get-it-done environment (henceforth known to me as VectorRuby), and 2) the chainsaw that is the SDK. I don't really care if it's C# (or Mono for us Mac people), but it seems to me that the SDK should simply be a thin bundle wrapper to provide a code entry point, plus a C library and a bunch of header files that can be called from whatever environment people would prefer to use. Quote Link to comment
Vectorworks, Inc Employee Vlado Posted October 15, 2010 Author Vectorworks, Inc Employee Share Posted October 15, 2010 Let me continue with the questioning: what would be the worst thing in VectorSript? In other words would would be the thing that you would like to see fixed first? Quote Link to comment
Dieter @ DWorks Posted October 15, 2010 Share Posted October 15, 2010 Let me continue with the questioning: what would be the worst thing in VectorSript? In other words would would be the thing that you would like to see fixed first? The editor! Quote Link to comment
Vectorworks, Inc Employee Matt Panzer Posted October 15, 2010 Vectorworks, Inc Employee Share Posted October 15, 2010 Vlado, The first thing that comes to mind is the PIO interface being stuck to 2D. With all the 3D advancements in VW, the PIOs are severely lacking here. For starters, instead of a rectangular PIO, why not a rectangular prism PIO 3D control points allowing the user to reshape the control points in any 3D view. But you probably already knew I was going to say that. ;-) I realize I may be straying from you intended question since PIOs are merely a container for VS the create stuff. Quote Link to comment
Miguel Barrera Posted October 15, 2010 Share Posted October 15, 2010 Vlado, We need a visual dialog editor as most modern programming packages. Resources such as images should be stored with the script rather than linked to an external file. It is a pain to build a dialog through command lines and cannot even use the debugger to sort out errors because it crashes VW. The debugger also needs to be fixed as it crashes if you set more than one stop point or even one point inside a loop which crashes VW on the second iteration. Some controls do not work either. I was trying to use a tree control in VW 2008 and although the tree did display correctly, VS would not recognize the control in the event loop. So I switched to 2010 and finally was able to get the click event but then the function to retrieve the text did not work. The only alternative that worked was to save the text in a global string array. Quote Link to comment
Pat Stanford Posted October 15, 2010 Share Posted October 15, 2010 The first this I would like is better dialog box handling. Currently I have some scripts where 80% of the code is the dialog boxes trying to get the information needed to run the script. There needs to be a better way. Whether that is a robust dialog builder or a simplification of VS to make it easier, that is one of the biggest drawbacks to making nice looking User Interfaces with VS. Second would be cross file scripting. It would be great to be able to launch a script and have it effect other files, but even the ability to run a script without having to import the resource first would be extremely useful. Third would be hooks to automatically run scripts. Run a script when the print command is called before printing. Run a script before a save. Run a script when the autosave starts/stops. Run a script when a file is opened. Run a script when a file is closed. There are probably a lot more. With these types of hooks, you could much more easily automate a lot of the repetitive drawing/document control functions. Quote Link to comment
maarten. Posted October 16, 2010 Share Posted October 16, 2010 the editor:A simple find-replace is really the minimum. In some texteditors you can select one word and it will be highlighted in the rest of the text. That way you can see real quickly where in the script (for example) a variable is used. You should be able to turn this option off in the preferences. auto sugestions while typing. When you type 3 letters, you should get an suggestion of procedures and functions that start with those 3 letters. You should be able to turn this option off in the preferences. List of variables: when you press (for example) alt+spacebar, you get a list of all the variables used in that Function/Procedure. When you're in a subProcedure/subFunction, you'll also see the vars of the Procedure/Function where the active Function/Procedure is placed in. You should be able to turn this option off in the preferences. Same as the last one, but then with the Paramters used in the Pio. You should be able to turn this option off in the preferences. [*]the debugger: It shouldn't crash VW on large scripts (Windows). It shouldn't crash VW on dialogs (Windows & Mac). It shouldn't be called with {$debug} but with a button in the editor (like the compile button). Quote Link to comment
J. Miller Posted October 16, 2010 Share Posted October 16, 2010 I completely agree with Pat & Maarten on the above topics two posts. There is a large amount of code to get a dialog box to behave properly. A more robust editor would be great too. I have some VB experience and the editor in that language is very easy to use but has a lot of the features Maarten described. I would not suggest getting rid of vectorscript but updating the interface would be wonderful idea. Jeff Miller Quote Link to comment
maarten. Posted October 17, 2010 Share Posted October 17, 2010 (edited) Can we make some more suggestions? Dialogs: as mentioned above, i think it would be nice to have a dialog editor. I personally never worked with such an editor before but if it would work something like this, i would like it a lot :A dynamic preview of the dialog where you can drag/drop controllers in. Clicking on such a controller let you type in the values you need (strings), or some code if you want to fill it with dynamic values (a list of all classes or something like that) The ID's of the controllers should be visible, maybe transparent or something (this option can be turned of in the preferences). You should be able to give your own control ID's, but it should give a warning if the ID is already used. Right clicking on a controller gives you a little submenu where you can choose "Ad action". Here you can fill in some code or you can use a predefined editor where you can choose things like IF 'some control' is 'some value' THEN 'this control' is 'unvisible' (it could look like the Criteria dialog) to do some Dialog_Setup like Swappanes or dynamic content of the controlers. [*]Dialogs used inside the VS "package" (sorry, don't know the English word), like the Parameter Dialog, the VS Editor, VS Preferences Dialog, Dialog Editor (if they would be made of course ),... should all be able to be placed next to each other and used at the same time. A dialog should not make an other dialog unusable. (I just mean that al those dialogs should work as the VW pallets, you don't need to close them when you want to turn back to your drawing or an other pallet). [*]The Parameter Dialog: Get rid of the Edit, Add and Remove buttons. A parameter should be editable directly in this dialog, like you adjust a spreadsheet (cause it's a real pain in the *ss when you need to adjust a whole list of Parameters): Click on the "cell" to directly edit the text: Click on a pulldown to choose an other type or Standard value: Click on "Edit" to edit the content of such a parameter, you'll get a little dialog to fill in the values: [*]Compiling: more information by Warnings. When you get a warning such as "String can not exceed 255 chars", at least say in what line this happened and it would be even nicer to see what value caused this error. Same thing with a NIL handle, give the line where this happened. When an index is outside an array. Give the value that caused the error. When there's an error in a line, such as "Identifier not declared", highlight the Identifier that is not declared. Edited October 17, 2010 by maarten. Quote Link to comment
maarten. Posted October 17, 2010 Share Posted October 17, 2010 Ow, and it would be cool if you trow in some fancy colors to pimp the code like most editors do . Quote Link to comment
MullinRJ Posted October 17, 2010 Share Posted October 17, 2010 what would be the worst thing in VectorSript? In other words [what] would be the thing that you would like to see fixed first?Vlado, ???I'm having an inordinate amount of trouble getting meaningful data from objects with the standard 2D VS calls. With all the new drawing environments there needs to be an easier way to get and set object parameters to get what you want. ???This started to become a problem in VW 2008 with the introduction of the Rotated Plan View (RPV), but has escalated to a nightmare. Now with Screen Plane, Layer Plane and 3D Plane objects - in conjunction with the RPV - there isn't one call that returns consistent data in all combinations of the above. Move the User Origin and you're in for a mind altering experience. Raymond Quote Link to comment
Pat Stanford Posted October 18, 2010 Share Posted October 18, 2010 I agree with all of the above, but I think they are all (even mine) one step to high. I think the biggest thing we need is full symmetry and consistency of the functions and procedures. Symmetry: It has been a while, but why are there some things we Get about objects but not Set. A long time ago I started to make a list of all the Get and Set Profunctions/procedures, but I never finished. A quick look shows that at least some of the routines don't have a mate when I think they should. The first one to jump out at me tonight is SetCursor. There should also be a GetCursor so you can set it back to what it was before you changed it. I think there are a lot of instances like this. Consistancy: As VS has grown, the terminology used has changed without some of the older routines keeping up. Why do we have ClassNum and NumLayers? They both return effectively the same information about Layers and Classes. They should both be the same. I would recommend that for now, a new routine be added for NumClasses. It would be exactly the same as ClassNum. Then ClassNum should be deprecated to be deleted in 10 years or so. If the symmetry and consistancy were increased VS would be much easier to use. What are some of your favorite missing symmetry pairs and examples of lack of function/procedure naming consistancy. Quote Link to comment
maarten. Posted October 18, 2010 Share Posted October 18, 2010 SetDashStyleN('My Dash Style', True,num,pair1DX,pair1DY,pair2DX,pair2DY,pair3DX,...); doesn't have a GetDashStyleN Quote Link to comment
arthur&l?on Posted October 26, 2010 Share Posted October 26, 2010 Hello...nice question. The first basic thing would be allowing VS to handle jpegs in dialogs and in info palettes. To be able to manage dialogs ? la Archicad. 2 : handling buttons 3 : Syntax colouring 4 : drawing dialogs as in Visual Basic or Delphi or... 5 : Pascal is relatively nice, but some cad packages allow scripting in more than one language. Thanks Francesco Quote Link to comment
Ryan McCuaig Posted November 5, 2010 Share Posted November 5, 2010 I'd devote resources instead to the debugger, a console, and a visual dialog editor. Something along the lines of Interface Builder on the Mac would be fantastic. This is a major reason that Mac GUIs are so painless to generate. By console / interactive prompt, I mean one like AutoCAD's or Sketchup's. It's incredibly helpful for exploring and learning how VS works, without the overhead of making up a plugin. I don't think the text editor is a priority. Editors are very personal things, and NNW can't hope to keep up with the dedicated programs. All I ever do during development in the VW editor is {$INCLUDE something.vss}, work on the file in TextMate, using a Vectorscript syntax customization I've put together. When ready, I paste back into the VW text editor. So, I'd support more hooks for external editors instead, and leave the development of editor customizations to outside devs. This is work that we can do; save Vlado's time for things that we can't. +1 for Pat's suggestion about hooking scripts to events, firing eg. on print or save. Quote Link to comment
maarten. Posted November 6, 2010 Share Posted November 6, 2010 A question about the VS Editor... I hear some of you say that you don't use the VS Editor but a text editor with a VS language module. I too use Notepad++ with such a module at work and it does work great but one thing that i miss the most is a way to compile my scripts... So, is there a way to do this in one of those text editors? If so, i too would leave the VS Editor for what it is and use a text editor. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.