Jump to content

"Conditional" hidden fields in Custom Tools


Recommended Posts

I've been scripting some custom tools, and it's freakin' awesome.  Learning a lot.


Now, I want to figure out how to make some OIP fields hidden based on another field's contents.  For instance, in the "Lighting Device" tool, when you check "Set 3D Orientation", two fields appear to enter that info, and the disappear when it's not selected.  I would like to do this in my tool, but I haven't been able to find documentation for it.  I'd love to be able to do this based on a text or integer value, but if it's just Boolean, I could use that for some things, too.  


For instance, for an integer value, it could display only 5 fields if the number of ports on an Opto-Splitter was entered as "5".  Or, for a data cable could switch between Universe and Network depending on some other selection.  


I know that it's technically possible based on Lighting Device and Cable Tools, but it might be something that is only available to VW.


Any assistance would be greatly appreciated!


Link to comment

Sam -


Assuming your custom objects are event-enabled, use the following calls to make parameters visible/invisible or enabled/disabled:






"BOOLEAN" can be "TRUE"/"FALSE" or a stated condition (such as PParameter >= 6).


Does that help??

Link to comment
On 4/26/2017 at 11:48 PM, Pat Stanford said:

And if it is not event enabled you can use:


PROCEDURE   SetParameterVisibility
(   inPlugin :HANDLE;
    inParameterName :STRING;
    inSetVisible :BOOLEAN


The SetParameterVisibility worked for me about 95% of the time.  For some strange reason, sometimes parameters don't change visibility on the first change of another parameter.  On the second selection of the same parameter to the same value, the visibility works correctly.  Weird.

Link to comment
11 minutes ago, Pat Stanford said:

Try adding a ResetObj or two into the PIO and see if that will do what you need. It sounds like the changes are being made after the PIO has drawn and are not being reflected until the next reset.


That did the trick.  Thank you so much!  Onward we go.  Now, if VW would just fix the years-old bug affecting the Object Context menu, everything would be peachy!

Link to comment
On 5/4/2017 at 5:27 PM, Pat Stanford said:

What bug with Object Context Menu?


I have several dozen scripts which I've written to greatly speed up my workflow doing short tasks which I may do 100 times an hour (mostly related to lighting fixture info, custom move and duplicate tools, custom selection tools, etc).  They are divided into several folders in the object context menu.  At some point, most of them just stop working.  Currently, not a single one works.  This was confirmed by VW to me some time a year or two ago.  It's been happening since I believe 2014 and kills my productivity.  Has almost made me question upgrading further.

Edited by SamIWas
Link to comment
15 hours ago, Pat Stanford said:

Do they come back when you restart VW? Restart the computer?


Is there anything you can do that specifically makes them stop working?


Are you willing to share any of them so some of the experts here can take a look and see if anything jumps out at us as being a problem?


Restarting Vectorworks and the computer has no effect.  Once you get a certain number of scripts or folders in the Object Context menu, things just start breaking down.  At first, just the first 20 or so scripts would work, while anything after that would fail.  A week later, only ten would work.  Now, nothing.


Here is a copy of a simple script which creates a popup window to enter a channel for selected fixtures.  For me, it's just much faster than opening "Number Instruments" or even double clicking on the fixture and entering the info in the edit fixture window.  I used it frequently, then it just stopped.  And so did everything else in the menu.  


I know the menu used to work, because I used to have an extensive Object Context menu.  Now, I can't even use it.


I have a support ticket from Service Select Support last year:


After further investigation, I have found that this is something that has been submitted to our engineering team. We are currently looking into the issue but we haven’t narrowed down the exact cause yet. I have added your example to the issue, which may help the engineers. Hopefully this issue will be addressed in a future update.


And then again this year:


This issue doesn’t appear to be fixed yet, but I am having a hard time replicating it in 2017. Can you send me a copy of your workspace file so I can test it on my machine?


Edited by SamIWas
Link to comment
39 minutes ago, Pat Stanford said:

Have you tried removing them from the workspace and then adding a few back and see what happens?


Yep.  On 2014, 12015 and 2016, I rebuilt my workspace several times and always had the same issues.  I started 2017 building my workspace from scratch, and barely made it halfway through before it started failing.


Every script I write is tested first in a different menu before moving it into the Object Context menu, so I know the scripts themselves function correctly.

Edited by SamIWas
Link to comment

What exactly is a "chunk"?


Is that 63 submenus total over the entire workspace, or per top menu?  I don't know why you'd have 63 submenus per top menu, so I assume it's over the entire workspace.  


If so, it's certainly possible that I hit that limit.  I think I had only 8-12 submenus added.

Link to comment

Pretty sure it's 63 in the entire workspace.


A menu chunk has an ellipsis (…) like View > Set Lighting Options…   




a submenu.


Not positive about the ellipsis.  I only know this because (1) @PatStanfordtold me and (2) from context reading of the vector script function to execute a menu command.


DoMenuTextByName('Standard Views',8); will change the view to the 8th choice in the Standard Views "chunk" (Right Isometric –unless you've edited the standard workspace to change the order of the views.)


As far as I know, "chunk" is not a common coding term for pull down menu groupings.


Link to comment

When you create a menu item from scratch, it can be standalone or exist out of an amount of submenu's (chunked).

The great thing about the latter one is that, similar menu commands (e.g.: add X, edit X, remove X) can be grouped into one menu instance in the workspace manager, but appear as 3 menu items to the user when added to the workspace, as mentioned the DoMenuByname should default to chunk 0 for standalone menu items, and to the chunk identifier in case of a chunked menu group.

Edited by Hippocode
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...