How does FiveW shut down xHb when you close the Mdi frameWND

[peterk]

If I hit Alt + F4 while my app is starting up and while the main mdi frame wnd is being opened, the main wnd closes and I end up with the application running with no interface and no way of shutting it down (except via task manager)

Normally when I shut down the main aplication Wnd, xHb quits without me having to make a call to xHb quit

This has got me thinking - when you close the FW mdi frame, does FiveWin call a xHb "quit" to quit the xHb application ?
[/list]

[Antonio Linares]

Peter,

FiveWin does not call Harbour/xharbour QUIT.

We call PostQuitMessage( 0 ) that makes the main event loop to finalize.

[Antonio Linares]

http://msdn.microsoft.com/en-us/library/ms644945(VS.85).aspx

[peterk]

Antonio

Thank you for the quick reply - I wil play around with that

Regards
Peter

[peterk]

Antonio - is the following a correct description of how an xHb/Fwh application works

1) xHb code starts
2) At some point the xHb code activates the FW Mdi frame Wnd
3) This starts the main FW event loop to handle events
4) xHb code stops at this point (on the line of code that activates the Mdi frame wnd)
5) When the Mdi frame Wnd is closed, the FW event loop is stopped via PostQuitMsg(1) called by the Wnd Destroy event
6) xHb code then continues from the point after the call to activate the Mdi frame Wnd, until it ends

Thanks Peter

[Antonio Linares]

Peter,

Yes

[peterk]

Antonio - last thing on this

Per above, if I close the FW Frame Wnd during the bInit, the tWindow class method 'destroy' does call PostQuitMessage(0), however I end up with the xHb app code running in task manager with the Frame Wnd closed.

If I check lWRunning() at that point it returns .f. so the FW event loop is not running but the xHb code is still running and never returns to after the Frame Wnd activate statement

If I manually call PostQuitMessage(0) again after activating the Frame Wnd (If the hWnd == 0), then the xHB app quits

So PostQuitMessage() will shut down the xHb app even if lWRunning returns .f. and the frame Wnd is closed (hWnd == 0) which makes me think PostQuitMessage(0) must also call xHb __Quit()

Is this correct / can you comment on the above please

Thanks
Peter

[Antonio Linares]

Peter,

__Quit() is not called. You can do this test: declare this function in your main PRG:

Code: Select all  Expand view

function __Quit()
   
   MsgInfo( "QUIT called" )

return nil


[Antonio Linares]

Peter,

Are you doing it this way ?

Code: Select all  Expand view

#include "FiveWin.ch"

function Main()

   local oWnd

   DEFINE WINDOW oWnd

   oWnd:bInit = { || oWnd:End() }

   ACTIVATE WINDOW oWnd

return nil

function __Quit()

   MsgInfo( "quit" )

return nil


[peterk]

Antonio

I am pressing ALT F4 during the wnd bInit (which does quite a few startup tasks and so takes a few seconds). When I do this, Twindow Destroy does call PostQuitMessage() but the application continues to run without a Window (in task manager) and the xHb code after the Wnd activate statement is never reached i.e. the system is still runnning the Fw event loop even though the frame Wnd is closed

My code at the end of bInit checks to see if oWnd:hWnd > 0, and if not calls PostQuitMessage() again which shuts the event loop down and then the xHb code after the oWnd:Activate line runs and the app quits normally

However I dont think I should have to call PostQuitMessage a 2nd time ??

Also FW function WinRun() [not documentedin help file] - does this start the FW event handler ?

Thanks, Peter

[Antonio Linares]

Peter,

> However I dont think I should have to call PostQuitMessage a 2nd time ??

You solution seems ok as probably due the amount of work done before starting the main window, it has not been subclassed yet, so WM_DESTROY is not routed to call PostQuitMessage() thats why the main event loop remains active.

In other words, the window is receiving an order to be destroyed, before than FiveWin can do its job.

[Antonio Linares]

yes, WinRun() starts the main event loop.

[peterk]

Antonio - thanks for the assistance

F Y I - I can also get around this by setting oWnd:bValid to {|| .f.} while the Wnd bInit runs which prevents the user closing the Wnd - this also works ok

Peter

[Antonio Linares]

Peter,

Thanks for the information.

Yes, that solution is simpler