Charles Chandler

Thinking that there is actually a lot that could be said on this topic, I went ahead and created a VectorLab article: http://www.vectorlab.info/index.php?title=VectorScript_Performance This way, as more information gets created, it can be added to a central article on the topic, rather than tacked onto the end of a discussion. (Some stuff just works better as articles, and not as discussions.)

Instead of using the LOC criterion, you could build an array of the objects that you need to operate on at the beginning of the script. Instead of just storing the handles, you would also store the insertion points of the PIOs. (They're PIOs that you're operating on, right?) Anyway, use GetSymLoc to find the insertion points, and store the x/y in additional elements within the TYPE structure. Then, to find an object that you want, instead of using the LOC criterion, you use the Norm function to test the distance of the object from a test point. Let me know if this doesn't make sense.

Hi Joel, "Good performance" is going to require something different in every circumstance, and without seeing the code, there's no way of knowing where the optimization opportunities might be. Nevertheless, there are some general guidelines. You're right about dynamic arrays. Re-allocating a dynamic array forces the creation of a new array of different dimensions, copying the contents of the old array into the new one, and then cleaning up the old one. If this is happening thousands of times in a script, you can see a hit because of it. So try to re-allocate as little as possible. If you know you'll need 1000 elements, allocate the array for 1200, and later, if you find you need more, add another 200 elements. Don't re-allocate the array every time you add an element. In a script that operates on PIOs in the drawing, don't reset the other objects if you don't have to. You might be doing SetRFields to poke new data in, but does that really require also calling ResetObject? (Sometimes it's just data that will appear in a worksheet somewhere, and there is actually no reason to reset the object.) Also, sometimes it makes a lot of sense to check the existing values before poking the new values in, and if the values aren't actually changing, then there's no need for a reset. You can save a lot of execution time this way. As a general rule, math is much faster (at run-time) than construct geometry (though it's a tad slower at design-time). Creating and destroying objects involves a substantial amount of overhead, as VW has to do many things to preserve the integrity of the drawing list as objects are created and destroyed. If you can do everything that you need to do within VectorScript, you won't kick off all of those routines under the hood. And if you do need to create a construct object for some reason, it's better to re-use it than to delete it and create a new one next time. Editing is cheaper than creating and destroying. SetSelect can be pretty expensive, because (last I heard) it triggers the Object Info palette code, and that is very expensive. Last time I checked, 75% of the regen time for a normal object was spent in building the OI palette for that object. If SetSelect is triggering this code, you could be spending a lot of time making the OI palette flicker, instead of getting the job done. So always use handle-based calls if they are available, rather than using SetSelect and DoMenuTextByName. ForEachObjectInList is very fast, and ForEachObject isn't bad, though you shouldn't use these more than once in a script if it can be avoided. These will step through every object (in the specified list, or in the entire drawing, respectively). Always run something like this once, to build up an array of handles, and then process the array of handles as many times as you want, rather than re-running the same search. There is more that could be said on this topic, and there are cases where ForEachObject can actually be faster than stepping through an array in VectorScript looking for a specific element. It all depends on how many objects are in the drawing, and how much data you might have to collect to support your searching. If you're really having performance problems, you might have to try it a couple different ways. You can use GetTickCount to capture the number of 60ths of a second since VW was launched. The basic strategy is simply like this: tick1 := GetTickCount; {do some stuff} tick2 := GetTickCount; {do some stuff} tick3 := GetTickCount; WriteLn('tick1: ', tick1 / 60); WriteLn('tick2: ', (tick2 - tick1) / 60); WriteLn('tick3: ', (tick3 - tick2) / 60); Don't dump your performance logging to the text file during the script operation, or you'll pick up a performance hit just because of the file i/o (which by the way is kinda slow too). HTH,

The functions with the green title bars are functions that were coded in the SDK, rather than in the VW core. This makes no difference to you, since they act the same as built-in functions when called from VectorScript. But for the people who work on the underlying code of these functions at NNA, it helps to know where to go looking for the code. The only other difference is that these functions are not documented in the standard VectorScript reference. Anyway, the SetToolByName function was implemented in 13.0.1.

