Sam Jones

I doubt that the ODBC option will be worth the work. It would seem that you need to make a library of red symbols that will end inserting as Lighting Devices with the record attached with the values saved when the red symbol was saved. These can be pulled into your documents with the saved record values. If you want to go over this process we can Zoom. Since you are in Germany and I am in Los Angeles the Zoom meeting would happen in your late afternoon or evening. This process would also allow you to have different libraries should you have different rental houses. This is a process that can be used with most plug-in objects should you need. Sam sjones@autoplotvw.com

Nope. If the VW tool works for you, you are good. As Scott said, their is a fully functional trial period for the AutoPlot Tools, but there is a good chance that looking at the video Scott mentions will show you all you need to know.

For Sam Jones it is best to send an email to sjones@autoplotvw.com His website is www.autplotvw.com

For Sam Jones it is best to send an email to sjones@autoplotvw.com His website is www.autplotvw.com

Thanks.

I want to set the name of a sheet layer that I am creating with a script using, "TrussTapeLayer := CreateLayer(TapeDLName, 1) This command sets the sheet layer number equal to the TapeDLName. I want to set the script to set the sheet layer name equal to TapeDLName. How do I do that and how do I change the sheet layer namej? TIA

I may be wrong, but the above solutions, and they are solutions, seem to miss the original ask. So let me ask you, Martin, do you want to change all the objects contained in a parent object to be assigned to the same class as that parent object? And, would you like the option to assign a class that you choose to the parent object and all its children? In both cases would you like the option to have the child objects to be assigned a "-" sub class of the parent object class?

It is important with Raymond's function that "Show/Snap/Modify Others" is selected. If you have "Show Others" selected there will be objects that are selected on other layers that do not present as selected. There may be times when you don't care if the selected object is not seen as selected, but those will be rare and they can be handled just as well with "Show/Snap/Modify Others". If you do care, but you don't want to have to be sure that "Show/Snap/Modify Others" is selected, do the following You will need to change the ForEachObjectInLayer function to this: ForEachObjectInLayer(FSEL, 3, 0, 4); { Visible/Selected objects, Shallow, Editable Layers }

Duplicating requests is not a problem; it is a help.

What labels?

Nope. Sorry Raymond. Your example doesn't work either. I noticed that your code does not place the locus, so I put in code to do so, but the following code does not work. SetParent() fails without triggering the alert. I tried the code below without the HMove(), and still no Joy. SetParent() seems to be the problem. No locus shows up anywhere in the symbol. The code was run from a text file .vs. PROCEDURE Test; VAR SymHdl :HANDLE; SymDefHdl :HANDLE; LocHdl :HANDLE; X, Y :REAL; BEGIN SymHdl := FSActLayer; SymDefHdl := GetObject(GetSymName(SymHdl)); GetSymLoc(SymHdl, X, Y); Locus(X, Y); LocHdl := LNewObj; IF SetParent(LocHdl,SymDefHdl) THEN BEGIN HMove(LocHdl, -X, -Y); ResetBBox(SymDefHdl); END ELSE AlrtDialog('SetParent Fails'); END; RUN(Test);

Nope. Sorry Pat. The above does not work.

My problem is that I need to set the location of the object, so I need to place the object using the coordinates of the definition. How do I do that?

Is it possible to place a Locus, or any other object, in a symbol definition/ I can get a handle to a symbol definition. I can iterate through the objects in the definition. I can edit those objects. But, I cannot find a way to place a Locus or any other object inside a symbol definition. Anybody know how?

Here is a code snippit from my "Draw Center Line" macro. I think it will get you there. Email me if you want to talk. Most pertinent lines marked with a {************} Sam sjones@autoplotvw.com CONST kDefautLineTypeNm = 'ISO-08 Long Dashed Short Dashed'; IF (GetObject(kDefautLineTypeNm) = NIL) THEN BEGIN ResList := BuildResourceList(96,14,'Attributes - Line Types',NumLineTypes); {************} FOR Index := 1 TO NumLineTypes DO BEGIN LineTypeName := GetNameFromResourceList(ResList, Index); {************} IF (LineTypeName = kDefautLineTypeNm) THEN BEGIN NeededLineType := ImportResourceToCurrentFile(ResList, Index); {************} END; END; END ; {IF (GetObject(kDefautLineTypeNm) = NIL) }

Josh's response is one of those amazing responses that is both complete, if a little cryptic, and the tip of the iceberg. I would stay away from creating parameters via a script. If I assume that you are using widgets to display the values of the parameters, you are going to have to maintain the separate record that Josh describes and shuttle values of the record fields back and forth to and from the widgets. The "to and from" part is not clear to me. Are you planning on having users enter/choose values by changing the widgets in the OIP, or is the OIP just there to display values. I'm having a hard time imagining why you want to create the parameters with a script. Are you trying to create a dynamic OIP that changes its own fields on the fly? Could you describe how you want to use this PIO such that you need to use a script to create it?

