ChildPanelOnReturn - child panel returns variables even if it's terminated using PanelOffPanel()

[tpjctrl]

Discovered this today on a very simple set up:

- clickable button object placed on a root panel which holds the following code in the "Clicked" script:

main(mapping event)
{
dyn_float dreturnf;
dyn_string dreturns;
bool closed = 0;

this.foreCol = "_Selected";

ChildPanelOnReturn("test.pnl",
"test.pnl",
makeDynString("$DP:" + $DP),
0,0,
dreturnf, dreturns);

closed = dreturnf[1];

if(closed==1)
{
this.foreCol = "_Transparent";
}

}

- popup with an Exit button which holds the following "Clicked" script:

main()
{
// declare parameters to pass back to the parent panel
dyn_float df;
dyn_string ds;

// set return parameters for confirm button click
df[1] = 1;
ds[1] = "Close";

// close panel, sending parameters back to parent
PanelOffReturn(df, ds);
}

- popup also has a dpConnect on the _Ui_#.ChildPanelOn.PanelName, if that changes ie. another popup is opened, it closes itself via PanelOffPanel()

So effectively if the root panel button is pressed, a popup is opened, the clicked script halts waiting for a return parameter, if Exit is pressed on the popup, dreturnf[1] is set to 1.0 and based on this the root panel object has it's foreCol changes to _Transparent.

The interesting thing is when the popup is opened and closed not via the Exit button, but by opening another popup (triggered from an unrelated object) - this causes the entire:

if(closed==1)
{
this.foreCol = "_Transparent";
}

to be processed, just as if the Exit button was pressed. I know this as I've stuck a DebugN inside the if() above and it throws a message in the log, both when the Exit button is pressed and when another popup is opened / the current one is terminated.

Things get even more interesting if you kill the popup using Alt+F4, then you get a log message related to the dreturnf index being incorrect. This is understandable as the root object script has nothing to process as the PanelOffReturn() never happens. But if you then click on the object again to open the popup and then you open another popup to kill the current one (so repeating the scenario above), the if(closed==1) statement stops working and the root object foreCol remains at "_Selected" with a log message related to the dreturnf index being incorrect (expected behavior). Now the odd thing is that you can revert back to the original behavior by clicking on the object, clicking Exit, then clicking on the object again and killing the popup with another popup, this will again make the object foreCol "_Transparent".

Any ideas why the above is happening? it makes little sense as any other popup effectively kills the current popup via the PanelOffPanel() triggered in the dpconnect CB function, so no parameters should be returned to the root panel object. Imho if the popup is not terminated using the Exit button, then an error should be generated as the ChildPanelOnReturn() doesn't get any parameters back. So if you kill the popup with another popup, or with Alt+F4, error should be shown and object should remain at foreCol "_Selected".

[leoknipp]

I tested it and I tried to understand what you have describe but I didn't manage to get in the situations you have described.
When calling the function ChildPanelOn*Return* functions the script where you have started the function is waiting for a changed value for _Ui_<num>.PanelOff.PanelName and PanelOff.ModuleName. For this purpose the function dpWaitForValue() is used.
If the dp elements are set the information written to _Ui_<num>.ReturnValue.Float and _Ui_<num>.ReturnValue.Text are read.

You can have a look at the CTRL code defined in scripts/libs/panel.ctl.

When using ChildPanelOn*Return* functions you have to check the length of the return arrays before accessing a specific index to avoid errors related to a wrong index.

Maybe you can add a simple example with your panels and a step-by-step procedure to show the problem you have described.

Best Regards
Leopold Knipp
Senior Support Specialist

[tpjctrl]

Hi Leopold,

thanks for your reply, here's a simple way to test this (version 3.16):

1. Create a panel to be used as a PANEL_REF, call it "TT2", create a single small rectangle with a Clicked script defined:

