Currently, yes. That is how the plugin works. That's one feature I do not like, and one reason I don't use it. The VW drawing should not have to be designed specifically around export. The layers should be able to be derived from a user field.

Yeah, multi patched fixtures on the same layer shouldn't create an error.

I really wish the official version would allow patch layers by a user field or something. I really don't like having to design my VW document's classes or layers around the patch.

Thanks guys, Apparently, it was a current-launch bug. Today, the problem is no longer happening. What's also weird is that all of my other PIOs use the same text-scaling procedure, but it didn't work in this one. So I corrected it without the scaling. Today, when I opened up the work file, the text was massive. I changed it to match my other PIOs and now it works correctly. So, it looks like all of that was related to the same thing. It's all working now. Alas...I didn't think to turn it off and back on again.

I have a tool I created for placing exhibit graphics. It's just a simple box and two pieces of text, controlled in the OIP. All of them react to a "Top" or "Bottom" setting in the OIP as well. When I select "Bottom", everything lines up as expected. When I select "Top", the text flies off into space, even though the correct dimension is being calculated. Here is a sample of the script: --------------------------------------------------------------------- {---------------CREATE RECTANGLE-------------} rectwidth := PWIDTH; rectheight := PDEPTH; IF PDIRECTION='Bottom' THEN BEGIN TextOrigin(0,(-.5-RectHeight)); TextVerticalAlign(1); END; IF PDIRECTION='Top' THEN BEGIN TextOrigin(0,(.5+RectHeight)); TextVerticalAlign(5); END; TextJust(2); BeginText; concat(PNAME) EndText; IF PDIRECTION='Bottom' THEN BEGIN TextOrigin(0,(-5-RectHeight)); TextVerticalAlign(1); END; IF PDIRECTION='Top' THEN BEGIN TextOrigin(0,(5+RectHeight)); TextVerticalAlign(5); END; TextJust(2); BeginText; dimtext EndText; --------------------------------------------------------------------- If RectHight is set to 1.5", as is default, and I select "Bottom", the PNAME text is at -2" and the dimtext text is at -6.5", as expected by the calculations. If I select "Top", PNAME should be at 2", but the text ends up at 21' 6.56". dim text should be at 6.5", but it ends up at 14' 9.54". Am I missing something, or have I encountered a bug? I don't recall having this issue previously on other scripts. Could it have anything to do with the source number being a dimension instead of a number? Oddly enough, if I put the calculation for one of the top locations in one of the text fields, it shows the correct number, while putting the text off in some weird location. If I need to include the entire script, I will. EDIT: I forgot to mention...if I change the TextVerticalAlign to 1 from 5, the text jumps to the correct coordinates, but is below instead of above that coordinate.

Yep. Most likely the internals of the symbol are in the "None" class. This is very normal. "None" is the default class in every document (along with "dimension"). Your lighting symbol might be in the "Lighting" class, but the lines and polygons that make up that symbol are probably in "None".

Yeah, that's a bummer. When I have some time, I guess I'll have to learn python scripting. I also can't use comma-delimited. Almost all of my data has commas in it. " Edison 12/3, 50' ". And I'd rather deal with working around it than changing all of the data to something uglier.

Okay. Thanks all. I was hoping for something simple I was missing! Seems like that would be a bug, and one that could be fixed fairly easily.

When importing a tab-delimited .txt data file from Filemaker, some fields may be empty. I've noticed that when a field is left black, Vectorworks ignores it and imports the next field in its place. So I have this test data: R1 1ABC 1DEF 1GHI R2 2DEF 2GHI R3 3ABC 3GHI R4 3ABC 4DEF R5 5DEF 5GHI And this simple script to test it: PROCEDURE ImportInfo; VAR filename,recnum,field1, field2, field3: STRING; BEGIN; Getfile(filename); Open(filename); WHILE NOT EOF(filename) DO BEGIN Read(recnum,field1, field2, field3); AlrtDialog(concat('Record: ',recnum,'. Field1: ',field1,'. Field2: ',field2,'. Field3: ',field3,'.')); END; {while} END; Run(ImportInfo); So, when I run that script, the first dialog says: Record: R1. Field1: 1ABC. Field 2: 1DEF. Field3: 1GHI as expected. But, the second run of it says: Record: R2. Field1: 2DEF. Field 2: 2GHI. Field3: R3 So, it has skipped the blank area in the first field of the second record. I have been dealing with this for ten years by putting a dash in empty fields. But, I really want to move past that, as that is error-prone. Since it seems to ignore the field, I don't know how to check for the field being empty. I can't move to comma delimited, and would really rather not move to colon-delimited. You guys are geniuses, so I'll throw this one at you!

Yep...the way mine is currently set up is that is uses IsNewCustomObject() to generate an ID upon creation, looking at existing IDs and adding 1. Then when duplicated, it checks the ID against the object name, which changes no matter what. If those two are different, it changes the ID number. But, this will only happen upon regeneration, which requires changing a field. SO, for now, that's what I do. I'll have to look up how to deal with kObjectCreated/13.

I am not, but that's precisely the item I am trying to disable. When I drop a fixture in, it often assumes basic mode, when my symbol is in extended mode.

When I drop some of my symbols into a drawing, they appear to automatically assume a mode from the drop-down menu. I do not want this, as I have my symbols drawn with the correct information, and Spotlight appears to always put the other mode. For instance, when I drop in a Viper Performance, it assumes standard mode, while I am using extended. My symbol's Light Info Record uses the extended number of channels. This explains why my paperwork was all messed up last show! At some point, I did a replace of the symbols on the drawing, and the number of channels changed to the wrong mode. I do not want Spotlight to assume a mode. Yet I cannot find whatever setting may control this. It does not appear to be in the LIR. Any way to turn this off, or just something I need to change in my workflow? Is it something I set when I made the symbol?

Whoa. That all sounds way above my head! But I'll look it up...don't know anything about the SDK or kObj type stuff. That's a shame. Was hoping for something more elegant than having to assign them upon export.

Expanding functionality of some of my tools a bit further. I need each object created by the tool to have a unique identifier so that data can be imported and exported between Filemaker. I have created an ID field in one of my tools in which I create this unique ID upon creation of each object. This works perfectly currently. However, any time I duplicate an object, the ID field will not regenerate until I change another field, which kind of negates the purpose. I've been trying to use the workarounds shown in the IsNewCustomObject page of the Language Guide, but I can't seem to get them to work either until I specifically modify a field in the OIP. Has anyone figured out a secret to a PIO updating upon duplication? The Lighting Device tool does it, so it must be possible. And, while we're at it: I know how to make a field in the OIP not editable. But, how can I make the object name also not editable? Can't seem to find the right procedure.

I'm not at my console right now, but can you have multi patched fixtures on different fixture layers in the console? I don't believe so. If you are creating your fixture layers from Position, as shown in your dialog, it will then try to patch your multi-patched fixtures on different trusses to different fixture layers, which I don't think is possible inside the console. That's why it works when you choose "All in one layer" or choose to define fixture layers by design layer, assuming all of your fixtures are on the same design layer.