It fails with the attempted execution of: Result := InsertNewDLCompN(3, 750, 1, 0, 0, 0, 2); Procedure CustTool; {$DEBUG} VAR Name:STRING; Result:BOOLEAN; BEGIN PushAttrs; Result := DeleteAllDLComponents; Result := InsertNewDLCompN(1, 35, 1, 0, 0, 2, 0); Result := SetDLComponentName(1, ''); Result := SetDLComponentClass(1, 0); Result := SetDLComponentFillColors(1, 257, 1241); Result := SetDLComponentPenColors(1, 257, 256, 257, 256); Result := SetDLComponentUseFillClassAttr(1, FALSE); Result := SetDLComponentUsePenClassAttr(1, FALSE, FALSE); Result := InsertNewDLCompN(2, 115, 1, 0, 0, 0, 0); Result := SetDLComponentName(2, ''); Result := SetDLComponentClass(2, 0); Result := SetDLComponentFillColors(2, 257, 1242); Result := SetDLComponentPenColors(2, 257, 256, 257, 256); Result := SetDLComponentUseFillClassAttr(2, FALSE); Result := SetDLComponentUsePenClassAttr(2, FALSE, FALSE); Result := InsertNewDLCompN(3, 750, 1, 0, 0, 0, 2); {--------------------------CRASHES HERE------------------------} Result := SetDLComponentName(3, ''); Result := SetDLComponentClass(3, 0); Result := SetDLComponentFillColors(3, 257, 256); Result := SetDLComponentPenColors(3, 257, 256, 257, 256); Result := SetDLComponentUseFillClassAttr(3, FALSE); Result := SetDLComponentUsePenClassAttr(3, FALSE, FALSE); SetDLSeparation(900); SetDLControlOffset(0); SetDLOptions(1); FillBack(256); FillFore(257); FillPat(0); PenSize(0); PenBack(256); PenFore(257); PenPatN(2); CallTool(-218); PopAttrs; END; Run(CustTool);

