Jump to content

Charles Chandler

Member
  • Posts

    97
  • Joined

  • Last visited

Everything posted by Charles Chandler

  1. 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.)
  2. 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.
  3. 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,
  4. 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.
  5. Try: DoMenuTextByName('AlignLayerViews',0); Like VectorScript plug-ins, use the filename.
  6. Try: FUNCTION SetToolByName(toolName :STRING) :BOOLEAN;
  7. 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
  8. 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
  9. 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
  10. 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.
  11. It's there, in the Dims/Notes palette.
  12. 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...
  13. 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.
  14. 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?
  15. I'm surprised to hear that this is still a problem. I tried to create the problematic condition in 2008 SP2 (83388), on both Windows and Macintosh, and didn't see any issue. I tried option-dragging a copy, copy-n-pasting a copy, duplicating a layer, etc. Regardless, at the very least as a service to those who are not running the latest version of VectorWorks (and perhaps for some who are), I created a Tips-n-Tricks page at VectorWiki.org on fixing a drawing once this problem has occurred. There is a document script that you can run that will automatically straighten everything out. Here is the link: Fix Stair Associations To answer visard's immediate questions: The "object name box" is the top box in the Data pane of the Object Info palette. And to the second question, in building with 3 or more floors, the intermediate floors will have stairs going up and stairs going down. To display this properly, you can set the stair "break" so that you only see a few treads of each staircase.
  16. OK, so it's not that you're calling SetRField on the other PIO twice; it's that you have to alter a parameter in the OI palette twice, regening the first PIO twice, to get the second PIO to update. Are there only two PIOs in question here? The reason I ask is that there is a different issue that can surface when there is a chain of resets that goes back and forth between PIO types. But it doesn't sound like that's the issue here. I'm stumped. What version of VW are you running, and on what platform?
  17. If you change parameters in any PIO (including the currently executing PIO), using SetRField, then those changes will be immediately accessible using GetRField. They will not be accessible using "pParamName" within the currently executing PIO. "pParamName" values are constants whose values cannot be changed during the execution of a script. Note that using SetRField to modify a parameter in another PIO will not cause the reset of that PIO, the way changing a parameter in the Object Info palette causes a reset of the selected object. You have to call ResetObject on another PIO to get its script to run. What does not happen immediately is that if one PIO is executing, and it calls ResetObject on another PIO, that PIO will not regenerate until after the first PIO's script is done. While resetting the class name will cause a regen, and while this at one time was a necessary work-around in some situations, this should no longer be necessary. ResetObject should work in all cases, at least to the same extent as any work-around would work. ReDrawAll will not reset anything. It merely forces a refresh of the screen, though within PIOs this generally doesn't do much. The part of the screen that VW thinks needs to be redrawn will automatically be redrawn, and anything outside of the bounding box of the PIO (before or after the reset) will be left as is. This can sometimes leave artifacts on the screen. There are work-arounds for that, but screen artifacts are not the issue here. Calling SetRField twice on another PIO should accomplish nothing, so I'm puzzled as to how this could be helping. HTH,
  18. I'm surprised that an object is created at all. Linear PIOs essentially have the same behavior as the Line tool -- if you double-click one single point in the drawing, you don't get a line of zero length -- you get no line, and the tool becomes deactivated. If you really feel obligated to eliminate this behavior, you can do a separate plug-in that will be a "tool" that you can use simply to collect pick-points, and when you've got enough points to create an object, then use CreateCustomObject to create the object, and exit the tool script. This is how the Framing Member Tool works, but not so much because the programmer really needed custom object creation behaviors, but because the Framing Member object is an SDK object, and these objects cannot be added to a palette and exposed directly to the user, like VectorScript objects can. So the programmer HAD to do a separate tool just to collect the pick points, and then use those points to create an object. This is why its creation behaviors are different from the Batt Insulation tool, which is just a linear PIO done in VectorScript.
  19. A while back I did a couple of plug-ins for generating the g-code for plasma cutting, and for re-importing the g-code for verification (or editing an existing part program). You can take a look at the (somewhat sparse) documentation at: CAD/CAM/CNC for VectorWorks. The biggest difference with laser cutting would be that you wouldn't need the .25" clearance that I'm providing for the lead-in and lead-out moves (which are automatically generated by the way). I should probably make the clearance user-definable. Anyway, I'll consider doing more work on this. Send me the specs for your controller and I'll see how much it would take to support it.
  20. See Example 1, at http://www.vectorlab.info/index.php?title=Events#Example_1 Basically, you just need to add another case, with something like this: kOnObjPrefEventID: BEGIN {Typically this dialog accepts user input and uses SetRField to write the values to the object's record definition handle.} AlrtDialog('Custom Preference Dialog'); END; Replace the AlrtDialog call with the name of your custom dialog routine. Charles
  21. Hi Bruce, Select the poly, and then click the Modify > Edit Polyline command. This will take you "inside" the polyline "group", where the individual components of the polyline are individually accessible.
  22. Use CreateSymbolDisplayControl instead. There's an example in the online function reference. By the way, VectorScript recognizes the first 20 characters of function, procedure, constant, and variable names. Characters after that can be present but are ignored.
  23. No, now that SP2 has been released, there is no way to update to SP1 -- the updater will always update you to the latest release.
  24. This means that your firewall is too restrictive. The updater needs to communicate with the NNA server, to determine the latest updates for your installation. If this communication fails, the updater will fail. So to install this update, you'll have to relax the firewall restrictions until after the update has completed.
×
×
  • Create New...