MullinRJ

Good morning, @Pat Stanford . Yes. You, me, and _c_, (and Tui). I just reread the thread and at the end I wrote that it works in VW 2020, but not in earlier VW versions. Also, you cannot export a VW 2020 file back to earlier versions with a popup field defined. Well, you can, but the popup field type will not work anymore. So, @Jesse Cogswell , the question to you is, "What version of VW are you using?" Raymond PS - Thanks for the memory jog, Pat. I'd almost forgotten about that issue.

Hi David, Yes, I have seen the 6 digit rounding when using Python for PIOs. The OIP will display 10 digits, and VS functions like Concat(pRealPIOParam) will display 15 decimal places when they convert Reals to Strings. Example from a VS PIO script I am currently working on showing 15 significant digits: ControlPoint01X= 0 ControlPoint01Y= 15.8676746286034 ControlPoint02X= 0 ControlPoint02Y= 26.1038951010443 I do not have a workaround for Python. Perhaps someone else does. Raymond

Hi David, I think it's a "feature" of Python, and not a limitation of VW. In VectorScript you get 15 decimals displayed for REALS. Is there a way to declare your variables as double precision REALS before you use them? If so, I'm not sure how you would do that for Control Point variables in a PIO. Raymond

The Script Function Reference can be found in your VW application VWHelp folder undoer VWHelp > Script Reference. The same documentation is also available online at https://forum.vectorworks.net/index.php?/announcement/14-developer-wiki-and-function-reference-links/ HTH, Raymond

Just for variety, here is a vector approach to do the same thing. It's just a little more code than Julian's scaling approach, and to the original request it will increment every line on visible layers. If you want the script to only work on the Active Layer, then change the last "2" to a "0" in the following line: ForEachObjectInLayer(GrowLine, 0, 0, 2); { All objects, Shallow, Visible layers } ForEachObjectInLayer(GrowLine, 0, 0, 0); { All objects, Shallow, Current layer } Procedure GrowLinesByInc; { Grow each line on visible layers by a user input length. If the user input is positive } { the line length increases, if it is negative, the line length decreases. } VAR dLength : REAL; function GrowLine(H :Handle) :Boolean; { Use global variable "dLength" to calculate a vector in the same direction } { of each line and add half of it to each end. } Var P1, P2, Vdelta :Vector; Begin if (GetTypeN(H) = 2) then begin { type 2 is a LINE } GetSegPt1(H, P1.x, P1.y); { start point of line } GetSegPt2(H, P2.x, P2.y); { stop point of line } Vdelta := UnitVec(P2 - P1) * dLength/2; P1 := P1 - Vdelta; { move away from center } P2 := P2 + Vdelta; { move away from center } SetSegPt1(H, P1.x, P1.y); { new start point of line } SetSegPt2(H, P2.x, P2.y); { new stop point of line } end; { if } end; { GrowLine } BEGIN dLength := RealDialog('Length increment?', '0'); if not DidCancel do ForEachObjectInLayer(GrowLine, 0, 0, 2); { All objects, Shallow, Visible layers } END; Run(GrowLinesByInc); Raymond

If there's no way to add a 3D fillet by script, you can always do a solid subtraction. Yes, it's a lot more work, but it is doable for simple shapes. Raymond

Hi Julian, That is not what I was hoping for. CreateControl(), option 2, creates a button to select a color from a system color palette. I was hoping to set the color of a PushButton, so I guess I mis-interpreted the function's use. Thank you for clarifying it. Raymond

It is my understanding, flawed as it is, that "vst" commands apply to TOOLS, where "vso" commands apply to OBJECTS. There may be some crossover, so like Sam, I await someone else's answer. Raymond

Has anyone ever gotten SetColorButton() to work? It is advertised as being introduced in VW 9.0, but I could not get it to affect a color change on a Modern Dialog PushButton in VW 2019, VW2014, or VW 2009, which is as far back as I can test without switching computers. Is it designed to work on a different kind of control? Documentation is sparse in both the HTML Script Function Reference and the online Developer's WIKI. If no one answers to the affirmative in a day I'll file a bug. Thank you, Raymond

So, what types are the objects? Place this just before or after the SubtractSolid() command. AlrtDialog(concat( bigObject, ' ', GetTypeN(bigObject), chr(13), smallObject, ' ', GetTypeN(smallObject) )); Are they what you think they are? If so, then I got nuttin' without seeing some code. Raymond

