TiTaNiuM sAMuRai

I'm opening a v8 file in v9. This file has a wref to another v8 file. The referenced file has not yet been converted to v9. As a matter of sound practice, I won't take a project that was started in v8 and carry it to v9. As a result, if I need a v9 reference, I'll build one from scratch. However, not everyone is of the same mind, and some v8 users may want to convert their project files to v9. If the referenced file name kept the _V9, VW looks at the v8 file, sees that it's the wrong version, and does one of two things:1) Alerts user that the ref'd file is not v9, and opens the file, with the error message "Error opening 'filename' while updating yada yada...". Okay, this makes enough sense; I need a v9 source file, with the same name as what the reference points to.2) Alerts user that the ref'd file is not v9, then pops up a dialog asking the user to select the file to use for the wref update. Point to the converted source that still has the _V9, if you have that. Point to a completely different name, or the same name but in a different directory. Whatever. What I don't understand is why VW sometimes -- usually -- displays behavior #1, but occasionally gives me behavior #2.

Saved caches. I see now where the size thing / rumour has its roots. Interesting approach...

... but I never HAVE the source file in v9, same name or not. I don't need to maintain the link in these cases. If I did, then I'd first update the source file (overwriting the v8 version, so I have the same sourcefile name). I'm not interested in updating the reference; I copy out what elements I need. I'm not stuck on anything, I just wanted to know why there is an inconsistency.

Sometimes, opening a v8 drawing -- that contains a wref -- will ask for the v9 version of the referenced file, but usually will not. Where's the toggle? 9.5.1 on X.1.4, the v8 files happen to be templates, and they are being opened both by a double-click and manually through VW.

Base floor plans which can be used for Floor Plans, Reflected ceiling Plans, Floor Finish Plans, and Millwork/Equipment Plans. Designers can also reference in the technical plans, and still produce presentation documents that are current with the working drawings. Sorry for butting in...

Are you switching from one preset to another, or ar you selecting 'Set thickness...'?

20 posts, I suppose, is the threshold to indicate regular contributors.

1. The windows you are using (and likely the doors, too) are VectorWorks Plug-in Objects. When a PIO (even in 9.5.1) is pasted into a different scale, it will not recalculate (it will not re-execute the script). Don't ask me why the app is written like that. 2. Dimension features (such as arrowheads) are programmed to appear the same size as printed, in the same way that 12-point text will adjust itself depending on layer scale (this applies only during text creation, since copy/paste doesn't maintain text appearance size. In fact, it isn't resized, whereas the arrowheads are).

When you say that the text size changes, do you mean the printed size or the world-space size?

I know that the source must be v9. I always get the error message, but occasionally I'll get a dialog asking me to find the v9 version of the referenced file.

Let's say I have a LinearObject PIO that's printing white elements (PenFore), since I'm using a black background. The PIO can be reshaped, moved, rotated, or otherwise modified, and still prints correctly (white pen on black background). At some point when I'm drafting, such modifications to this PIO (and all my other ones) will cause it to switch to a black pen.I use my SetPrefInt(16) to FALSE via a menu item, so I get a white background. The incorrect PIO is now white pen against the white background; this makes sense enough. Then I enter the 'Create Plug-in...' dialogue, click 'Done', and all the PIO's are re-executed. The PIO corrects itself, using black pen against the white background. I use my SetPrefInt(16,TRUE) menu item, and the PIO is white pen again. Now: if modification (rotation, etc.) to this PIO caused it to write with a black pen (the background is black now, remember), I wouldn't be all that surprised. However, this is not the case. Re-execution of the PIO script due to moving, rotation, parameter-changing, etc. does not cause the pen white/black flip. Not until a little while later, maybe 20 or so commands down the road. I've tried my PIO with and without a check to see what the GetPrefInt(16) value is -- and compensate for it -- but this has yielded no solution. I'd like to think that there is something I'm doing wrong, instead the result of a VectorScript bug.

Regens appear to be inconsistent. I have a check to pref #16. Stretching the PIO recalculates for redraw, but doesn't get the right numbers. Moving does get the right numbers before recalculating. What's the deal? Switching between white and black appears to show no consistency.

I feel your pain. BTW, VectorWorks is NOT primarily a drafting tool. It's a program to create working drawings. Workgroup refs come in -- origin to origin -- but can't be moved. Create wrefs, then create Layer Links on a separate layer. The Layer Links work almost exactly like xrefs. Turn the wref layers off.

If I first PushAttrs, then PopAttrs when I'm finished my PIO, are there any document settings that aren't restored? I modified the scale factor for some text, and, as a result, my document text settings get messed up, remaining so after the PIO has been executed. Whassup, Willis?

Excellent, Watson. Brilliant, yet wonderfully simplistic! Thank you.

Have you done colour correction testing to account for the screen's gamma setting? Are you printing to Postscript or non-Postscript ?

I fully understand the speed issue; regeneration time will vary, depending on the state in which the file is saved. Actually, Photoshop regen could vary depending on filters and such. However, I'd like to know why 3D/2D states affect the file _size_. Andrew?

"This will not write all the 3d information to the file but it will store it so you don't lose it." ... and VW would 'store it' how, if not writing to the file? I'm really dying to understand the nature of VW's saved-state character...

Is your black empty? (assuming you have a CMYK ink setup) The cyan ink is less likely a culprit, but maybe. The magenta ink wouldn't have been responsible, since it IS printing.

Unless I'm mistaken, it's been changed and hardwired to the arrow keys while holding down Shift.

Thank you, Katie.

Sorry. It's only the text of the PIO's that's messed up. TextSize(TagFontSize); {12 pt; INEED2 set the unit to 'points' instead of mm or inches} TagFontSize is a CONST ( =10; ) Is there a more thorough way of specifying the text size? Should I set a metric SIZE for the text, and then scale up that value?

Whenever I go to the Create Plug-ins dialog, all the PIO's that I have (custom-made) reset themselves to the ACTIVE layer only. When I switch to another layer (different scale, so the PIO's are incorrectly scaled), moving the PIO doesn't fix it, but rotating does. Reset on Move is checked, as is Reset on Rotate. The regen check is as follows: {"error-check for possible size changes in regens"} if IsNewCustomObject (this_object_name) or (GetLayer(this_object_handle)=NIL) { what does this check mean? } then LayerScale:=GetLScale(ActLayer) { set the scale var to the current doc scale } else LayerScale:=GetLScale(GetLayer(this_object_handle)); { retrieve scale of object's layer } It's as though the GetLayer doesn't work correctly during a global PIO update. I originally grabbed the above check from a v8 Elevation Benchmark script. Can anyone help? Until then, I'll try to check if the placement of the code (and assignment to LayerScale) is the culprit.

... and as I'm drawing an arc somewhere else, I noticed that the p1 and p2 for the arc parameters establish the DIAMETER for the arc? Am I mistaken, or is this true? DIAMETER FOR AN ARC???

The document information to restore the last zoom value (zoom&pan, actually) does exist; it is what Undo uses. Is there a way to access this information from VectorScript? Why hasn't Diehlgraphsoft already put it in? What's been holding NNA back?