Jump to content
Developer Wiki and Function Reference Links ×

VectorScriot or ...


Vlado

Recommended Posts

  • Vectorworks, Inc Employee

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

Link to comment
  • Vectorworks, Inc Employee

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++.

Link to comment
  • Vectorworks, Inc Employee

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. :-)

Link to comment

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.

Link to comment
  • Vectorworks, Inc Employee

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.

Link to comment

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.

Link to comment

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.

Link to comment

  • 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.
      ubbthreads.php?ubb=download&Number=4626&filename=selectiekopie.png
    • 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.
      ubbthreads.php?ubb=download&Number=4625&filename=autosugproc.png
    • 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.
      ubbthreads.php?ubb=download&Number=4627&filename=sugVar.png
    • 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).

Link to comment

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

Link to comment

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:

    ubbthreads.php?ubb=download&Number=4631&filename=Para%20adjust1.png

    Click on a pulldown to choose an other type or Standard value:

    ubbthreads.php?ubb=download&Number=4632&filename=Para%20adjust2.png

    Click on "Edit" to edit the content of such a parameter, you'll get a little dialog to fill in the values:

    ubbthreads.php?ubb=download&Number=4633&filename=Para%20adjust3.png

    [*]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 by maarten.
Link to comment
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

Link to comment

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.

Link to comment
  • 2 weeks later...

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

Link to comment
  • 2 weeks later...

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.

Link to comment

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.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...