My FoxPro program has a quit button and the usual min/max/X buttons in the top right, and when using either the program disappears and seems to have closed properly. However, when I check my Task Manager, I find that it is still running.
This is my main.prg file:
ON SHUTDOWN CLEAR EVENTS
with _screen
.visible = .f.
endwith
DO FORM locations\form1
READ EVENTS
ON SHUTDOWN
and this is the code for my exit button 'click' event:
unlock all
close database all
clear events
RELEASE ALL
quit
My program has only the one form and it's set as top-level... any suggestions as to how I can fix this?
Thanks for your time and help :)
If you are running VFP originating from the IDE (Development environment), and you do _Screen.Visible = .F., you are HIDING the main VFP screen, and the system may be returning directly to that, and since you can't see it, you cant formally quit.
In your MAIN.PRG, put the following down at the bottom as a separate "function" that will be visible within the call stack.
function CloseMyApp
*/ For now, just to "ignore" any errors of any dangling objects trying to get released
*/ and otherwise might be HIDING an error upon shutdown.
on error *
*/ NOW, clear the event handler and close everything else down
clear events
close database all
close tables
on shutdown
quit
endfunc
Then, in your start, change your ON SHUTDOWN to call this "function"... Right now, you are only issuing a single command of clear events. This way, you can wrap up a bunch of "cleanup" operations before closing, and not just clearing the read events.
ON SHUTDOWN Do CloseMyApp in Main.PRG
If you click the EXIT button on the form (your button) does the form close and the application close correctly ?
If it does, ASSUMING the button is called 'cmdExit' then add this line to the 'UNLOAD' event of the form
THISFORM.cmdExit.click()
Related
I don't want to deflect the button hit or ignore the close event. I just need to run some cleanup code.
Let me tell you what I've tried so far:
atexit()
_onexit()
SetConsoleCtrlHandler()
~QCoreApplication()
No code set by these is being executed.
The process just get killed when I press the X.
I certainly can make a windowed app and solve this, but is there a solution for a console application?
Thanks!
I am working on a TCP server that I'm developing on CLion under Windows 10.
I would like my program to be able to end properly, when I click on "stop" my program. I thought CLion was sending a signal, but after trying to catch them all, it looks like it does not.
So my question is, how does CLion stop running the program? Is it possible to detect it within the program?
Thank you in advance.
I found my answer here.
According to this link, signals are actually used :
Click this button to terminate the current process externally by means
of the standard shutdown script. Clicking the button once invokes soft
kill allowing the application to catch the SIGINT event and perform
graceful termination (on Windows, the Ctrl+C event is emulated). After
the button is clicked once, it is replaced with icon run tool window
kill indicating that subsequent click will lead to force termination
of the application, e.g. on Unix SIGKILL is sent.
I'm doing a QWizard with QT 4.8.5 and in some pages I have to close some other applications and exit my program. This works fine but now I want to show a pop up message that tells the user that the programs are restarting (There are others a part of mine and mine is the last one to be closed always). The code I use to show the pop up is the next one and I place it in the validatepage of a QWizardpage:
QMessageBox *msgBox1 = new QMessageBox;
msgBox1->setWindowTitle("Title...");
msgBox1->setIcon(QMessageBox::Information);
msgBox1->setText(" blablablalbal bla bla bla.");
msgBox1->setWindowModality(Qt::NonModal);
msgBox1->show();
QCoreApplication::processEvents(); // without this line, the show does nothing and I can't see my pop up window
So the thing is: With that code, When I am in that wizardpage and click to finish, it launches the QMessageBox while (behind) the program is restarting the other applications and then closes itself (with a QApplication::quit(); ) which is exactly what I want... BUT no message is shown in the pop up... I can't see the icon, the title or the text... :S I don't know why :(
Whereas when use ->exec(); instead of show, the icon, title and text are shown BUT when the pop up appears, nothing is done behind until the user closes that pop up... :S
I understand that .exec() freezes all until user closes the pop up while show doesn't...
So... how can I see the text with the show() behaviour?? I don't want the user to interact with that pop up, I just need the pop up to show up while closing all until my program closes too...
Thank you so much!
Relevant: http://comments.gmane.org/gmane.comp.lib.qt.general/30706
In summary, QDialog::exec() creates a modal dialog (regardless of your Qt::NonModal setting) with its own event loop, and ::show() does not.
So in your case, ::exec() will fully render the dialog but it's blocking the rest of your background processing. ::show() won't block, but since it's sharing the event loop with your other code it isn't getting around to emptying the event queue (which has all of the show/layout/render events from your dialog) because of your background code.
I would try the following:
use ::show() not ::exec()
force your dialog to the front using QDialog::raise() and Dialog::activateWindow()
(the important part) either
call QApplication::processEvents() within your background processing tasks (e.g., within long-running loops).
spawn your background processing into a thread (this may or may not be easy depending on how your code is structured) to allow the main event loop to process your dialog events.
I have just got this problem for a few days. Before, I've always thought that letting the program exit by returning from main and clicking close the console window is the same way to end the program.
However, I've found that they are different. Since my program opens a camera which is an object. And closing the console windows does not destroy or clean up the object. So the next time I have error to open the camera again
I just need a confirm if this is true?
Then why only until now I can see the problem?
Closing a console window in Windows, kills the running program (or stack of running programs). Unless it has registered a handler for this event, it gets no chance to clean up. If you want solution, register a handler.
Hm, consulting the documentation, wait a few secs…
OK, look up SetConsoleCtrlHandler.
Closing a running console application will kill the process, not giving you the chance for any clean up code. I guess you could hook a windows message loop to trap the WM_CLOSE message and do proper cleanup, but at the end of the day, you just shouldn't kill the process.
I have an MFC application that spawns a number of different worker threads and is compiled with VS2003.
When calling CTreeCtrl::GetItemState() I'm occasionally getting a debug assertion dialog popup. I'm assuming that this is because I've passed in a handle to an invalid item but this isn't my immediate concern.
My concern is: From my logs, it looks as though the MFC thread continues to service a number of windows messages whilst the assert dialog is being displayed. I thought the assert dialog was modal so I was wondering if this was even possible?
The message box that shows the assertion failure has a message pump for its own purposes. But it'll dispatch all messages that come in, not just those for the message box (otherwise things could get blocked).
With a normal modal dialog, this isn't a problem because the parent window is typically disabled for the duration of the dialog.
The code that launches the assertion dialog must've failed to figure out the parent window, and thus it wasn't disabled. This can happen if your main window isn't the active window at the time of the assertion. Other things can go wrong as well.
You can change how Visual Studio's C run-time library reports assertion failures with _CrtSetReportMode. You can make it stop in the debugger and/or log to the output window instead of trying to show the dialog.
Dialogs (even a messagebox) need to pump the message queue, even if they're modal. Otherwise how would they know you clicked on the "OK" button?
If you need to stop everything when an assert triggers it's usually not too difficult to write your own implementation of assert() (or ASSERT() or whatever) that will break into the debugger instead of displaying a messagebox that asks if you want to break into the debugger (maybe only if it determines that the debugger is attached).