JoelS

I have some fairly hefty scripts which operate on thousands of objects and I would obviously like to optimise the performance as much as possible. I take care with my dynamic arrays and things like that but are some operations typically slower than others? Is it better to create and destroy an object where you need it or move it around? Are WHILE loops faster than ForEachObjectInList? Do criteria searches slow things down or not? Are there any consistent methods for profiling to see where your script spends a lot of time? Thanks, Joel.

Thanks Jonathan, I'll keep that in mind. Joel.

Hi there Islandmon, Thanks for the reply, but this is an import problem into VW from original AutoCAD data via DXF. The only variable that AutoCAD allows on export of DXF is whether it is binary or ASCII 16 digit - not that it makes any difference to what VW does with it on import. Joel.

As I import a lot of DXF data for landscape design, most of the objects are AutoCAD splines or polylines and while these import with the shape intact, the number of vertices is something like ten times greater (or more) than that in the AutoCAD drawing. Yesterday I had a chance to use AutoCAD and VectorWorks 2008 together and trialled many simple objects and all the export options that AutoCAD makes available (not many). In every case, splines suffer this massive vertex inflation on import. This has been going on for a long time (v10 certainly) and we spend a huge amount of time cleaning up these objects to make them sane. The version of DXF/DWG is irrelevant, they all do it. 3D NURBs are the only splines that seem to come across in a sensible way but I cannot find any way to convert spline to NURB within AutoCAD - not that we will be able to this very often anyway. Importing the same data into MapInfo or Canvas (or reimporting it back into AutoCAD) results in objects that are identical to those in AutoCAD, so it's definitely VectorWorks which is in error. Are there any factors that might affect this issue during import? Joel.

Agreed, this is a good rule, however this is a rare instance of it being a convenience for the user to have some aggregated information generated by the PIO placed on their clipboard (at their choice) for immediate reuse elsewhere. As this is something they are used to and appreciate, I would like to preserve the functionality. Saving the same data as a file is just a nuisance. Joel.

It used to be possible to call DoMenuTextByName('Copy', 0); with text selected in a StaticText field under VW11.5 but it seems that with 12.5 the Copy menu item is always grey when any PIO field is selected. Why has this changed and is there a work around to get data onto the system clipboard? Joel.

Kevin, Many thanks, this works nicely. I didn't think of using GetObject() in this way and it opens up some other possibilities too. Joel.

How can I test that a record definition (format) exists in my document before a script attempts to use it in the same way as I can for symbol definitions? I could attach all the RFs to a special object and test that but it seems a bit clumsy. TIA. Joel.

I find myself in agreement with those who consider 'None' an odd choice of nomenclature for something that does have existence, and indeed parity with all the other classes one might create. It's not null in any sense. Not inactive, not unusable, not irrelevant, not invisible, not useless, not empty. What else could it be named that conveys its presence more clearly? Default, Misc, Placeholder, Base, Root, General, Indefinite, Undefined, Hotchpotch, StuffWeDontKnowWhatToDoWith? OK, so the last one might break something? Joel.

Thanks so much Antone, that's a really interesting techinique - it was the use of Project 2D Objects that I didn't understand. Joel.

I would like to be able to incorporate layers from one document in another but with a scale and rotation in the target document different to that of the source document. The task is to have detailed 2D/Plan building drawings appear on a separate site map rotated into position at the correct location and scale and have them be updatable from the source when necessary without too much manual intervention. Rotation is desirable as the buildings in plan are much easier to draw on a non-rotated grid and the map is constrained to OS co-ordinates. WGR brings in the layer as it appears in the source and would have to to be scaled, rotated and placed before/after every update. Copying and pasting would be just as easy and just as inefficient. WGR cannot reference viewports in the source so cannot return rotated and scaled elements in this way. Layer linking works only within the one document and modifications to the linked layer are prohibited. Is there a way to do this with Fundamentals 12.5? TIA Joel.

Katie, The lines appear in Save as PDF no matter which printer is selected if the data originates in VW, no matter what settings I try. If Save PDF as Postscript is selected, I get good output irrespective of the printer driver chosen. All the other applications from which I have used Save to PDF produce good output using any of the printer drivers. Joel.

I can confirm that output from VW via Save PDF as Postscript works well, generating clean PDFs when converted with Preview, incorporated into another application and printed to the R1800 at A3. Joel.

I think I have found a workaround that seems to be producing good output. If instead of Save as PDF? I choose Save PDF as Postscript? and the open the resulting file with Preview and let it convert the file to PDF, the rendering is clean. I still have to go through the whole process of using the PDF in my DTP and finally printing the document so I'll report back on the results. Joel.

Printing to the R1800 printer is fine. I have tried various settings in the print dialog, including all VW settings, changed to another printer (laserwriter) but the PDF output always shows the same lines. PDF output from other applications using the same mechanism is not affected by this problem. I don't really understand the interaction between the print dialog settings and the effect these would have on the generation of PDF output. I'll look into the generic printer option. Joel.

My Epson R1800 to which I usually print VW output. Joel.

