vsoWidgetPopup not unique to different instances

[Jayme McColgan]

hey,

 

so I'm using vs.vsoPrmName2WidgetID() and vs.vsoWidgetPopupAdd() to fill out a dropdown based on other fields so the values in the list should be unique to the current instance of the PIO. it seems to change ALL instances of the PIO and not just the one that I'm currently working with. 

 

is this an expected behavior or should vs.vsoWidgetPopupAdd() only be updating the current instance of the PIO?

 

Here's an example of my code...

 

ok, parmid = vs.vsoPrmName2WidgetID('', 'Product')
	vs.vsoWidgetPopupClear(parmid)
  
	vs.vsoWidgetPopupAdd(parmid, f"None", f"None")
	vs.vsoWidgetPopupAdd(parmid, f"-", f"-")
	for i in range(len(mylist)):
		vs.vsoWidgetPopupAdd(parmid, f"{mylist[i][0]}", f"{mylist[i][1]}")

 

[Jesse Cogswell]

For this to work, you want to make sure that you are doing widget stuff in the Widget Prep event rather than the InitXProperties event.  This is one of those things not covered in the documentation, but the widget prep event (event 41, usually named kObjOnWidgetPrep) will run anytime the object is selected, so it will automatically update with any pop-up information when the object is selected.  I'm not super great with Python, but I can send you examples in Vectorscript if it would help you.

[Jayme McColgan]

I was just coming back to say that I think I figured it out by repopulating the list when event 41 is called. I couldn't remember the webpage where it says what Event 41 does so I tried it anyways. lol

 

Def start():
  theEvent, theButton = vs.vsoGetEventInfo()
  recname = vs.GetName(recordHandle)

  if theEvent == kObjOnAddState:
    vs.vsoStateAddCurrent(PIO_handle, theButton)

    elif theEvent == 41:
      quick_update() ### Populates dropdowns with correct info

      elif theEvent == kResetEventID:
        goodguy = check_license()
        if goodguy:	
          mainloop()
        else:
          #vs.AlrtDialog(str("hmmm... you can't sit with us"))
          lockedout()
    	vs.vsoStateClear(PIO_handle)
    
    return None

 

 

[MullinRJ]

Event 41 is kObjOnWidgetPrep

 

Raymond

[JBenghiat]

And just to clarify, widgets just display an object’s data in object info when the object is selected. Technically the popup is the same for all the instances, you’re only changing what’s visible when each instance is selected. 
 

In other words, don’t count on widgets for data storage, only data display. 

[Jayme McColgan]

On 6/10/2023 at 12:38 AM, JBenghiat said:

And just to clarify, widgets just display an object’s data in object info when the object is selected. Technically the popup is the same for all the instances, you’re only changing what’s visible when each instance is selected. 
 

In other words, don’t count on widgets for data storage, only data display. 

that's what i was afraid of... so is there a safer way to dynamically populate a popup? i haven't run into any issues yet but I'm still kind of early in my testing.

[JBenghiat]

I found that the MVC software model is useful when thinking about PIO’s. The OIP and drawing represent the view, and your parameters hold the data. Your code is the controller. 
 

So, for a pull-down, you’re creating a view of the available options for the selected objects at the moment of selection. That widget’s sole purpose should be for user interaction. At that point, you shouldn’t care about unselected objects, because the user can’t interact with them. 
 

You do have to take multi-selection into account, which only comes into play if all the selected objects are the same type. If each PIO has different possible menu options, you either have to include all the options for all selected PIO’s, or gray out the pull-down. 
 

In terms of the data, if the pull-down is an also parameter, the field will only store the selected value. If it is just a widget, it stores no value. 
 

Where you would get into trouble is if, for example, you have another command that creates a report based on ALL the options in the pull-down. (Or a PIO button that presents a dialog that accesses all the values, etc). If you use the pull-down values, you are using the UI View as Data, which is bad design. The better option would be to store the data in a hidden parameter (JSON strings are great for this), and think of the widget prep event where you transfer the data to the view. 

[Jayme McColgan]

On 6/12/2023 at 1:53 PM, JBenghiat said:

So, for a pull-down, you’re creating a view of the available options for the selected objects at the moment of selection. That widget’s sole purpose should be for user interaction. At that point, you shouldn’t care about unselected objects, because the user can’t interact with them. 

conveniently enough this is how I treat all my plugins that have dropdowns. most of my "dynamic" plugins hold all the required data in a JSON file that lives in the user folder (which gives the user the ability to add/edit the data in a dialog box) I'm slowly going through and updating my plugins to support dynamically updating popups based on that JSON file. what I need to test is when a user has different options in that JSON file than another user and handle that accordingly.

 

I'm currently learning how to make my plugins as dynamic as possible and try not to include any hard values in my code.