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

[Tom H.]

(separated responses so as to not confuse things too much):)

Is there an equivalent to PROP:Touched (or even PROP:IMM) for entry controls in SB? It seems checkboxes, buttons and options always trigger when they change state so that they can be evaluated and action taken, but entry controls do not.

Going back to my example with the reg code entry, it would be nice if SB would detect that a value changed in an entry control and triggered EVENT:ONUPDATE even if the dialog was re-displayed using the 'back' button.

*sigh* I just always seem to get tangled up with the 'events only fire going forward' stuff.

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

[Tom H.]

> But if the user clicks "Next" then you have an event to do whatever is
> required (in the next dialogs)

That's the key point: I don't get an event when the user presses next after going back and changing the entry control. No event is fired, so none of the logic for setting up the rest of the script behavior is executed. It just proceeds to the next dialog, leaving everything as it was as if the user never went back and made the change.

Sorry if this seems convoluted...:)

Thanks,
Tom

[linder]

Hi Tom,

Hmm, no event in this case? I'll check this :)

Friedrich

[linder]

Hi Tom,

Interesting... I can reproduce this here. IMO, this is a bug. Item in review :)

Friedrich

[Tom H.]

Whew... figured out a workaround.:D

It seems that no defined event is fired when you press next, but an event = 0 is. So, code under the dialog can execute if it is not in IF EVENT:ONUPDATE structure.

My workaround is that I've defined a 'save' variable for the reg code prior to the loop, and within the dialog I ignore events and just test for the current value vs the saved value. If it is different, it does all the required logic and resets the 'save' variable to match the new value. Works for me in my initial tests...

Thanks ever so much for the usual excellent support!

Tom

[linder]

Thank YOU so much :)

This is definitely a bug!!!! If you go 'Back' two dialogs then 'Next' to go to the dialog that should fire the update event and press 'Next' again then it works as expected. Argh! We'll fix this.

Thanks again :)

Friedrich

[linder]

I think it behaves as expected in the latest internal source code now:

CHANGE : (sync from SB8) [SB#105131] Runtime: A "Custom Dialog Wizard" did not fire an $EVENT:ONUPDATE$ event when the user pressed the 'Next' button after going back from the next dialog.

CHANGE : (sync from SB8) [SB#105132] Runtime: A "Custom Dialog Wizard" receives an $EVENT:ONREOPEN$ event when the user presses the 'Back' button.

Friedrich

[Tom H.]

Excellent, thanks!

Tom

[linder]

RTF print bug fixed. Thanks again for bringing this to our attention.

---
FIX : (sync from SB8) [SB#105111] Runtime: Under certain circumstances, the "Readme" or "License Agreement" Print button printed the wrong RTF text.
---

Friedrich

[linder]

BTW, we'll try to make a "development build" available tomorrow. If you are interested, you can then check the enhanced event handling and RTF print fix.

Friedrich

[linder]

Hi Tom,

The "Development Build" is available now:

http://www.lindersoft.com/forums/showthread.php?t=32094

Friedrich