cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
DLee65
Level 13

SUITE PROJECT: Property value overwritten by wizard page load

Within my suite / advanced UI package I have a custom dialog with two radio buttons.
RadioButton1: PROPERTY_NAME == YES
RadioButton2: PROPERTY_NAME == NO

I have an event that executes with the OnBegin sequence to set the default value of PROPERTY_NAME. This property according to the log file gets set properly.
However, once the custom wizard page loads I get the following:
PROPERTY_NAME:valid value now '' (two single quote characters indicating an empty value)
'PROPERTY_NAME' value now 'YES'
'PROPERTY_NAME' value now '' (two single quotes again)
UI DLL: Executing user validation > (Group)
'PROPERTY_NAME:valid' now ''
'PROPERTY_NAME' value now 'YES'
'ISCurrentPage' value now 'CustomWizardPageName'

This is fine when my PROPERTY_NAME value is actually YES from the custom event, however, if the condition of the system indicate that the value should be NO, then I want RadioButton2 selected by default. In all cases where the value should be NO the property always gets changed to YES, which is not the behavior I am expecting.

Is there some way around this problem?

NOTE that I have uploaded a sample exe from a new project along with the debug log. This reproduces the same behavior of loading the custom wizard page causes problems. Note that the sample does have some layering problems with the custom wizard page but that does not affect the results.
NOTE2: I am testing on Win7x86 Professional. I am not certain if this affects the results.
Labels (1)
0 Kudos
(5) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

I think I might be reproducing this problem, but there is also a minor mistake in your example. If I add two radio buttons to the InstallationWelcome dialog, giving them property values of PROP==one and PROP==two respectively, and add a label with property PROP (clearing out the text so it shows the property), then it follows my buttons exactly. If I then set PROP to two in the Property Manager, it still initially shows up as one. However if I add a button to this page, and move it up before the radio buttons, it initially shows up as two.

I believe the problem occurs when we set focus to the first focusable control on the page. If the first control is a radio button, it acts as though you had clicked the radio button. So as a workaround, if you can add a button before it, you may be able to avoid this behavior. I'll see if I can come up with a better workaround, but I think this may require a code-based solution for the general case.

(The minor mistake in your example is that both of the labels conditionally shown refer to the same string: "You have selected Option Two".)
0 Kudos
DLee65
Level 13

Hmm, interesting solution. I am not sure how I can integrate a button control into the current UI design.

The button has to be visible for this to work, so just adding a control with a condition to make it not visible does not work.
I cannot even replace the integrated 'back' button with this because the UI does not let me place anything in the bottom button area.

So my only current solution is to:
1. live with the behavior
2. Add an extraneous button control to the UI that does nothing. I am not sure I can sell this to the people who approve the UI design of my work.
3. Hiding it behind the labels does not work either. Once I click on the wizard page the button pops to the front.

As to the string value, yeah, it probably occurred when I copied the control, but the string value itself never changed the outcome of the two option controls. I was looking at the debug log more than the actual UI controls themselves.

Thanks for looking at this Michael. I now understand why the behavior occurs.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

Yeah, I get the conundrum. I've prototyped a code-based fix as well, but along the way I ran across a lot of posts from people who complain about equivalent behavior in MFC and Windows Forms apps. So on the one hand, it's at least somewhat "by design." But on the other hand, in those cases you often have a lot more direct control over how you fix things, so in the Suite UI we have to address this for you, or you are stuck with workarounds like a check box that enables the radio buttons, or even setting the Style option WS_TABSTOP on a preceding label. (Note that the last results in run-time behavior that may confuse the occasional keyboard user, as the label does not indicate that it has focus.)

The code-based fix I prototyped will focus the first control that is a tabstop and is either a "checked" radio button, or is not a radio button. Does this approach sound like it would address your needs? Like adding a button, this also resulted in keeping my test showing "two" in the scenario I described. But if the property is initially set to "three", it will run out of other options and focus the first radio, resetting "three" to "one"; setting WS_TABSTOP on a label handles this case of no radio selected, but has the same focus caveat I already mentioned.
0 Kudos
DLee65
Level 13

That sounds like the behavior I am looking for. If my property is set for a particular radio button, I want it to honor that first, if property does not exist or is a different value than described for the objects then select the first item.

I am curious, how does the UI handle the 'back' sequence? If the user changes the selection and clicks next and then back, I believe the option the user selected is still selected, even if it is not the first object.

Thank you.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

The relevant code is shared, so it's not requesting anything different. Yet it does behave differently. I've see similar effects when the radio buttons aren't first and I tab around the dialog, eventually activating them - namely the first time it will check the radio button that gets focused, but future times it focuses the checked radio button. Magic. Or voodoo.
0 Kudos