calling another plugin and getting there results back

[Jayme McColgan]

So I need to have a VS-based plugin call a pretty extensive Python script and get the response from that script. What's the best way to do that? My first thought was making a Python based plugin and calling that tool from within the VS plugin, but I tried all the vs.CallTool() variants, but it seems you can only get a true/false that the call was successful?

 

Is there a better way to do this?  

[JBenghiat]

https://github.com/Vectorworks/developer-scripting/blob/main/Function Reference/Functions/PythonExecute.md
 

Last I checked, the described method for passing data didn’t work for encrypted scripts; you have to use the string repository (Get/SetRepStr commands). 

[Jesse Cogswell]

I think @JBenghiat has the right solution using the string repository.  Have the VS script call the Python script with CallToolByName (if it's a tool), or DoMenuTextByName (if it's a menu command).  Then have the Python script store all of the needed variables into the string repository using the Rpstr_ set functions, and then have the VS script recall the variables using the Rpstr_ get functions.  Then use the Rpstr_RemoveValue function to clear the string repository values if they are no longer needed.  The only snag you might hit is that I'm not sure whether Vectorworks will allow a script to run and complete while executing another script.  But it's certainly worth a shot.

 

Otherwise, wrapping your Python script into a PythonExecute function and just having it live inside your Vectorscript is another way.  You might even be able to get away with using Open to open the Python file, then use ReadBin with the proper encoding (probably UTF-8?) to get the full contents of the Python file and send it to PythonExecute to run it.  Don't forget to add a PythonBeginContext and PythonEndContext around any Python code inside Vectorscript.

[JBenghiat]

2 minutes ago, Jesse Cogswell said:

You might even be able to get away with using Open to open the Python file, then use ReadBin with the proper encoding (probably UTF-8?) to get the full contents of the Python file and send it to PythonExecute to run it.

 

I've never tried it, but I think the #INCLUDE directive is fairly "dumb", and may work to include the contents of a python file. You may have to work out a way to wrap it in single quotes. You also need to stick to double quotes in the python file to ensure that PythonExecute is taking a string.

[Jesse Cogswell]

I tried to $INCLUDE a Python file inside a Vectorscript file a while back and it wouldn't compile since it tried to compile the Python as if it were Vectorscipt.

 

I just did some testing with ReadBin and it should work.  The documentation for ReadBin straight sucks and doesn't tell you all of the things you need to know, if reading as a string, you need to include two additional arguments, the length of the string and the encoding.  Here is the code I used to test it, and it faithfully reproduced a Python file.  I haven't tried it with PythonExecute yet.  

 

PROCEDURE TestEncoding;

CONST

	kPath = 'Enter file path here';
	kUTF8 = 3;
	
VAR

	contents:DYNARRAY[] OF CHAR;

BEGIN
	Open(kPath);
	ReadBin(contents,65535,kUTF8);
	Close(kPath);
	
	CreateText(contents);
END;

Run(TestEncoding);

 

[Jayme McColgan]

Sadly, it's a good amount of Python code that can't really be plaintext, so I can't just open the file. Maybe I could encrypt the Python file and have VS decrypt it every time? 

 

The Python I need to check is for a license checker, which is totally easy for my Python-based plugins because I just include the "checkserial.py" in the plugin encryption process. Some of our legacy plugins are written in VS, which I don't have the time to rewrite them so I need to figure out a way for those VS-based plugins to check a license serial flow I built in Python.

 

My original idea was to bake the Python script into its own "CheckSerial" menu plug-in and have the VS plugins to call that plugin and return a true or false if the user is licensed to run my plugins. 

[Pat Stanford]

Might be a good time to learn a little about the SDK and create a VWlibrary that you could call from either VS or Python. Then you would not have to mess with going back and forth.

 

I believe @JBenghiat has created such an animal before.

 

Other than knowing (thinking???) that it is possible, I have zero idea how to actually accomplish this with the SDK.

[JBenghiat]

To keep the python workflow, you could construct checkserial as a module, so so that the PythonExecute calls would just be 'import checkserial' 'checkserial.check()'

You would want to obfuscate your python file and probably set the python script path. The python call would set a value in the string repository that your main code would check.

 

In the SDK you can indeed create your own VS and Python commands, which you can then just call from your script. That easily lets you use the same code for VS, SDK, and python plug-ins.

[Jayme McColgan]

I guess it's finally time to learn the SDK. but in the mean time. tell me more about this... 

 

On 12/4/2025 at 10:56 PM, JBenghiat said:

The python call would set a value in the string repository that your main code would check

What's the string repository? 

 

EDIT: i found all the Rpstr commands. buildign a plugin now. 

Edited December 13, 2025 by Jayme McColgan

[Jayme McColgan]

ok here's my basic scripts that seem to be working for now. let me know if I'm missing anything... 

 

Python Menu Command Plugin

 

import vs, datetime, tool_checker
def start():
    curdate = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
    checked = tool_checker.get_serials()
    vs.Rpstr_SetValueBool("oTGMlvZs6m", checked)

    vs.Message(str(f"Plugin ran at {checked}")) #only here for debugging

    return None

 

Here's the basic VS Code I wrote to check this. will integrate these lines into the VS Code at the start of the plugin.

 

PROCEDURE VS_CheckAllowed;
VAR
    allowed : BOOLEAN;
BEGIN
    DoMenuTextByName('Test Menu Plugin', 0);
    allowed := Rpstr_GetValueBool('oTGMlvZs6m', FALSE);

    IF allowed THEN
        AlrtDialog('Allowed')
    ELSE
        AlrtDialog('Not Allowed');
END;

RUN(VS_CheckAllowed);

 

[JBenghiat]

Overall this seems fine. 
 

You don’t seem to be using curdate. FWIW, the string repository clears when you quit VW, so you are guaranteed a check once per session without using a date stamp. The date could come into play if you have a time-based demo or perform a periodic update check.

 

I may be wrong, but I think for this to work, you need to have the plug-in menu in your workspace. You are ultimately better off using PythonExecute(). 
1. Set the python path to where you install your helper script, and begin a context

2. Call PythonExecute(‘import tool_check_thisone’)

3. Call PythonExecute (‘tool_check_thisone.start()’)

 

You can find tools for obsfucating Python files directly, so you don’t need to make a plug-in. 
 

If you update get_serials() to take an argument (the string repository name), you don’t even need the intermediary. 

 

[Jayme McColgan]

On 12/13/2025 at 10:45 AM, JBenghiat said:

Overall this seems fine. 
 

You don’t seem to be using curdate. FWIW, the string repository clears when you quit VW, so you are guaranteed a check once per session without using a date stamp. The date could come into play if you have a time-based demo or perform a periodic update check.

 

I may be wrong, but I think for this to work, you need to have the plug-in menu in your workspace. You are ultimately better off using PythonExecute(). 
1. Set the python path to where you install your helper script, and begin a context

2. Call PythonExecute(‘import tool_check_thisone’)

3. Call PythonExecute (‘tool_check_thisone.start()’)

 

You can find tools for obsfucating Python files directly, so you don’t need to make a plug-in. 
 

If you update get_serials() to take an argument (the string repository name), you don’t even need the intermediary. 

 

yeah i had the datetime there for debugging... forgot to delete it before sending this example. i might look into the PythonExecute() stuff at a later date but this seems to be working for now. gonna test it with some users and see if any issues come up.