1. Stopping onClose Event in Win32Lib
Hi all,
I am writing a simple Win32 application and want to be able to ask the
user a "yes" "no" question if they have made changes to their work when
clicking on the "x" in the top right hand corner of the window.
Like all good programs "Save? Yes / No / Cancel".
I can use the "onClose" event to process a procedure when the user clicks
on the "x" but I don't know how to cancel the even if the user wants to
click on "Cancel" meaning I do not want to close.
Any help will be very much appreciated.
Thanks
Ray Smith
2. Re: Stopping onClose Event in Win32Lib
>From: Smith Ray <Ray.Smith at FUJITSU.COM.AU>
>Subject: Stopping onClose Event in Win32Lib
>
>Hi all,
>
>I am writing a simple Win32 application and want to be able to ask the
>user a "yes" "no" question if they have made changes to their work when
>clicking on the "x" in the top right hand corner of the window.
>
>Like all good programs "Save? Yes / No / Cancel".
>
>I can use the "onClose" event to process a procedure when the user
clicks
>on the "x" but I don't know how to cancel the even if the user wants to
>click on "Cancel" meaning I do not want to close.
>
Use WinMain() again....
Bye,
PQ
QC
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
3. Re: Stopping onClose Event in Win32Lib
Ray Smith wrote:
> I can use the "onClose" event to process a procedure when the
> user clicks on the "x" but I don't know how to cancel the even
> if the user wants to click on "Cancel" meaning I do not want to close.
Good point. I've been wondering how to implement the overriding of default
behaviors in Win32Lib.
When Win32Lib creates a control, it grabs the control's callback (a pointer
to Win32 code that handles events), and stores it in window_func. Then in
replaces the default Win32 callback with a Euphoria callback to my WndProc
routine. When a control gets an action, Win32 triggers the Euphoria callback
code instead of the default Win32 callback. That's how Win32Lib "hooks" into
events.
Since the Euphoria code gets run *instead* of the default window callback,
it's up to Win32Lib to call the callback when it's done, or Win32 can't do
the default action (like draw, resize, or click a control). So when the
Euphoria code is done running, Win32Lib calls the original Win32 callback of
the control:
-- run behavior
return c_func( xCallWindowProc, { window_func[id],
hWnd,
iMsg,
wParam,
lParam } )
For windows, Win32Lib runs it's own code, and then calls DefWindowProc to
handle the default action:
return c_func( xDefWindowProc, { myHwnd, iMsg, wParam, lParam } )
What (I think) you are asking is the ability to specify that the default
action (for example, closing the window) *not* be called in certain cases.
There is currently no way to do that, but it wouldn't be difficult to add.
For example, I could add a routine skipDefaultAction (or some better name)
that would flag the default callback from running. So you could write:
function onClose_Window()
-- is the flag preventing the window from closing?
if not canClose then
-- cancel the default action
skipDefaultAction()
end if
end function
and if the canClose flag was false, the window would not close
Comments?
Thanks.
-- David Cuny
4. Re: Stopping onClose Event in Win32Lib
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Feb 19, 1999
-
Last edited Feb 20, 1999
In visual basic, your routine can return true or false, whether or not to exit
or not.
In the same way, it can mangle key-presses, and all other kinds of related info,
trough arguments and returned values.
Maybe that's the way to go ?
Ralf
5. Re: Stopping onClose Event in Win32Lib
Ralf wrote:
> In visual basic, your routine can return true or false,
> whether or not to exit or not.
I had considered this, but that would mean changing all the event handlers
from procedures to functions, and adding a return value to them. This seemed
like a lot of work to have the user do - especially since most users would
never access that feature. It seemed wiser to require extra work for the
exceptions, and not the norm.
Thanks for the feedback.
-- David Cuny
P.S. - In case anyone is wondering, I've finally started to work on adding
common controls to Win32Lib. It looks like they are going to be No Fun At
All to code.
6. Re: Stopping onClose Event in Win32Lib
>From: "Cuny, David" <David.Cuny at DSS.CA.GOV>
>Subject: Re: Stopping onClose Event in Win32Lib
>
>Ray Smith wrote:
>
>> I can use the "onClose" event to process a procedure when the
>> user clicks on the "x" but I don't know how to cancel the even
>> if the user wants to click on "Cancel" meaning I do not want to
close.
>
>Good point. I've been wondering how to implement the overriding of
default
>behaviors in Win32Lib.
>
>When Win32Lib creates a control, it grabs the control's callback (a
pointer
>to Win32 code that handles events), and stores it in window_func. Then
in
>replaces the default Win32 callback with a Euphoria callback to my
WndProc
>routine. When a control gets an action, Win32 triggers the Euphoria
callback
>code instead of the default Win32 callback. That's how Win32Lib "hooks"
into
>events.
>
>Since the Euphoria code gets run *instead* of the default window
callback,
>it's up to Win32Lib to call the callback when it's done, or Win32 can't
do
>the default action (like draw, resize, or click a control). So when the
>Euphoria code is done running, Win32Lib calls the original Win32
callback of
>the control:
>
> -- run behavior
> return c_func( xCallWindowProc, { window_func[id],
> hWnd,
> iMsg,
> wParam,
> lParam } )
>
>For windows, Win32Lib runs it's own code, and then calls DefWindowProc
to
>handle the default action:
>
> return c_func( xDefWindowProc, { myHwnd, iMsg, wParam, lParam } )
>
>What (I think) you are asking is the ability to specify that the
default
>action (for example, closing the window) *not* be called in certain
cases.
>There is currently no way to do that, but it wouldn't be difficult to
add.
>For example, I could add a routine skipDefaultAction (or some better
name)
>that would flag the default callback from running. So you could write:
>
> function onClose_Window()
> -- is the flag preventing the window from closing?
> if not canClose then
> -- cancel the default action
> skipDefaultAction()
> end if
> end function
>
>and if the canClose flag was false, the window would not close
>
>Comments?
>
>Thanks.
>
>-- David Cuny
>
>
What's wrong, I use for cancelling the request of closing by :
WinMain(MainWindow)
onload_MainWindow()
That's all!
Bye,
PQ
QC
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
7. Re: Stopping onClose Event in Win32Lib
Patrick Quist wrote:
> What's wrong, I use for cancelling the request of closing by :
>
> WinMain(MainWindow)
> onload_MainWindow()
>
> That's all!
Well, for one thing, it doesn't *cancel* the request. At best, it re-opens
the window after it's been closed. Let me explain what currently happens
when the close icon is pressed in a window in Win32Lib, and why I prefer my
method:
1. Pressing the close icon issues a WM_CLOSE event to that window.
2. On getting the event, the Euphoria event handling code WndProc is
activated.
3a. Since this is a modal window, Win32Lib does some internal monkeying with
the popModal routine to make sure that if there is another modal window, it
will receive focus.
3b. If the window is modal, it is hidden (not closed), and WndProc is
exited, and the following events are *skipped*.
3c. If the window was *not* modal, the onClose event is run.
3d. The DefWindowProc routine is run to handle the default Win32 actions.
This generates a WM_DESTROY event.
4. On getting the event, the Euphoria event handling code WndProc is
activated.
5. If there is an onDestroy event, it is triggered.
6. WndProc calls PostQuitMessage to shut down the application.
*Whew* Been paying attention? If so, you might have noticed that onClose
doesn't work for modal windows. Oooops. Bug fix time.
Now, if you want to prevent a *modal* window from being closed, your only
chance is trapping in the onEvent routine, because the only window to see
the destroy event (WM_DESTROY) is the primary window. That's because
Win32Lib doesn't call DefWindowProc when a modal window gets a WM_CLOSE, and
so a WM_DESTROY never gets generated, yada yada yada.
On the other hand, if you want to prevent the *primary* window from being
closed, you can either trap it in onClose or onDestroy event handlers.
I can only *guess* what happens with your example:
1. When the close icon is pressed in the *primary* window, a WM_CLOSE is
issued.
2. Win32Lib runs whatever onClose code there is, and then runs
DefWindowProc, which issues WM_DESTROY.
3. Since WM_DESTROY was issued to the primary window, PostQuitMessage is
called to shut down the application.
4. PostQuitMessage causes WinMain to fall out if the message loop, and
destroy all resources.
5. onload_MainWindow() is called, which does goodness knows what. I'll go
out on a limb and guess that it calls openWindow, which reloads the main
window. It then falls out of onload_MainWindow() and does...
...I haven't the foggiest notion *what* it does. In theory, it's finished
running the code, so Euphoria should shut down at this point. But pressing
the close icon again *should* shut down the application, since there's
nothing to fall through to.
I have no idea *why* (or if) your example works. As far as I can tell, it
relies on a side effect which might go away in some future version.
In my mind, the optimal action would be to explicit with something like
cancelDefaultAction(). Sure, it's opaque (and the name is awful) - but it's
a more general solution, and the user has a better chance on figuring out
why that particular line is there, and what it might do.
-- David Cuny
8. Re: Stopping onClose Event in Win32Lib
I got two new books about Win API David. During March I'll resume VE
development and may help you with win32lib. With the unlimited callback
addresses 2.1 provides I may migrate some of the Delphi code to native
Euphoria. What do you think of creating an Euphoria parallel to the
Delphi's (and C++ Builder) VCL?
BTW RTTI is achievable in Euphoria or I'm I wrong?
One small question: I just removed my win98 and installed NT workstation
4.0 (highly recommend migration ;). Does anyone know how to make it
"power-off" on exit (ATX system)? Win9x did it OK.
Regards,
Daniel Berstein
daber at pair.com
9. Re: Stopping onClose Event in Win32Lib
Dan
I think "Power down" depends on atx motherboard and type of power
supply you have. check your hardware manual or manufactures web site.
Bernie
10. Re: Stopping onClose Event in Win32Lib
Daniel Berstein wrote:
>I got two new books about Win API David. During March I'll resume VE
>development and may help you with win32lib. With the unlimited callback
>addresses 2.1 provides I may migrate some of the Delphi code to native
>Euphoria. What do you think of creating an Euphoria parallel to the
>Delphi's (and C++ Builder) VCL?
Here I'm at a disadvantage - I haven't actually played with the Delphi/C++
interface. With only about 10Meg left of my hard drive, I wouldn't be able
to install it anyway... 
Can you point me to where the interface is described/there are screen shots?
Thanks.
-- David Cuny
11. Re: Stopping onClose Event in Win32Lib
At 02:30 PM 20-02-1999 , you wrote:
>Daniel Berstein wrote:
>
>
>>I got two new books about Win API David. During March I'll resume VE
>>development and may help you with win32lib. With the unlimited callback
>>addresses 2.1 provides I may migrate some of the Delphi code to native
>>Euphoria. What do you think of creating an Euphoria parallel to the
>>Delphi's (and C++ Builder) VCL?
>
>
>Here I'm at a disadvantage - I haven't actually played with the Delphi/C++
>interface. With only about 10Meg left of my hard drive, I wouldn't be able
>to install it anyway...
>
>Can you point me to where the interface is described/there are screen shots?
VCL is the Visual Component Library. It a collection of native code
components that encapsulate (each) a visual interface element ( = control
or gadget). It's much simpler to just include a "button" component in your
application than to explicitly creating/registering the window class and
then create it and make a wndproc. A clear interface is required, in
escence you neee OO to achieve this, but with some tricky use of routine
id's we should be able to by-pass this obstacle.
In general we'll need a generic library that act as a "middle-ware" between
the app and the underlaying components implementation. Win32lib is on the
way, but it's difficult to customize it. The component model enables third
parties to develop their own extension based on a common and well known
interface. A nice component for Euphoria would be a grid ;)
Regards,
Daniel Berstein
daber at pair.com
12. Re: Stopping onClose Event in Win32Lib
Hey,
A CancelDefaultAction() would be usefull for Win32Lib, I tried just doing a
WinMain() when I wanted to cancel the action and it does currently work ... so
I'll keep that there until a better solution comes along.
I think Win32Lib is excellent, and can't wait for things like ... status bars,
toolbars, list views .......
anyway ... i'll continue dreaming later ...
Thanks for the help
Ray Smith
13. Re: Stopping onClose Event in Win32Lib
David Cuny wrote:
> P.S. - In case anyone is wondering, I've finally started to work on a=
dding
> common controls to Win32Lib. It looks like they are going to be No Fu=
n At
> All to code.
>
Hello David,
Can you explain in short what comment control are and what can be done =
with them?
TIA,
Ad Rienks
| Gratis e-mail en meer: http://www.dolfijn.nl/
| Een product van Ilse: http://www.ilse.nl/
14. Re: Stopping onClose Event in Win32Lib
Well, I was going to ask if you could implement rich edit controls in
Win32Lib, but
since you're working on common controls, I guess I'll just wait a
while.. I already
gave A LOT of suggestions for Win32Lib already.. I have a few more,
but, I'm not
going to tell you them right now... Heheh.
Austin (aka The AfterBeat)
> David Cuny wrote:
> P.S. - In case anyone is wondering, I've finally started to work on adding
> common controls to Win32Lib. It looks like they are going to be No Fun At
> All to code.
