Reset variables and a few other issues

[Tom H.]

Using latest version of SB7.4...

I have a custom dialog where the user enters a registration code, and based on the code, it determines the type of install (demo, single user, multi-user, etc.)

Based on the install type, subsequent dialogs are shown or omitted, and an install type specific readme file is displayed. Four possible readme RTF files are included in the project as support files, and the readme dialog "Readme text" value in the script is set to: "local://%TMPDIR%\%READMEFILE%"

My current issues:
1) The script seems to lock into the first value that %READMEFILE% is set to, ignoring subsequent changes if I back up and change the registration code. E.g, if I start as 'Demo' go forward, then back up and switch to a valid reg code, the readme dialog still displays the demo RTF, even though OutputDebugString out verifies that the value of %READMEFILE% was changed to the proper RTF file in EVENT:ONUPDATE of the registration dialog.

2) Apart from the readme dialog display not resetting to the current value for %READMEFILE%, using the print button on that dialog always prints the License Agreement, not the contents of whatever readme is actually being displayed. The name of the printed file comes out as 'readme.pdf' (I'm printing to a PDF driver, obviously). Printing on the actual license agreement dialog does print the license as 'license.pdf'. The license dialog text is set to "local://%TMPDIR%\%PRO_LICENSE%"

3) Is there a way to trigger something like EVENT:ONREOPEN when going back to the registration code dialog? Currently, both INIT and REOPEN only fire when going forwards, so I have to click back two dialogs in order to trigger the UPDATE parsing logic again. If I just go back the one step no events are fired even though I change the registration code value.

Thanks in advance,
Tom

[linder]

Hi Tom,

I have attached a demo project to display three different RTF files. If you go back to the selection dialog to select another RTF, the "Next" button will always refresh the Readme dialog.

It also prints the RTF okay and does not print the License Agreement here.

BTW, only the 'Next' button fires events.

Does this help?

Friedrich

[Tom H.]

Thanks for the example! 'Refresh next dialog' is the magic line, as per the help resources are cached the first time they are read.

I can still replicate the readme printing the license, though. Sequence is:
Reg code (now has refresh next dialog)
Readme (displays okay, click print: okay)
License (displays okay, click print: okay)
Back to Readme (displays okay, click print: prints license, not readme)

If I go back two steps so as to trigger the 'refresh next' again, then the readme prints correctly. Bouncing back and forth between printing the license and readme seems to lock in to one file. It's very consistent.

I've been able to print the license from the readme, as well. I tried putting refresh into the "IF %_SB_DIALOGID%" both of those dialogs (only line, not in an event trap), but it still didn't help unless I backed up multiple steps.

It seems it really needs a way to refresh a dialog on the equivalent of event 'go back' or something.

Thanks,
Tom

[linder]

Hi Tom,

Would it be possible for you to manipulate my example .sb7 in such a way that it demonstrate this incorrect "License Agreement" print behavior?

Thank you for your help!

Friedrich

[Tom H.]

Here you go. Your demo of "refresh next" use with the mods.

1) Run it
2) Next your way to the license dialog
3) Go back a step to the readme
4) Print the readme

It prints the license file from the readme display every time here.

Btw, the issues with events and going back and changing the text entry field are actually more important to me at the moment -- I can live without a print button whereas the other potentially impacts end users.

Thanks again for you quick help with this!

Tom

[linder]

Hi Tom,

Wow, yes! I can reproduce this here. Item in review.

Thanks so much for bringing this to my attention.

Friedrich

[Tom H.]

Any thoughts on how I can trigger events/actions if the user goes back and changes a text entry field? As I said, buttons/options/checkboxes all seem to trigger on every state change, but not text entry fields.

This is my one real remaining issue with the new scripts...

Thanks,
Tom

[linder]

Hi Tom,

The problem is that Windows does not fire such an event on EDIT controls. Buttons/Radio/Checkboxes fire events if the state changes, Edit controls do not.

When do you need such an "event"? The user clisks the "Back" button and changes the value of an EDIT field in a previous dialog. And then you have to do "something" if the control "loses" focus (and before the user clicks "Next")?

Friedrich

[Tom H.]

The edit control is where the user enters the registration code, which determines all of the subsequent actions for the script (readme display, dialogs to show/hide, etc.)

So, if they go back and change it from a 'demo' to a real code, I don't get an event where I can reset the files/dialogs to the new value.

As a workaround, is there a way to force a particular dialog to display when the user presses back? For example, from the readme, can I set it to show the welcome dialog when the user presses 'Back', skipping the registration dialog. That way, I would at least get EVENT:ONREOPEN, etc., on the registration dialog since they would be going forward again at that point.

Thanks,
Tom

[linder]

Hi Tom,

Aha, okay. But if the user clicks "Next" then you have an event to do whatever is required (in the next dialogs) if the user changed the EDIT. You only need an event to change the current dialog. I fear I am missing something <g>.

But we'll try to add an event to the EDIT control.

BTW, the 'Back' button does not execute an "action".

Friedrich