main(mapping event)
{
dyn_float dreturnf;
dyn_string dreturns;

this.backCol = "Yellow";

ChildPanelOnReturn("Test_panels/Test2.pnl" ,
"",
"",
0, 0,
dreturnf, dreturns);

if(dreturnf[1] == 1.0) this.backCol = "Grey";
}

2. Create a panel to be used as a PANEL_REF, call it "TT3", create a single small rectangle with a Clicked script defined:

main(mapping event)
{
dyn_float dreturnf;
dyn_string dreturns;

this.backCol = "Yellow";

ChildPanelOnReturn("Test_panels/Test3.pnl" ,
"",
"",
0, 0,
dreturnf, dreturns);

if(dreturnf[1] == 1.0) this.backCol = "Grey";
}

These are almost identical, but the only difference is the child panel which they open, TT2 opens Test2.pnl, TT3 opens Test3.pnl.

3. Create a panel, call it Test2.pnl and add a single button, change the text on the button to "EXIT" and add a Clicked script defined:

main(mapping event)
{
PanelOffReturn(makeDynFloat(1.0), makeDynString());
}

4. Create a panel, call it Test3.pnl and add a single button, change the text on the button to "EXIT" and add a Clicked script defined:

main(mapping event)
{
PanelOffPanel(myPanelName());
}

5. Create a blank panel, call it Test1.pnl, drag an instance of TT2 onto it so that it sits on the left, drag an instance of TT3 onto it so that it sits on the right. Run the panel in QuickTest mode.

--------------------------------------------------------------------------------------------------------------------

At this stage you should have a panel with two rectangular buttons that are Grey in colour. If you press the one on the left, the button changes colour to Yellow and Test2.pnl is shown. If you press the one on the right the button changes colour to Yellow and Test3.pnl is shown. On Test2.pnl if you press the "EXIT" button it will close itself and the button on the left changes colour back to Grey. On Test3.pnl if you press the "EXIT" button it will close itself and the button on the right should remain Yellow as no values are passed from Test3.pnl back to the button (an error should be logged in the Log saying that dreturnf doesn't exist). At least this is how I assumed it would work...but that's not the case. Both buttons work the same way ie. they open a child panel and on pressing "EXIT" the child panels closes itself and buttons change back to Grey colour.

This is wrong imho as the "EXIT" button on Test3.pnl does not trigger a PanelOffReturn(), but instead a PanelOffPanel, so no dyn_float / dyn_string are passed back to the initiating button, thus an error should be generated.

I'd appreciate if you could run this test and if the above is in fact correct, explain why.

[dbindernagel]

I could reproduce your problem and I think I have an explanation.
Returning values is done by using the _Ui datapoint to store the dyn values.
_Ui_[your UI number].ReturnValue.Float
_Ui_[your UI number].ReturnValue.Text
(e.g. _Ui_1.ReturnValue.Float)

The problem occurs as follows.
1. Click on TT2 and then on Exit: the value "1" is stored in the Float DPE.
2. Click on TT3 and then on Exit: the value "1" remains unchanged in the Float DPE and is used as an return value.

If you set the Float DPE to the value "0" and click first on TT3 it works as expected.

Your problem is that you are not using PanelOffReturn in a panel that should return values. The function "PanelOffPanel" does not write anything to the return value DPEs and they continue to contain their last values.

The function "ChildPanelOnReturn" will check if the panel has been closed by pressing the x button on the window and will return empty dyns as return values. But If you use "PanelOffPanel" this check will not work and the function uses the values from the Ui datapoint.

[tpjctrl]

Cheers dbindernagel, thanks for taking the time to try this. I've had no idea how the parameter passing works, now it's much clearer. I do agree that using PanelOffPanel rather than PanelOffReturn on a panel which has been called using ChildPanelOnReturn is wrong of course, it's just that it doesn't indicate an error and actually works. Because I didn't know how the parameters get passed back to the originating panel, I simply assumed that passing nothing due to the use of PanelOffPanel would trigger a fault in the Log.