Ryan McCuaig

I don't think it's currently possible to have a script run on file open, though having scripts fire on events such as open, save, print, etc. has been briefly discussed as something worth implementing. As it stands, I'd probably implement it as a "Document Setup" menu command, similar to the Nemetschek-supplied one under "File > Document Settings > Document Setup..." (though this may be a VW Architect thing, so I'm not sure you'd have it). On the downside, you have to remember to run it after opening a template. On the upside, it wouldn't run on every save. To make it easier to remember, maybe include a big red note in the template, saying "run this script," that the script will delete on a successful run.

I don't know the internals. It may be more correct to say the "VS Compiler Mode" command changes it from interpreting PIO code once per session to interpreting on every insertion, versus compiling. But I don't think there's any practical significance to the distinction here.

@TheBlindExpert @maarten - I make a lot of use of Tools > Scripts > VS Compiler Mode during development ... it tells Vectorworks to re-compile every time the PIO is inserted. Turn this on, then just leave the VW script window open while you work on the code in your external program. If you've used {$INCLUDE whatever} and the right compiler mode, you should be able to save, switch to VW, hit compile, switch back to the editor, edit, save, back to VW, compile...

I'd devote resources instead to the debugger, a console, and a visual dialog editor. Something along the lines of Interface Builder on the Mac would be fantastic. This is a major reason that Mac GUIs are so painless to generate. By console / interactive prompt, I mean one like AutoCAD's or Sketchup's. It's incredibly helpful for exploring and learning how VS works, without the overhead of making up a plugin. I don't think the text editor is a priority. Editors are very personal things, and NNW can't hope to keep up with the dedicated programs. All I ever do during development in the VW editor is {$INCLUDE something.vss}, work on the file in TextMate, using a Vectorscript syntax customization I've put together. When ready, I paste back into the VW text editor. So, I'd support more hooks for external editors instead, and leave the development of editor customizations to outside devs. This is work that we can do; save Vlado's time for things that we can't. +1 for Pat's suggestion about hooking scripts to events, firing eg. on print or save.

Looks like VWFC::VWObjects::VWRecordObj has some methods for this, like GetParamValue(). Check VWRecordObj.h ... I couldn't find anything on the developer wiki. How you get a VWRecordObj given a handle to an arbitrary object is a little fuzzy to me.

Yes, Xcode is what you're after. Pay special attention to the setting up of targets, and locating header files. A lot of the build errors you'll get are related to Xcode not being able to locate hard-coded paths to headers and static libraries.

I would support Ruby or Python as the next generation of Vectorscript. C#, Java, or C-like, strongly-typed, finicky languages should be confined to the SDK. Most of what I've wanted to do can be done in Vectorscript; I just find the syntax (especially loops) cumbersome compared to Ruby, the inconsistent API syntax can be trying, and the need for variable declarations no longer seems necessary. In principle, there's plenty of room for two environments: 1. the hand-holding, garbage-collected, weakly-typed, get-it-done environment (henceforth known to me as VectorRuby), and 2) the chainsaw that is the SDK. I don't really care if it's C# (or Mono for us Mac people), but it seems to me that the SDK should simply be a thin bundle wrapper to provide a code entry point, plus a C library and a bunch of header files that can be called from whatever environment people would prefer to use.

Something like this should work on selected objects in the current layer. I like to confine any ForEachObject() operation so that I can see the result. In bigger files, you can cause havoc and not notice for a while if something happens to an invisible layer. But if you put (ALL) in place of ((SEL=TRUE) & (L=lname)) it should nail everything... might have trouble with things in groups. Hope this helps. PROCEDURE Main; VAR lname : STRING; i : INTEGER; PROCEDURE UseClassAttribs; VAR h : HANDLE; BEGIN h:= FSActLayer; { get a handle to the object } { set the object to use the class settings for } { its display attributes } SetFillColorByClass(h); SetPenColorByClass(h); SetFPatByClass(h); SetLWByClass(h); SetLSByClass(h); END; { PROCEDURE UseClassAttribs } BEGIN i := 0; lname := GetLName(ActLayer); ForEachObject(UseClassAttribs,((SEL=TRUE) & (L=lname))); AlertInform(Concat('UseClassAttrib applied to ',i,' objects'),'',TRUE); END; { PROCEDURE Main } Run(Main);

No luck here with the firewall off, although I do get an extra download step that wasn't happening before. It simply fails in the same way after a long download.

