WhoCanDo Posted December 17, 2014 Share Posted December 17, 2014 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.? Quote Link to comment
C. Andrew Dunning Posted December 17, 2014 Share Posted December 17, 2014 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?? Quote Link to comment
WhoCanDo Posted December 17, 2014 Author Share Posted December 17, 2014 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 Quote Link to comment
WhoCanDo Posted December 17, 2014 Author Share Posted December 17, 2014 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 Quote Link to comment
C. Andrew Dunning Posted December 17, 2014 Share Posted December 17, 2014 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. Quote Link to comment
Miguel Barrera Posted December 17, 2014 Share Posted December 17, 2014 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. Quote Link to comment
WhoCanDo Posted April 8, 2015 Author Share Posted April 8, 2015 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. Quote Link to comment
Vectorworks, Inc Employee Matt Panzer Posted April 8, 2015 Vectorworks, Inc Employee Share Posted April 8, 2015 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? Quote Link to comment
WhoCanDo Posted April 9, 2015 Author Share Posted April 9, 2015 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? Quote Link to comment
Vectorworks, Inc Employee Matt Panzer Posted April 9, 2015 Vectorworks, Inc Employee Share Posted April 9, 2015 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. 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.