Have you verified your handles are correct inside the PIO? Without seeing any code that is my only guess. Raymond

Hi @Jiajing , I just did some quick testing of your script. There are some side effects you need to be aware of. Short answer: vs.ForEachObjectInList() and ForEachObject() work differently. The first procedure walks through a list of handles where you supply the first object in the list. The second procedure walks through every object in the drawing. You change the selection state when you hide or gray objects by changing their class visibilities. I am assuming that is what you are doing. Your use of vs.ForEachObjectInList(AssignClass, 2, 2, vs.FInGroup(vs.GetParent(Dummy))) uses option 2, 2 which means Selected and Deep. If your group objects are grayed because they are in a Hidden Class they become unselected. Your script is using the SEL criteria to process objects, so unselected objects will not be processed as you walk through the list. If your groups are grayed another way, you'll have to see if this is still true. Notice your LW and color are set because ForEachObject() works differently from vs.ForEachObjectInList() and does not need the outer group to be selected to see selected objects inside that are selected. If you change your settings to vs.ForEachObjectInList(AssignClass, 0, 2, vs.FInGroup(vs.GetParent(Dummy)) you can enter grayed groups. This may not work exactly as you'd like so you may have to play with it. HTH, Raymond

@Jiajing In Python you have to put "()" after VS function calls that do not have parameters. These are two examples I spotted in your code: vs.DSelectAll() Dummy = vs.LNewObj() That should clear your syntax problems. Raymond

You're welcome, Sam. Sometimes I get lucky. Raymond

Sam, This is not a definitive answer, and I've only played with it for a few minutes, but you may want to see if this gets you close enough so you can do your dastardly deeds. Do you need to make a distinction between your Plug-in being CUT vs. DELETED? If so, then stop reading HERE, as this won't help you. If not, then try adding a line at the end of your 44 event (kObjOnAddState) to test the state of "theButton" variable that's returned from the first line in the 44 event. It's going to take some sussing out on your part to see if it meets your needs. If you only get the 'Am I DeLETeD?' message when you expect it, then substitute the AlrtDialog() call with your cleanup procedure. vsoGetEventInfo(theEvent, theButton); case theEvent of ... kObjOnAddState: begin { 44 } theButton := vsoStateAddCurrent(PIOHand, theButton); if (theButton = 14) then AlrtDialog(concat('Am I DeLETeD?')); end; { 44 } end; { case } HTH, Raymond

Thank you, @_c_ . You always say the nicest things. 😊 There's something about dialogs, ... , and vectors. I just can't seem to resist. Raymond

Hi Pete, Because a basic toggle script requires no variables, it can be reduced to one line SetPref(14, not GetPref(14)); but there is nothing wrong with placing that line inside a PROCEDURE definition and using a RUN() statement to execute it. You can use this, or my, format to create toggle scripts for any of the boolean VW Preferences. A list of preference numbers can be found online on the Developer Wiki in the Appendix. Here's a link: https://developer.vectorworks.net/index.php/VS:Function_Reference_Appendix#apppref This is not the complete list, but it's pretty inclusive. Just substitute a different number for the one in the script and save it to a new VSM command. I've got 14 of these loaded in my workspace and most have a HotKey for quick access, and the one you just posted is one of them. Building these is one of the quickest ways to make VW work as fast as you can think. They are real time savers. HTH, Raymond

I modified my previous post. Neither version of the script works in VW 2016 as a menu command, but the longer version does work when run in a Script Palette. The longer script works in VW 2017 (and newer). The original script (shorter one) works in VW 2018 and newer. Raymond

Pete, Good it works. You must be using VW 2020. If you're planning to use it in VW 2017 you will need a slightly longer script. I wrote the above script in VW 2020, and it worked perfectly, but I tried it in VW 2017, and I have to also toggle the Unified View OFF and ON to make the screen redraw properly. You're on a PC, I'm on a Mac, so they may work differently, but if you don't get instant redraw then you can modify the script to the one shown below. The last two lines toggle Unified View twice to force the screen to redraw. This seems to be necessary in VW 2017, but not newer versions. The script above works as desired in VW 2018, VW 2019, and VW 2020. Here's a modified script that will work in VW 2017 (and newer). Neither version works in VW 2016. I have not tried it in versions earlier than VW 2016. { This script will toggle the Stack Layers (Unified View) option to display 2D objects } { and BEEP when the option is active (2D objects are visible). } { 24 May 2020 - Raymond J Mullin } SetPref(95, not GetPref(95)); if GetPref(95) then SysBeep; { Toggle Unified View to update screen redraw } SetPref(94, not GetPref(94)); SetPref(94, not GetPref(94)); Raymond