Same error here on OS X 10.4.7, installing over 12.0.1... had an uninterrupted download so I doubt that's it. Little Snitch (http://www.obdev.at/products/littlesnitch) says: "ExtractFiles wants to connect to nemetschek.net on TCP port 80 (http)" "ExtractFiles wants to connect to exchange.nemetschek.net on TCP port 25 (smtp)" Seems a bit weird to me that the installer wants to connect to a mail server, but what do I know... Opening up port 25 on my end makes no difference, still get the same error.

The plotter has to represent *everything* (even blank space) in memory. If you had a 24x36" sheet at 300dpi, it would take 24x36x300x300 = 77MB in grayscale, or 3x that for colour = 233MB. Multiply by 4 for 600dpi (2x in each direction = 4x total), and it's around 933MB to represent your drawing as a bitmap. So 1GB is not an unreasonable spool size. The same drawing at A3 would only be 11x17x300x300x3 = around 50MB at 300dpi, or 200MB at 600dpi. Usually inkjets don't have very much memory, so they rely on the computer they're connected to (hence why the letter size ones cost less than their own cartridges). In your case, it may be that 128MB just isn't enough RAM to deal with the big size.

We generally repair permissions after updating the drafting stations, so I'm not sure that's it. Thanks, though. We may try reinstalling VW from the original dmg files next...

Mark, we have tried the force-quit and it doesn't seem to work. We can make the problem happen pretty frequently by: 1) opening 2 or more files, 2) saving one file. If Vectorworks crashes during save, the file being saved is trashed, ie. the Finder says it's 0 bytes. This is happening 1-2 times a day in our 20-person office; all machines are VW 12.0.1 and OS X 10.4.6, and our server is 40% full. We have turned on Preferences > Session > Save To A Separate File... throughout the office and this seems to cut our losses to 15-30min drafting time when it happens. This is not fun one. Very much looking forward to the fix.

In our experience, this seems to relate to corrupt font caches under OS X. Running FontFinagler (http://homepage.mac.com/mdouma46/fontfinagler/) and restarting makes the problem go away for a few weeks for us.

I have had some luck running a script containing only: DelName('Plugin-Name'); Your PIO should now insert without the error message, as this will get rid of the name collision that's triggering the problem. I don't know what this does long-term as far as leaving cruft in the file, as in theory there is now a (hidden) PIO record format with no name in the file. But, also in theory, it should purge once nothing's referring to it.

This seems to be related to a problem we're having with 12.0.1 on Mac OS X. We have a drawing list in a worksheet, in its own file. We want to reference the worksheet into a plan file (_not_ import). Open the plan file. Navigate to the worksheet file. Right-click the worksheet and we are offered the choice of "reference" or "import." Click "reference." The trouble is "reference" seems to work the same as "import," ie. VW copies the worksheet into the plan file, so it misses updates to the worksheet file. It doesn't seem to matter if it's on the network or local.

Ok, thanks. We went ahead and pushed it out anyway. In the future, it would be nice to have such a list a) to know we're not crazy when something seems amiss, and b) to help with planning out how we'll use various features... some things become show-stoppers at the 11th hour & it can get a bit frustrating. Knowing there's a bug A that happens when you do B means we'll plan to avoid doing B until notified otherwise.

Bueller?

Anyone? Anyone?

Katie, thanks but that PDF is the document that points to our missing "Fixed Bugs.htm" document. Is it available somewhere else?

Looking through the 12.0.1 documentation, I see there's supposed to be a file called "Fixed Bugs.htm" at [Vectorworks]\Release Notes\Fixed Bugs.htm. Anyone else find this file, or is it on the NNA website somewhere? We are triaging our 12.0.1 deployment (20ish machines) based on whose annoyances have been fixed first.

quote: Originally posted by Katie: [...] The font substitution is lifted in VW 12 since it's a cooca application. VW12 seems more to me like a Carbon app that now uses the Quartz graphics engine instead of the QuickDraw one... it hasn't really been rewritten into Cocoa, has it?

quote: Originally posted by wjb: In Canada, rigid insulation is typically drawn by a rectangle of dimensions equal to the insulation material thickness and length in section, filled with a repeating pattern of short lines (perpendicular to the long axis) which are 2/3rds the width of the rectangle, alternating in direction, and staggered equally along the length of the section. I've made up a linear plug-in that does the "Canadian standard" version as well as the one shown in Detail magazine: Unlocked, fully probe-able. Share it to your heart's content. Hope this helps.