SamIWas Posted April 27, 2017 Share Posted April 27, 2017 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! Quote Link to comment
C. Andrew Dunning Posted April 27, 2017 Share Posted April 27, 2017 Sam - Assuming your custom objects are event-enabled, use the following calls to make parameters visible/invisible or enabled/disabled: vsoWidgetSetVisible(PARAMETER NUMBER,BOOLEAN); vsoWidgetSetEnable(PARAMETER NUMBER,BOOLEAN); "BOOLEAN" can be "TRUE"/"FALSE" or a stated condition (such as PParameter >= 6). Does that help?? Quote Link to comment
Pat Stanford Posted April 27, 2017 Share Posted April 27, 2017 And if it is not event enabled you can use: PROCEDURE SetParameterVisibility ( inPlugin :HANDLE; inParameterName :STRING; inSetVisible :BOOLEAN ) ; Quote Link to comment
SamIWas Posted April 28, 2017 Author Share Posted April 28, 2017 Thanks, guys. I will give those a try and see what happens. My tools are basically "point objects" which draw some shapes and add some text based on OIP input. I don't know what an "event enabled" objects are, so I can't answer that question. Quote Link to comment
SamIWas Posted May 4, 2017 Author Share Posted May 4, 2017 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. Quote Link to comment
Pat Stanford Posted May 4, 2017 Share Posted May 4, 2017 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. Quote Link to comment
SamIWas Posted May 4, 2017 Author Share Posted May 4, 2017 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! Quote Link to comment
Pat Stanford Posted May 4, 2017 Share Posted May 4, 2017 What bug with Object Context Menu? Quote Link to comment
SamIWas Posted May 6, 2017 Author Share Posted May 6, 2017 (edited) 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 May 6, 2017 by SamIWas Quote Link to comment
Pat Stanford Posted May 6, 2017 Share Posted May 6, 2017 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? Quote Link to comment
SamIWas Posted May 6, 2017 Author Share Posted May 6, 2017 (edited) 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: Quote 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: Quote 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 May 6, 2017 by SamIWas Quote Link to comment
Pat Stanford Posted May 7, 2017 Share Posted May 7, 2017 Have you tried removing them from the workspace and then adding a few back and see what happens? Quote Link to comment
SamIWas Posted May 7, 2017 Author Share Posted May 7, 2017 (edited) 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 May 7, 2017 by SamIWas Quote Link to comment
Pat Stanford Posted May 8, 2017 Share Posted May 8, 2017 @michaelk I seem to remember you figuring out something about a 256 item limit in all of the menus? Do you know anything or am I misremembering? Pat Quote Link to comment
michaelk Posted May 9, 2017 Share Posted May 9, 2017 Pat, that was a long time ago, but in 2011 you could have 63 submenus and 127 chunks. But it might be more now. Quote Link to comment
SamIWas Posted May 9, 2017 Author Share Posted May 9, 2017 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. Quote Link to comment
michaelk Posted May 9, 2017 Share Posted May 9, 2017 Pretty sure it's 63 in the entire workspace. A menu chunk has an ellipsis (…) like View > Set Lighting Options… or 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. Quote Link to comment
Hippocode Posted May 10, 2017 Share Posted May 10, 2017 (edited) 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 May 10, 2017 by Hippocode Quote Link to comment
Recommended Posts
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.