Syl wrote:
> When you return -1 in any event sub, not just in _Terminate, your window
> gets destroyed. Since you cannot exit the Dialog() loop other than
with -1,
> there are but two ways to do it
But that is my problem. I return(-1) to Setup() but the window is not
terminated by _Terminate or OKbutton_Click. Why?
From an event handler...
* Returning 1 continues the "normal" action. For Terminate, this is to
destroy the Window IIRC.
* Returning 0 prevents the "normal" action from taking place.
* Returning -1 will exit the main loop.
So what happens in the usual Win32::GUI program is that -1 exits the main
loop, and then the _program_ terminates, cleaning up the windows as it
exits. That is probably why your windows stay there.
In fact I want to destroy the window after I gather the data (faults and all
:) and reconstruct the window with some error messaging stuff displayed. Or
can I ->Hide(), reconstruct and then ->Show()?
I don't think that's the best way of doing it. Why destroy the windows at all?
What you want to do--after the Ok or Cancel is pressed--is to Hide() the
window, validate the input, and then Show() the same window with some added
error messages. Note that the values the user wrote a minute ago is still
there in the controls. Which is what the user wants, so this is a Good
Thing! :)
Pseudo:
main
Create window
Init window (clear error msg label)
Win32::GUI::Dialog()
Do stuff with entered values if Ok was pressed.
Exit
win_Terminate and cancel_Click
win->Hide()
return -1 to exit main loop
ok_Click
If values ok
win->Hide()
set status flag = ok, and save entered values
return -1
else
put error message in label
return 0 (or 1, it may not matter at all)
That's it.
A cool thing would be to put the error message label at the bottom of the
Dialog window, and if/when it needs to be displayed, you enlarge the window
to make it visible (once). (Make sure it's entirely visible within the
screen/desktop window, either by placing it in the middle of the screen, or
by checking the coords.) Example of program that does this: PGP Disk (when
you enter the wrong password).
Another cool thing would be to put the error message/hint just beside the
affected input control, and highlight/SetFocus to the first offending input
control, to make it easy for the user to a) see what's wrong, and b) change
the input. You can see this in many well designed web forms.
/J
-------- ------ ---- --- -- -- -- - - - - -
Johan Lindström Sourcerer @ Boss Casinos [EMAIL PROTECTED]
Latest bookmark: "Outline for Requirements Specification"
http://www2.ccnmtl.columbia.edu/requirements.xml