Try: DoMenuTextByName('AlignLayerViews',0); Like VectorScript plug-ins, use the filename.

Try: FUNCTION SetToolByName(toolName :STRING) :BOOLEAN;

I did a plug-in for generating HTML image map code within VW. Here's the link: http://scs-inc.us/default.php?page=products&subPage=products/HTML%20Image%20Map/Default

Now would be a good time to get up off of $20 for a third-party plug-in. The "Wall Types to v12 Styles" plug-in will convert wall types created in versions 9~11 to wall styles in version 12 and above. Here's the link: http://scs-inc.us/default.php?page=products&subPage=products/wall%20types%20to%20v12%20styles/Default

If you're looking for KnowledgeBase articles in general, you might start at the VectorWiki Tips & Tricks page. All of the KB articles have been categorized, making it somewhat easier to find something on a particular topic. Here's the link: http://www.vectorwiki.org/index.php?title=Tips_and_Tricks

That's weird. Can you post some before-and-after images? I want to see the location of the linear control points, before and after it has unflipped itself.

It's there, in the Dims/Notes palette.

I entered a bug report for this.

All of that having been said, I'm now seeing Ramon's problem, and a number of other problems, for which there appears to be no work-around. The best that I could come up with is a document script that can be used to clear the preference set selection within the document. This will get you back to using the default preference set, and you'll see finishes in the Assign Room Finishes dialog. procedure main; var h :handle; begin h := GetObject('NNA_PrefSetPointer'); if h <> nil then DelObject(h); end; run(main); If you don't know how to create and run document scripts, just say so, and I'll provide more detail. Problems that remain include the fact that no matter what I do, editing finishes doesn't work -- the edits never get committed to the Room Finish Library.txt file. This file can be manually edited, with TextEdit, but not with the VW dialog. And, of course, running VA Set Project Prefs just screws things up again. So you can't switch preference sets. Ramon -- I think it's time that you step on up to 2008...

This problem has been fixed in 2008. If you're still using 12.5.3, you can manually add a preference set. Open the following file: [VectorWorks]/Plug-Ins/VW_Arch/Data/VA2_Preference_Set_Paths.txt Here is the default contents of that file: ** VectorWorks ARCHITECT ** 6 VA Defaults [%plug-ins%]\VW_Arch\Data\Prefs_Def\ Prefs_01 [%plug-ins%]\VW_Arch\Data\Prefs_01\ Prefs_02 [%plug-ins%]\VW_Arch\Data\Prefs_02\ Prefs_03 [%plug-ins%]\VW_Arch\Data\Prefs_03\ Prefs_04 [%plug-ins%]\VW_Arch\Data\Prefs_04\ Prefs_05 [%plug-ins%]\VW_Arch\Data\Prefs_05\ You can add, delete, and edit items as you please in this file. But here are some things that you have to observe: * Do not edit the first line. * On the second line, enter the total number of items that follow. * When defining a pref set, the first column is the name, and the second column is the path. * The path can be an absolute path (such as /Applications/VectorWorks/Plug-Ins/...) or a relative path. * Relative paths have to use Windows sub-folder delimiters ("\") instead of Mac ("/"), even if you're on a Mac. * Relative paths can start with "[%plug-ins%]", which denotes relative to the plug-ins folder, or "[%VW%]", which denotes relative to the VectorWorks root folder. When you're done, save the file to: /Users/[YourUserName]/Library/Application Support/VectorWorks/12/Plug-ins/VW_Arch/Data/VA2_Preference_Set_Paths.txt Then the edited pref names and paths will show up. I don't know what to say about Ramon's problem, with finishes not showing up properly.

How many different actual PIOs are getting updated? I don't mean how many PIO instances in the drawing -- I mean how many different PIO types? In other words, is it all "Point Object #1", or is it "Point Object #1", "Linear Object #1", "Point Object #2", etc., that are in the reset chain? To put it another way, in the plug-in editor, where it lists the plug-ins of which VW is aware, how many of those items are involved?