Hi Pete, I believe 95 is your number. That is the VW Preference number for the action you want. Here's a script that will toggle it. If this is not the action you desire, write back. Do you need help creating the Menu Command? I can post that, too, if it will help. { This script will toggle the Stack Layers (Unified View) option to display 2D objects } { and BEEP when the option is active (2D objects are visible). } { 24 May 2020 - Raymond J Mullin } SetPref(95, not GetPref(95)); if GetPref(95) then SysBeep; Raymond

Michael, Place an AlrtDialog() command at the front of your Event Loop in your main program like this: BEGIN result := GetCustomObjectInfo(PIOName, PIOHand, recHand, wallHand); vsoGetEventInfo(theEvent, theButton); AlrtDialog(concat('Top of Event Loop: ', theEvent, ' ', theButton)); { usually commented - used for debug } case theEvent of ... end; { case } END; Run(MyPIO); Comment out the AlrtDialog() for normal running. This will show you exactly what PIO events you are receiving. Raymond

Short answer - NO! Michael, Script Palette scripts and Plug-in scripts are handled completely differently. Scripts run from a Script Palette only run when you click on them, meaning once. Plug-in objects run when VW tells them to, which is in response to the selection state of the Plug-in and the events that VW "throws" at them. The only event where you are supposed to create geometry is inside event 3, the ResetObject event*. And by the way, your object can run way more than 3 times in a row under the right circumstances. Every action in your drawing has the potential of generating a series of events that a Plug-in object might handle (Placing a new PIO; Selecting; Duplicating; Moving; Rotating; Editing the OIP; Editing a Symbol that is in your PIO; Deleting; Cutting; Pasting; Moving a ControlPoint; .... I'm sure there are actions I missed, but do you get the idea?), and different PIO types have different event sequences. Point objects differ from Linear objects, which differ from Rectangle objects, which differ from Path objects, etc. In addition to handling events that VW generates, you can issue events of your own, like ResetObject again. You can also enable or filter events that your plugin "sees", or is aware of. This is done in event 5 (ObjOnInitXProperties). The combination of events and user actions is quite large. Be prepared to be stymied a lot in the beginning. Oh, you're already there. That's good, it means you're trying things. It also means you're human. I'd hate to think this was easy for you. 😉 No disrespect intended. You should probably start taking notes of what events you receive for the actions you are performing. It's the best way to get an overall picture of the way your code is setup and how it responds. Put an Alert Dialog at the front of your code and display every event that comes in. Write them down. Patterns will emerge and your questions will become more detailed. Welcome to the bottom of the rabbit hole. The real adventure is climbing out. Raymond * If you draw outside of event 3, your objects will NOT be part of the plugin and may "litter" your drawing. This may be your intention, so it can be done, but you must do it carefully.

Michael, Use vsoAppendWidget() { adds widget to the end of the list } or vsoInsertWidget() { adds widget before "paramID" } Raymond

Hi Michael, The PIO main loop processes EVENTS, usually in a CASE statement. From that loop all other routines get called. Drawing your geometry is only done when the kResetObj event is issued. There are only a few events you need to look for. The reset object event, kResetObj (3) is the event where you draw should almost everything. Actually it deletes all existing geometry, then redraws it again based on the state of your parameters. Like a Modern Dialog, there is a setup event, kObjOnInitXProperties (5), where you do setup stuff, and a button event, kObjOnObjectUIButtonHit (35) where you do stuff when buttons get pressed. If you've ever programmed a Modern Dialog, this works in a very similar fashion. I'm sure this is still too vague. Other people may describe it better than I, so take two aspirin and write back, the fun has just begun. Raymond

Good analogy. Be prepared to hold your nose a lot and swallow your Cod Liver Oil, like a good little programmer. After you download the SDK look for this file: /SDK/SDKVW(######)/SDKLib/Include/Kernel/MiniCadHookIntf.h It's full of headaches you never thought possible, but it's full of answers, too; probably preceded by lots of questions. Bottom's Up 😝, Raymond