> Ronnie Ward wrote: > > I've built using VS 2008 C++ Release mode a Windows FLTK app (1.1.9) that > > suppresses the DOS console using the Linker commands /SUBSYSTEM:WINDOWS and > > /ENTRY:"mainCRTStartup". > > > > The app executes fine, but when I "cancel" the app by clicking the X in the > > upper right corner of its Fl_Window, the app terminates. However, when I > > open TaskManager, it shows an entry for the app that is still executing > > (consuming 50% of the cpu cycles). > > > > I think it is related to running the app w/o a DOS WINDOW because when I > > build a release version the shows the DOS box in the background > > (/SUBSYSTEM:CONSOLE), I can terminate the FLTK Window app, but the DOS box > > remains active. It also must be canceled (click X) to terminate it. > > > > So, my question is how can I also terminate what I think is the invisible > > DOS Window when I terminate an FLTK app built linked with the > > /SUBSYSTEM:WINDOWS and /ENTRY:"mainCRTStartup" commands? > > > How about the FLTK test applications; do they have the same problem?
No, when I close those apps, the background DOS window is closed as well. When I show the background DOS Window with my app, it will not close when I close the app window. > I've never seen this myself on windows, except when I had a problem > with my app using CreateProcess() incorrectly. > > Does your app use threads? > In task manager turn on threads to check the thread count > while doing the tests. Yes, I am using timeout and repeat_timeout. The thread count is 8 while my app window is active. When I close it, the thread count still shows 8 for the ghost process I'm trying to eliminate. > When your app is running, look at its PID at startup time, and see > if there's more than one instance of the process or more than one > thread. Only one PID is created for the app window and both the DOS window, and the ghost process. > When you close the app, does that same PID remain running > when you exit the program? Yes, the same PID shows for the ghost process. > If you redefine your window's callback() function to > invoke a callback that just calls 'exit(0);', does that fix it? Not sure I implemented your suggestion correctly, but what I implemented did not change the behavior. All I did was defined a callback in my window to override the Fl window callback. My callback body executed an exit(0);. > What does the end of your main() look like? > Is the last thing return(Fl::run()); If so, try instead: > > Fl::run(); > exit(0); Mine is as you suggested, but the code doesn't come into play because my main() function never exits because I close the app window while main() is busy in a loop. However, if I allow the app to terminate normally, all is well--no ghost process hangs around. What I need to do is catch the app close click, and terminate the app normally. Whatever the default is there is not working in my case. Thanks for your suggestions. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