When I print to PDF via the Mac OS X print dialog, the resulting PDF is of the correct region and the content is rendered OK but there are fine white vertical lines (gaps?) in many of the filled objects which renders the image unusable. The lines are present both in Preview and Acrobat Reader of if the file is imported into another application. Printing the same region is fine. Page setup has the scaling for VW and the page attributes as 100%, A3 LS. All my layers are set to 'Paint'. VW 11.5.1 Mac OS X 10.4.8 TIA Joel.

Absolutely no problem. Please redirect all ire, real and implied to NNA :-) I have a client who would benefit from WGR and would keep a master map somewhere to be accessed by users around the organisation, most of whom would be making some contribution to the drawing. The master would be refreshed periodically to incorporate their changes. The issue is that none of them would have their own symbol folders, deriving all their resources from the master. In this case, all symbols are in one big list. In any case, it's not beyond the wit of man to name symbol folders drawn from another document so they cannot be confused. Where name conflicts occur they are easy to resolve. To simply ignore the organisation of external symbol libraries seems to me a real and unnecessary disadvantage. I'll propose a system where symbol folders are eliminated and symbol names are prefixed in some way to group them, expound on the pros and cons and see what they think. Joel.

If there is logic in organising symbols into folders in the master, how is that logic invalid in the client? If the alias of a folder in the Finder was not actually a folder but just the files it contained, I would not be happy. In any large solution (where WGR is ideal) there are symbols for use by scripts alone and those to be placed by the user. Mixing them together is a bad idea. If the folder structure is indeed brittle with WGR, perhaps it's better not to have symbol folders at all anywhere and just have a long list of symbols with prefix codes to keep them in groups - it certainly would make the scripts that traverse symbol libraries a lot easier to write. Hard luck for the poor user who has to scroll through them all though... Joel.

I have been experimenting with WGR in VW 11.5.1 and I see that client files have all the symbols from the various folders of the master grouped together at the top level of the resource browser in the client - the folder structure of the symbols in the master is effectively lost. Is this behaviour as it should be and why does it work this way? Scripts that look for specific folders obviously won't work in the client and having all the symbols available presented in one list is difficult for the client user. Thanks, Joel.

Some of my clients on PCs are seeing changes to diacritical characters when brought in to VW 11.5 through a scripted import into a RF field. I am using my own VS which imports tabular data from a text file to populate object data. Text strings containing diacriticals can be pasted into the same RF fields and they appear to remain intact. Diacritical characters also appear to be preserved when opened in various different applications on the PC but not when brought into VW with the script. On my Mac this is not a problem so I can't replicate it. What could be happening to the text encoding used during import? TIA. Joel.

The consensus from tests other users have kindly done for me seems to be that palette script encryption actually does not work in VW, contrary to the manual. Encrypting PIOs does work and I'll use them in future. Joel.

With some help from the good folks at Vectorscript-L, I wrote the following AppleScript that will take a VectorScript from the front window of SubEthaEdit and execute it in VW, ignoring the usual AppleScript timeout if you are debugging: code: -- getplaintext subroutine called from within the Tell using 'of me' on getplaintext(fromUnicodeString) set styledText to fromUnicodeString as string set styledRecord to styledText as record return ?class ktxt? of styledRecord -- Ensure Western (Mac OS Roman) encoding end getplaintext tell application "SubEthaEdit" activate -- Get the script text out of SEE as a string. set theScript to the text of document 1 as string -- Convert from Unicode set theScript to getplaintext(theScript) of me tell application "VectorWorks" activate -- Execute the script in VW ignoring application responses DoScript theScript end ignoring end tell end tell[/code] The pascal syntax highlighting in SubEthaEdit does a good job and I like this editor better than BBEdit. Joel.

I have tried encrypting palette scripts that call includes so they can be distributed to my clients but if I move the includes or run the script on a machine that does not have them, the scripts fail because of missing includes. Restoring access to the includes restores normal functioning. I thought that include files were copied into the encrypted script so that they would be autonomous. I have suffixed the name of all the include files with .px (e.g. IncludeTest.px) and the palette script is certainly locked - at least it can no longer be opened for editing. No include contains references to other files. For the Mac (Tiger/VW11.5.1) I used the Caps lock-Shift-Opt-Cmd-double-click sequence to encrypt. What might be happening here? TIA, Joel.

I am attempting to use SubEthaEdit and AppleScript to send VS for execution in VW. My AppleScript is: tell application "SubEthaEdit" activate set theScript to the text of document 1 as string tell application "VectorWorks" activate DoScript theScript end tell end tell theScript variable is of class string and contains the command in the SubEthaEdit window as a string but VW returns an error that the data is of the wrong type. The "as string" is coercing from Unicode. If I simply change the tell for the application from "SubEthaEdit" to "Tex-Edit Plus" with the same data, it works fine and the command is executed. In both cases, the AppleScript editor shows the correct, identical string being passed to DoScript. What could be happening here and what is the AppleScript editor not showing me that could make the script fail? TIA, Joel.