Jump to content


Vectorworks, Inc Employee
  • Posts

  • Joined

  • Last visited

Posts posted by Vlado

  1. Hi, sorry for the late response. I didn't get notification for this for some reason.


    Anyway, the configuration XML file should be placed next to the vso/vst/vsm file, and it should have the same name. Below, i'll give you a sample xml.


    The Tools -> Plug-ins-> Encrypt Sript menu you found will only encrypt a single text file. You need to work with the plugins, and thus you need to run the Plugin Manager.


    You can encrypt a one plugin from the Plugin Manager (as an alternative to EncryptVSPluginFilePath  call) holding Ctrl+Shirt+Alt on win or Ctrl+Option+Cmd+Shift+CapsLock on mac and double click on a plugin. It's rather obscure way, and we have plants to make it more stream lined. Maybe this would be easier for your case. (I though this was documented in F1 help, but i couldn't find it)




    A sample XML file:


    <?xml version="1.0" encoding="UTF-8" standalone="no"?><!-- This file defines how the corresponding script plug-in should be packaged--><Plugin>

  2. Hi Eric, 


    well, this is a giant file.It's awesome to see you pushing the limits.


    The XML property i told you about just removes the asynchronous calculations, which in this case is not useful.


    I'll add a new property to turn off the auto-calculations (SP2 hopefully) until we find a solution of this. This way, it will not interfere with your work but you'll have to do manual recalculate when you need to see updated values.




    • Like 1
  3. Hi Eric,


    You can disable the automated calculations and then you can use the menu command to recalculate.


    However, i'm interested to see why is it cumbersome to you? Can you send me a test file, or at least a video of the problem? (vstanev@vectorworks.net) Thank you.


    To disable the automated calculations, open this file:



    Edit it with a text editor, and put 'false' in the 'AsyncCalculation' tag (there is 'true' at the moment there). This file should be in your app folder.





    • Like 1
  4. Hi all,

    now I see this feature was never documented properly by Vectorworks.

    The encryption (obfuscation) of Python scripts is similar to the VectorScript process. I'll make sure we make an article on developer.vectorworks.net site about that.

    Until then, here is explanation of how python encryption (obfuscation) works.

    A user develops his python vso/vst/vsm plug-in. Typically, as the samples demonstrate, the code of the plug-in just includes an external py file. This way it is much easier to develop as it allows external IDE.

    At the end of the development, the python script is a collection of py files. The encryption (obfuscation) process (run from the Plugin manager or from EncryptVSPluginFilePath call) will compile and pack up all the external pyo or pyc files (those are compiled py files) into the vso/vst/vsm file. This means that the vso/vst/vsm files can be distributed without providing any of the source files.

    More on python files here:


    And here is the trick. For VectorScript the app follows the {$include} directive when doing this, but for Python, there is no way to follow the includes and figure out what is to be included.

    So, Vectorworks would expect an xml file next to your vso/vst/vsm that is being encrypted. This file will define what files must be included.

    Note, Vectorworks 2014 has a problem where the main script text inside the vso/vst/vsm will not be modified by the process. This means that even though the plug-in is packed up, the script text is still untouched and can be seen if there is an error reported. The issue will be fixed for VW2015.

    Here is an example xml file that defines several files to be packed up when encrypting (obfuscating) the plug-in:

    Note, the name of the XML file should be the same as the VSO/VST/VSM file.







  5. Hi Ilay, you should not copy anything to 'site-packages' from the sample. Unzip the sample in your user's plug-ins folder and that should be all.

    when a vsm, vsm, or vst runs, VW adds that folder to the python search path. So, when the scripts does 'import import ui.dlgHandler' the first thing python would do is to look for a folder 'ui' next to the vsm.

  6. What a coincidence: an end user would just like to change the names of User fields in the Door tool, but that is no longer possible. Is this really progress? Methinks not.

    Well, but that's not problem of the SDK, it's a problem of the plug-in's design. But yes, I know what you mean ... VS is more user friendly :)

  7. Just informational (this is the VS forum anyway), but SDK does have much better support for popup value list, also dynamic popup value list. Also it has much easier XML API for configuration files. The SDK is OS independent, as long as you can handle two different compilers. The only drawback maybe is that it uses C++.

    You can tell I like the SDK, eh ;)

  8. Hello,

    the VWFC classes are wrappers on top of the SDK. Unfortunately, not very well documented.

    The VWObjects namespace contains objects that are designed as wrappers of MCObjectHandle. Every class has two different constructors:

    1. wrapping - the one that accepts MCObjectHandle

    2. creating - the all others (they create a new object)

    For the VWRecordObj you can just create instance like this:

    VWRecordObj rec( hRecord );

    Note that for parametric objects, it's much easier to use VWParametricObj, it directly allows you to access the parameters.

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

  • Create New...