xTuple.com xTupleU Blog & News Customer Support

Call Function from Parameter Widget object selection

Is it possible to fire off a function from a PW object is selected or clicked in the same way it can be done with a standard screen GUI object like a button in a window?

For example, something like this:

mywindow.setParameterWidgetVisible(true);
var _pw = mywindow.parameterWidget();
_pw.appendComboBox(qsTr("Site"), "siteid", siteqry);

_pw.siteid.clicked.connect(DoSumthin);

function DoSumthin(){
 
      blah blah blah
 
 mywindow.close();
}

At this point, I do not believe there are any signals on a parameterWidget based around changes to a filter inside the parameterwidget. It can even be quite difficult to identify that a filter called “Site” has been appended to the widget.

This is something I have looked for from time to time, and is seen as useful. But not implemented as yet.

I added [26953] a while back as an idea on how to approach this. Never explored implementing it, though.

Yes - that incident looks like it would resolve many of the requirements.

If you’re making a screen based off of the display class window (which it looks like you are, given the .setParameterWidgetVisible call), you can get around this by using the optionsWidget functionality of the display class, where you add your own widgets instead of using parameterWidget. I attached some sample files to illustrate how this works.

optionsWidget.js (1.6 KB)
custom-optionswidget.mql (142 Bytes)
optionsWidget.ui (5.0 KB)

Is it possible to add a separate object / checkbox to the same display class window that contains a visible Parameter Widget? It does not necessary need to aesthetically pleasing, just functional - like off to the side, at the top, etc?

Yes, the optionsWidget is the vehicle for doing that. You need to implement reading/addng the params in setParams, they get appended to the parameters from the existing parameterWidget.

OK, but it’s one or the other. You have to ditch and replace the Parameter Widget in the window, correct? Then use the OptionsWidget to manually recreate or emulate the functionality of the PW. While the sample code included does provide an excellent roadmap for doing this, the needed functionality for here is actually very basic.

It started with this post in the Partners Only section - https://forums.xtuple.com/t/alternate-reports-from-a-open-custom-window/6299/4

I pulled it out here as the need to react to PW object selection seemed like a more generic question.

But, in the end, I just need to be able to switch a target report from an already open custom window.

It might be easier just to clone the window, change the report referenced, save it under a different name and attached it to a separate menu item.

Not elegant at all, but pretty simple.

You can certainly intercept the Print or PrintPreview buttons and choose your report at that point based on a parameter.

Disconnect the core signal from those buttons and then attach a new custom signal which points to a function that sets the ReportName based on a parameter widget value.

Hey now that is not a bad idea. Thanks! Will give it a try.

OK. I am trying to do the core disconnect on print, but not sure exactly how to do it with the Parameter Widget object.

Trying this:

toolbox.coreDisconnect( mywindow.findChild("_print"), "clicked()", mywindow,"sPrint()");

But it is not working. Do you know the right way to intercept the Parameter Widget print button?

There are several ways to solve this problem. Here are the ones I could think of:

  1. As David B suggested, setParameterWidgetVisible(false) and use the options widget functionality. With this approach you the script writer take full responsibility for creating all of the necessary widgets and setting all of the MetaSQL parameters. Embedding a parameter widget into the options widget doesn’t change the core problem — pulling the info you need out of the parameter widget.
  2. Wait until 26953 is addressed, which will be a while.
  3. Read the parameter widget code carefully to find a way to get the widget and connect a JS function to one of its signals. This is possible; it’s hard and fragile but possible.
  4. Intercept the Print and Preview buttons. As Stefan observed, this is harder than it sounds. The Display class uses a level of abstraction internally that allows it to be used flexibly. That same abstraction makes simple tasks like this hard because they violate the initial assumptions about permitted behavior.
  5. Add a separate checkbox as Stefan suggested. To do this, you’ll have to find one of the layout objects on the window, create a checkbox, insert it into the layout, and connect it to a function that changes the report. You don’t need the options widget to do this and you don’t need to modify setParams().

Adding that ugly-but-useful checkbox seems to be the easiest:

// add a checkbox to the customers list to control column alignment
var pw        = mywindow.parameterWidget();            // get the parameter widget
var pwLayout  = toolbox.widgetGetLayout(pw);           // get the layout that holds it
var _reportCB = new XCheckBox("_reportCB", mywindow);  // create the checkbox
pwLayout.addWidget(_reportCB);                         // add the checkbox to the layout
_reportCB.toggled.connect(sToggle);                    // make it do something

// a function to do something
function sToggle(pChecked)
{
  var hitem     = mywindow.list().headerItem();          // get the header
  var numberCol = mywindow.list().column("cust_number"); // get the column number

  if (pChecked)
    hitem.setTextAlignment(numberCol, Qt.AlignRight);
  else
    hitem.setTextAlignment(numberCol, Qt.AlignLeft);
}

None of this is magic. It’s all attention to detail and not making assumptions.

Gil

Excellent. Thank you very much Gil. I will try utilize some of the CheckBox code above.