Dividers for layer lists, yes. Layers with the same name, no. In the absence of the former, still no for the latter. On that path, lies confusion, agony, and death. (Next time, I'll tell you how I really feel.)

The only way I know to hide the movement circle is to give it a class in the symbol definition and hide that class. Vectorworks University has 2 or 3 videos. I would start with "A GUIDE TO DATA VISUALIZATION WITH VECTORWORKS".

If you use Layer colors, you cannot color different fixture types with different colors. Everything on the layer will be the same color. I have only been able to get class colors applied to Instrument type with the following settings. While this works (sort of), I get much much better results using Data Visualization (DV). Which also gives me much greater latitude as to when I color by Instrument Type or by another Lighting Device parameter. Using DV I can use different settings for different viewports depending on for whom the sheet layer is meant. Learning DV will open up a whole new world for making your drawings more informative, and not just for Lighting Devices.

"Track Object" is really cool for guiding the use of menu commands, but it will not solve your redraw problem. Unfortunately, as far as I know, nothing will solve your problem. No redrawing will take place until after the entire command is completed.

And I forgot to add, be sure to use long descriptive names for the field constants, so that you know what field your code is referring to in all of the calls in the SetupDialog code and the code that you want to create in the dialog handler. For example { control IDs for Breakin Edit Dialog} {Instead of: kUnnamed1 = 4; kUnnamed2 = 5; kUnnamed3 = 6; kUnnamed4 = 7; kUnnamed5 = 8; kUnnamed6 = 9; kUnnamed7 = 10; kUnnamed8 = 11; kUnnamed9 = 12; } Use: kBIInventoryNameLbl = 4; kBIistLbl = 5; kBIListBx = 6; kBILengthsLbl = 7; kBILenEditTxt = 8; kDeleteSelectedBIsBtn = 9; kAddBIsBtn = 10; kAddBIBtnLbl = 11; kSaveBIAsNewBtn = 12; {Part of the SetupDialog for the Breakin Edit Dialog} BEGIN Dialog10 := CreateLayout(GetStr10(3), TRUE, GetStr10(kOK), GetStr10(kCancel)); {create controls} CreateStaticText( Dialog10, kBOInventoryNameLbl, GetStr10(kBOInventoryNameLbl), -1 ); SetStaticTextStyle( Dialog10, kBOInventoryNameLbl, 3 ); CreateStaticText( Dialog10, kBIistLbl, GetStr10(kBIistLbl), -1 ); SetStaticTextStyle( Dialog10, kBIistLbl, 1 ); CreateListBox( Dialog10, kBIListBx, 30, 15 ); CreateStaticText( Dialog10, kBILengthsLbl, GetStr10(kBILengthsLbl), -1 ); SetStaticTextStyle( Dialog10, kBILengthsLbl, 1 ); CreateEditText( Dialog10, kBILenEditTxt, GetStr10(kBILenEditTxt), 10 ); CreatePushButton( Dialog10, kDeleteSelectedBIsBtn, GetStr10(kDeleteSelectedBIsBtn) ); CreatePushButton( Dialog10, kAddBIsBtn, GetStr10(kAddBIsBtn) ); CreateStaticText( Dialog10, kAddBIBtnLbl, GetStr10(kAddBIBtnLbl), -1 ); CreateCheckBox( Dialog10, kSaveBIAsNewBtn, GetStr10(kSaveBIAsNewBtn) ); {Part of the Dialog handler} CASE biEditItem OF SetupDialogC: BEGIN ReNameNum := 0; SetItemText(Dialog10, kBIInventoryNameLbl, CurrInventory); index := 0; WHILE ((BIList[index + 1].Name <> '') & (index < kMaxBreakInKinds)) DO BEGIN AddChoice(Dialog10, kBIListBx, BIList[index + 1].Name, index); index := index + 1; END; SelectChoice(Dialog10, kBIListBx, 0, TRUE); SetItemText(Dialog10, kLenEditTxt, BIList[1].TailLength); END; {SetupDialogC} kBIListBx: BEGIN GetSelectedChoiceInfo(Dialog10, kBIListBx, 0, endSel, gTempStr); ... END; {kBIListBx} kDeleteSelectedBIsBtn: BEGIN FindNumSelected(Dialog10, kBIListBx, numSelected, selItemArray); GetChoiceCount(Dialog10, kBIListBx, numItems); ... END; {kDeleteSelectedBIsBtn} kAddBIsBtn: BEGIN GetChoiceCount(Dialog10, kBIListBx, numItems); GetSelectedChoiceInfo(Dialog10, kBIListBx, 0, endSel, gTempStr); ... END; {kAddBIsBtn} kOK: BEGIN GetSelectedChoiceInfo(Dialog10, kBIListBx, 0, endSel, gTempStr); IF endSel < 0 THEN endSel := 0; GetItemText(Dialog10, kBILenEditTxt, BIList[endSel + 1].TailLength); GetBooleanItem(Dialog10, kSaveBIAsNewBtn, saveAsNew); ... END; {kOK} END; {CASE biEditItem}

There is a 3rd party solution for $25. "Savvy Sequencer 2" by Josh Benghiat at www.benghiatlighting.com. If you number anything often or different things only once but often, this is a must have plug-in. Many people think they shouldn't have to use a 3rd party plug-in. Well, if you want to do any or all of the above easily, suck it up and get "Savvy Sequencer 2".

I forgot to add it also asks for a destination for where to save the code that constructs the dialog. I copy the text of the saved file into the "SetUpDialog" subroutine of the script/PIO. Unfortunately, the labeling is poor. The first ask is for the destination of the creation script file and the second ask is for the choosing of the command in which to embed the string resources.

Let's try again. First, if Andy Dunning or Josh Benghiat chime in, pay attention. Andy's dialogs are beautiful not only in organization but also in clarity of function. Josh knows more about VS than anyone outside the mothership. Second, I love the DialogBuilder. I cannot conceive of making dialogs without it. Thinking about doing what Raymond does gives me a headache and chills at the same time. However, Raymond also makes exquisite dialogs. Also, Pat, you have my phone number. So... In a separate file for EACH dialog with a 1:1 design layer. No matter how simple the dialog, since simple dialogs seem to grow and expand to encompass new functionality requests. "a." I'm not sure this is the most efficient, but it is the easiest way for me to put it where I want to make it easier think about the organization of my script. I do separate the constants out and place them with the other constant declarations at the beginning of the script, but grouped all together between comments identifying them as for what dialog. Since I make extensive use of the GetPlugInString() call, I use the VS export for both In the resulting dialog: I use the "Embed Resources into VSO/VST/VSM..." button. This wonderful functionality allows you to pick your Script/Plug-in file (vso or vsm) in which to embed the strings that label all the buttons and other proscribed text into the "Strings" resources of the command/plug-in definition; this eliminates having to double enter. (I love this). However, I do comment in the actual string values next to the "GetPlugInString()" calls. Without claiming to be "better", I put the entire creation code, with the exception of constant creation, in a subroutine, "SetUpDialog", and call that routine later in the code. I also make the generated functions below Global and not subroutines of the "SetUpDialog" procedure. {==============================================================} FUNCTION GetStr(ndx :INTEGER) :STRING; BEGIN GetStr := GetPluginString( kTextStrTableID + ndx - 1 ) END; {==============================================================} FUNCTION GetHelpStr(ndx :INTEGER) :STRING; BEGIN GetHelpStr := GetPluginString( kTextStrTableID + ndx + 5 - 1 ) END; {==============================================================} In general, I feel it is better to compartmentalize code functionality, even if the code is called only once. It seems to make debugging easier and the the functionality of the code easier to follow. Also, subroutine effects on global variables are easier to follow. Unless, of course, your subroutines are liberally sprinkled with said global variables. HTH.