Script length restriction for 64 bit

[WhoCanDo]

I've nearly finished writing a macro and now VW tells me I've exceeded my 32000 character length.

I'm using VW2014 and I will upgrade to VW2015 64bit if someone can confirm that the 64bit version will allow me to exceed the 32000 character length.

If not then does anyone have any tricks to overcome the 32000 character limit?

Does this limit include just spaces or can I change some leading format spaces to tabs etc.?

[C. Andrew Dunning]

I've never seen a character limit, but the way to manage longer scripts is to use "Includes."

Let's say your macro/script is called "WonderMacro."

Copy the entire contents of the script to a text file called "WonderMacro.px," stored in your "Plug-Ins" folder. (That folder should already have a file called "WonderMacro.vsm.") Then, in the Script Editor (from where you copied your code) enter "{$Include WonderScript.px}." When you restart VW your script should be able to be run.

Make sense??

[WhoCanDo]

Just a little more help please. Is this all I put in the script editor?

{$Include WonderScript.px}

or is it

procudure ...;

{$Include WonderScript.px}

begin

end;

run (...);

or what?

Thanks

[WhoCanDo]

OK. Got it...

procedure this;

var

{$Include filename_with_path}

begin

end;

run (this);

and then use Notepad or other text editor to edit the filename.

Thanks

[C. Andrew Dunning]

Actually, if the general syntax of what is in "WonderScript.px" is something along the lines of below, you only would need "{$Include WonderScript.px}" in the Script Editor:

PROCEDURE Scriptarino;

VAR

(Variable definitions)

BEGIN

(Script Body)

END;

Run (Scriptarino);

Essentially, "{$Include WonderScript.px}" means that whatever is in that px file goes here. You can even use "includes" within your main px to reference multiple px files in the same way - say, to reference a Procedure or Function common to multiple scripts.

[Miguel Barrera]

It seems odd that you would have that limitation on a windows machine. My largest plug-in is 272 kb (= 272,000 char) and is running from a single file.

I had this problem about 8 years ago but it seems it got fixed on the Windows side around that time because all the newer plug-ins I have created since then are larger than 32 kb and running without problems.

[WhoCanDo]

There is definitely a limit related to 32bit.

I finished my script using $Includes but I'm not happy because I can't make the $Include files secure and sharing the $Include files across the networks and also making them transportable is a nightmare.

When I add all the code to the internal script editor and then "OK", I get the message "The Script contains 79670 characters. 47669 of which will be lost. Do you wish to continue? The Script Editor can not save a Script with more that 32001 characters. etc."

I would have thought that VW would be 64bit by now.

[Matt Panzer]

If you're referring to locking plug-ins. Using a ".px" extension for the include files tells VW to add them to the locked plug-in file. This means the locked plug-in files will not require the ".px" files for distribution. Just be sure to keep an unlocked copy of the plug-in file for future development.

To be honest, I rarely ever develop scripts in the Plug-in editor and much prefer BBEdit or Text Wrangler (on the Mac) for coding. Most of my plug-ins simply point to one include file for the main script. That main script usually points to several more includes.

As for other problem you see with includes, can you explain them?

[WhoCanDo]

I'm probably behind the times here but I have never used $Include until this instance when my script got too large and it was suggested as a solution.

Normally I write the macro scripts, not as plugins, and lock them within the stationary sheet so that the drawing is a single entity and is transportable throughout the office and to other sites.

In this case the text files are on our server and accessible by the vectorscript localy. They can't be locked and if I send my stationary to our out-of-country site then they have to have the same $Include path for the macro to work.

Do you have an alternative setup suggestion?

[Matt Panzer]

I see. So you're using scripts on a script palette. Script vs plug-ins (menu commands, tools, and objects) both have their advantages. Having the script stay with the document (document specific) certainly is an advantage of not having to install plug-ins, but it also means that updated scripts won't be available in older documents unless you import them in. Since plug-ins are application specific, they are immediately available to all documents (new and old). This means updates to the plug-ins only need to be installed once (to the application) rather than importing to each document. Then there's the added advantage of assigning keyboard shortcuts to the tools and commands in the workspace editor.

That all said, I think your biggest need is to have the scripts stay with the document so they're available to anyone you send the file to. In that case, I certainly see your point and understand the challenge. Unfortunately, I cannot think of anything except (the obvious) trimming down your code as compact as possible. You asked about replacing space characters with tabs in your original message. If you're replacing multiple spaces with each tab then that should help. You could also copy the script to a decent text editor and use grep to strip out tabs, comments, extra lines, etc. This can help to considerably reduce the size. Obviously, it will be harder to read and edit the code, so make sure to keep the original for editing. You could use a script with the include file while developing the code, then trim a copy of the file down to paste into another script for distribution.

Unfortunately, trimming the script down will most likely be a short term solution and the problem may rise every time you want to edit the script. If any better ideas come to mind, I'll let you know.