Hi Scuri - that’s great news. Thank you. You don’t have a binary build of a 32-bit dll that’s compatible with Microsoft Visual C++ 2017 do you? i.e. the equivalent of iup-3.27-Lua53_Win32_dll15_lib.zip? I have just spent a whole day trying to follow the instructions in the IUP documentation on how to build IUP and I have not succeeded. I created a folder which has these zip files:
· cd-5.12_Sources.zip · freetype-2.6.3_Sources.zip · ftgl-2.1.5_Sources.zip · im-3.13_Sources.zip · iup-3.27_Sources.zip · lua-5.3.5_Sources.zip · zlib-1.2.11_Sources.zip and when I unzipped them I got these folders: · cd · freetype · ftgl · im · iup · lua53 · zlib I downloaded Cygwin, but couldn’t build any of the components. If I didn’t define TEC_UNAME I got an error, but I couldn’t work out what value to set it to, for Visual C++ 2017 (32-bit dll). I then tried using MinGW and got a little further with that. Some of the files seemed to compile (albeit with lots of warnings), but the components themselves did not build. Don’t know why not. To be honest, I don’t feel I’m close with either Cygwin or MinGW. So if you have a binary I could use, I’d be very grateful. Simon From: Antonio Scuri [mailto:antonio.sc...@gmail.com] Sent: 12 July 2019 6:21 PM To: IUP discussion list. Subject: Re: [Iup-users] FW: IUP crash in Debug Mode Hi, I just committed to the SVN a new global attribute called CUSTOMQUITMESSAGE. If set to Yes, the message processing it will use a custom quit message and it will not call PostQuitMessage. Let me know if it works. Best, Scuri Em ter, 2 de jul de 2019 às 12:18, Simon Orde <simono...@family-historian.co.uk> escreveu: Hi Scuri I do understand your caution about making a change – especially if no-one else has reported the problem. Can I have another go at trying to change your mind? There is an ambiguity here that I think may not be helping things. In Windows, a thread can (optionally) have a message queue. They get one if they do things that require a message queue. And in that case, a message loop must be provided to process the messages in the queue. This typically looks like this (in the page you sent a link to): // Start the message loop. while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0) { if (bRet == -1) { // handle the error and possibly exit } else { TranslateMessage(&msg); DispatchMessage(&msg); } } Notice that in the comment they call it “the” message loop. From what you’re saying, it sound like you’re thinking of the winLoopProcessMessage function in the file iupwin_loop.c as the thread’s message loop. And it’s true that it is a message loop. But it isn’t the thread’s main message loop. It is IUP’s own message loop – a secondary message loop that is nested within the main application message loop. At least it is in any application, such as mine, which has other non-IUP windows in addition to the IUP windows. My application is an MFC application. In an MFC application, the main message loop is within MFC code at the highest level. When the documentation (in the link you posted) talks about how “the thread’s message loop terminates” (on receipt of a WM_QUIT message), they’re talking as if the thread only has one message loop. Which is the most normal thing. The point is, you don’t call a PostQuitMessage to get a secondary message loop to exit. Or not unless you want the whole thread, with all windows attached to it, to shut down. Incidentally, there’s nothing wrong with secondary message loops. We use them too in a few places in the application. But one shouldn’t treat them as if they were thread’s main message loop. I suppose it is possible that some applications might use IUP for all their windowing requirements and have no non-IUP windows. Is that possible? If so, I suppose it’s possible that winLoopProcessMessage might actually function as the thread’s main message loop. So here’s another suggestion: provide a mechanism whereby an IUP client can set a flag within IUP to indicate whether it wants IUP to shut everything down on exit. That flag could be enabled by default, so existing implementations will notice no difference in behaviour. But an application like mine could set this off at the outset. If the flag was disabled, IUP would behave as I proposed in my last email, and use a registered windows message to exit its loop. If the flag was enabled, it would behave as now and use PostQuitMessage. This would not only solve my problem, but also safely future-proof IUP over the issue going forward. What do you think? Simon From: Antonio Scuri [mailto:antonio.sc...@gmail.com] Sent: 02 July 2019 1:15 PM To: IUP discussion list. Subject: Re: [Iup-users] FW: IUP crash in Debug Mode Hi, If you take a look at: Using Messages and Message Queues https://docs.microsoft.com/en-us/windows/desktop/winmsg/using-messages-and-message-queues The thread nomenclature may lead to another understanding, but you will see that to use PostQuitMessage is the regular way of doing it. I don't think is a good idea to change that in IUP. I have no idea of the consequences for other applications where everything is working. Until today only your case has been reported. For now you can do it in your own distribution, maybe in the future we can change that. Best, Scuri Em qui, 27 de jun de 2019 às 09:15, Antonio Scuri <antonio.sc...@gmail.com> escreveu: Hi, I'm in the middle of several tasks here. I'll get back to this soon. Thanks for sending the suggestion. Best, Scuri Em qui, 27 de jun de 2019 às 09:12, Simon Orde <simono...@family-historian.co.uk> escreveu: I downloaded the source code for IUP 3.26 and 3.27 from SourceForge to see if I could work out what was going wrong. I haven’t been able to work out why sometimes IUP scripts cause the application to close – even, in some cases, if it’s not running under a Lua debugger. But I have spotted some behaviour that looks clearly wrong to me, which I believe can be easily fixed, and which if fixed should solve the problem. In both 3.2.6 and 3.2.7 there is one and only call to PostQuitMessage and only one place where the WM_QUIT message is mentioned (and for that matter, only one place where ‘GetMessage’ is called), and it’s in the file iupwin_loop.c. The 3.2.6 and 3.2.7 versions of this file are identical. I believe that the following 3 small changes would fix the problem: (1) Insert this line to the top of iupwin_loop.c (at say line 26): “static UINT win_quit_msg_id = 0;” (2) The IupExitLoop function currently looks like this: void IupExitLoop(void) { char* exit_loop = IupGetGlobal("EXITLOOP"); if (win_main_loop > 1 || !exit_loop || iupStrBoolean(exit_loop)) PostQuitMessage(0); } … and should be changed to this: void IupExitLoop(void) { if (win_quit_msg_id == 0) win_quit_msg_id = ::RegisterWindowMessage("IUP Quit Message"); char* exit_loop = IupGetGlobal("EXITLOOP"); if (win_main_loop > 1 || !exit_loop || iupStrBoolean(exit_loop)) PostMessage(NULL, win_quit_msg_id, 0, 0L); } (3) The winLoopProcessMessage function currently looks like this: static int winLoopProcessMessage(MSG* msg) { if (msg->message == WM_QUIT) /* IUP_CLOSE returned in a callback or IupHide in a popup dialog or all dialogs closed */ return IUP_CLOSE; else { TranslateMessage(msg); DispatchMessage(msg); return IUP_DEFAULT; } } … and should be changed to this: static int winLoopProcessMessage(MSG* msg) { if (win_quit_msg_id == 0) { win_quit_msg_id = ::RegisterWindowMessage("IUP Quit Message"); if (win_quit_msg_id == 0) return IUP_CLOSE; } if (msg->message == win_quit_msg_id) /* IUP_CLOSE returned in a callback or IupHide in a popup dialog or all dialogs closed */ return IUP_CLOSE; else { TranslateMessage(msg); DispatchMessage(msg); return IUP_DEFAULT; } } That’s it – except that there are a couple of comments in the same file /* WM_QUIT */ that can simply be removed. The code in each case is fine as it is and does not need to be changed. Probably you should define “IUP Quit Message” (or whatever your preferred string is) as a constant string at the top of the file, for greater robustness. Theoretically you could use WM_USER + ? as the message id, but it’s more robust to use a registered message. That way you can be 100% sure that there won’t be a conflict with any application-defined messages, which there could be if you took the WM_USER approach. The Windows documentation says that the PostQuitMessage function “Indicates to the system that a thread has made a request to terminate (quit)”. That is clearly not the case here, so PostQuitMessage should not be used. Any thoughts anyone? Scuri? Simon From: Antonio Scuri [mailto:antonio.sc...@gmail.com] Sent: 24 June 2019 6:27 PM To: IUP discussion list. Subject: Re: [Iup-users] FW: IUP crash in Debug Mode > 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 _______________________________________________ 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
