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