> Is there any way I can stop it doing that?
No
> Has IUP always posted WM_QUIT messages?
I think Yes
> I wasn’t clear from your reply what you think needs to be done.
Actually neither I...
> From my point-of-view, I don’t want IUP to ever close down my
application in any circumstances.
Yes, it wasn't meant to do that. When you are showing an IUP dialog the
iup.MainLoop will hold the execution until a WM_QUIT message is posted. The
same happens when iup.Popup is called, but in this case there is a
secondary message loop, when the quit message is posted it returns to the
mainloop. The idea, and it works when not debugging, is that IUP receive
the quit message, and returns the control to the application just like a
secondary message loop.
The problem is that your application loop is intercepting our quit
message in debug, apparently because of the message pump process. Notice
that IUP has its own way to message pump by using IupLoopStep. We use that
to implement the Lua debugger in the IupLuaScripterDlg predefined dialog.
To be more specific and not being, I think something in the message pump
should be changed, but I'm not sure what.
Best,
Scuri
Em seg, 24 de jun de 2019 às 13:23, Simon Orde <
simono...@family-historian.co.uk> escreveu:
> Hi Scuri – I wasn’t clear from your reply what you think needs to be
> done. From my point-of-view, I don’t want IUP to ever close down my
> application in any circumstances. So I don’t want it to ever post any
> WM_QUIT message (or call PostQuitMessage). Is there any way I can stop it
> doing that? I can’t see that there is anything wrong with my debugger’s
> message pump. And if I don’t crank the message pump, the debugger won’t
> work. I tried just ignoring the case when PumpMessage returns false, but
> that didn’t solve the problem.
>
>
>
> I have a similar problem with progress bars. I enclose an example below.
> Unlike my previous example, if I run this script normally, the application
> closes down when it ends (having I think received a WM_QUIT message because
> the app’s ExitInstance method gets called at the end). For some reason, if
> I run it under the Lua debugger, the application does not close down. It’s
> hard to know what is going on, because if I run it under both the Lua
> debugger and the Visual C++ debugger I get ASSERTs in the MFC which prevent
> further processing (“mfc140ud.dll!02ed5d93()” - and no usable stack info
> between that and WinMain).
>
>
>
> Has IUP always posted WM_QUIT messages? We are now running IUP 3.26 and
> Lua 5.3 having upgraded from IUP 3.11.2 and Lua 5.1. We did not used to
> have this problem before we upgraded.
>
>
>
> Simon
>
>
>
> *The following script crashes the application when run normally*
>
>
>
> require "iuplua"
>
>
>
> local cancelflag
>
> local gaugeProgress
>
>
>
> local function StartProgressBar()
>
> cancelbutton = iup.button {
>
> title = "Cancel",
>
> action=function()
>
> cancelflag = true
>
> return iup.CLOSE
>
> end
>
> }
>
> gaugeProgress = iup.progressbar{ expand="HORIZONTAL" }
>
> dlgProgress = iup.dialog{
>
> title = "Note Replacement in Progress",
>
> dialogframe = "YES", border = "YES",
>
> iup.vbox {
>
> gaugeProgress,
>
> cancelbutton,
>
> }
>
> }
>
> dlgProgress.size = "QUARTERxEIGHTH"
>
> dlgProgress.menubox = "NO" -- Remove Windows close button and menu.
>
> dlgProgress.close_cb = cancelbutton.action
>
> dlgProgress:showxy(iup.CENTER, iup.CENTER) -- Put up Progress Display
>
> return dlgProgress
>
> end
>
>
>
>
>
> dlg = StartProgressBar()
>
> gaugeProgress.value = 0.0
>
>
>
> for i=0,10000 do
>
> -- take one step in a long calculation
>
> -- update progress in some meaningful way
>
> gaugeProgress.value = i / 10000
>
> -- allow the dialog to process any messages
>
> iup.LoopStep()
>
> -- notice the user wanting to cancel and do something meaningful
>
> if cancelflag then break end
>
> end
>
> dlgProgress:destroy()
>
> -- distinguish canceled from finished by inspecting the flag
>
> print("cancled:",cancelflag)
>
>
>
>
>
>
>
>
>
> *From:* Antonio Scuri [mailto:antonio.sc...@gmail.com]
> *Sent:* 20 June 2019 1:20 PM
> *To:* IUP discussion list.
> *Subject:* Re: [Iup-users] FW: IUP crash in Debug Mode
>
>
>
> I think the problem is really the WM_QUIT processing.
>
>
>
> When the message is processed it is removed from the queue so it is not
> processed again. Popup dialogs in IUP has a secondary message loop. That's
> why iup.GetParam and iup.Alarm work ok.
>
>
>
> The problem is not at your script. The problem seems to be with message
> processing.
>
>
>
> WM_QUIT is posted at the button click when iup.CLOSE is returned or
> IupExitLoop is explicitly called. Clicking in the X (the close button of
> the dialog) does not generates a WM_QUIT message because it only hides the
> dialog. Since it is the last IUP visible dialog, it will end the message
> loop in a complete different way.
>
>
>
> Since the iup.MainLoop is run after your application message loop it
> shouldn't be a problem because it will work as a secondary loop for the
> application and it will catch WM_QUIT messages posted by IUP.
>
>
>
> But If I understood it right, I think CMyApp::PumpMessage is processing
> WM_QUIT messages posted by IUP.
>
>
>
> Best,
>
> Scuri
>
>
>
>
>
>
>
> Em qui, 20 de jun de 2019 às 08:04, Simon Orde <
> simono...@family-historian.co.uk> escreveu:
>
> I did the test. I changed the OK ‘button’ to a ‘flatbutton’. I also had
> to change “action” to “flat_action”. It didn’t make any difference. The
> application appeared to have received a WM_QUIT message when you click the
> OK button, exactly as before.
>
>
>
> Couple more things: I wondered if setting the NATIVEPARENT window handle
> of the dialog would make a difference. I was able to get that to work
> using “iup.SetAttribute(dlg, "NATIVEPARENT", hWnd)”, but it didn’t make any
> difference to the problem.
>
>
>
> I said in an earlier email that code following dlg:destroy never gets
> called if you click the OK button. I now think that that’s wrong. I think
> the code does get called, but it’s hard to tell and hard to test because
> the application is dying fast (as the WM_QUIT message has already been
> posted). So the fact that the lua_pcallk command rets 0 (no error) is
> probably of no significance.
>
>
>
> For interest, if I run the script under a debugger, I have to crank the
> message pump myself, so I call CMyApp::PumpMessage at various points so
> that the editor/debugger gets a chance to process messages. The code tests
> to see if CMyApp::PumpMessage returns false. It should only do this if a
> WM_QUIT message has been received. And if you click the OK button,
> CMyApp::PumpMessage does indeed return false, seemingly during the call to
> dlg:destroy (i.e. before the next script line has been processed, as far as
> I can see).
>
>
>
> If I don’t run the script under the debugger, I don’t crank the message
> pump. Instead there’s a message loop in the bowels of the MFC. But that
> calls CWinApp::ExitInstance if the PumpMessage call returns false. I can
> put a breakpoint in my applications ExitInstance method call and this
> seemingly gets called exactly when you would expect – i.e. in the same
> circumstances that CMyApp::PumpMessage in the editor’s message crank would
> return false.
>
>
>
> In my view, the big clue is that iup.GetParam and iup.Alarm both work
> fine with no problems. What is it that they are doing which is different
> to what my script is doing?
>
>
>
> Simon
>
>
>
>
>
> *From:* Antonio Scuri [mailto:antonio.sc...@gmail.com]
> *Sent:* 19 June 2019 8:33 PM
> *To:* IUP discussion list.
> *Subject:* Re: [Iup-users] FW: IUP crash in Debug Mode
>
>
>
> Ok.
>
>
>
> Can you make a simple test? To replace IupButton by IupFlatButton and
> check if there is any difference?
>
>
>
> Best,
>
> Scuri
>
>
>
>
>
> Em qua, 19 de jun de 2019 às 15:05, Simon Orde <
> simono...@family-historian.co.uk> escreveu:
>
> … sorry – yet more clarification.
>
>
>
> When I said “if I modify the script to add something (a message box) say,
> after the call to “dlg:destroy()”, the message box code never gets called
> if I call dlg:destroy.”
>
>
>
> Again – what I meant is that if you click on the ‘OK’ button in the
> dialog, the script exits at the call to dlg:destroy(). But it doesn’t exit
> there if I closed the dialog by clicking on the ‘X’ in the dialog’s
> top-right corner. In that case, the script continues to execute after the
> call to dlg:destroy() and the message box is displayed.
>
>
>
> Simon
>
>
>
>
>
> *From:* Simon Orde [mailto:simono...@family-historian.co.uk]
> *Sent:* 19 June 2019 6:57 PM
> *To:* 'IUP discussion list.'
> *Subject:* RE: [Iup-users] IUP crash in Debug Mode
>
>
>
> To be precise, when I said “If I run the iup dialog script from my
> previous post… in (Visual C++) debug mode … it will close the application”,
> I meant: “… it will close the application *if* you click on the OK button
> in the dialog”. It will *not* close the application if you click on the
> ‘X’ in the dialog’s top-right corner. Just wanted to be 100% clear about
> that.
>
>
>
> Simon
>
> _______________________________________________
> Iup-users mailing list
> Iup-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iup-users
>
> _______________________________________________
> Iup-users mailing list
> Iup-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iup-users
>
> _______________________________________________
> Iup-users mailing list
> Iup-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iup-users
>
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
