So my question is targeted currently at Windows, but knowing the information for OSX would still be useful just to know later incase you have the answer for that.
How my program(s) function:
An initial EXE will run and create a window, this EXE will check and perform updates for the main program and take some user input. After the user input this EXE will start a new EXE (the main program), passing the details from the window so that this new EXE can claim the window and use it. The first program will terminate and the window should not close.
What I need help with:
I know how to create the window, and passing the required arguments through the exe is not something I know, but I dont think I will struggle to find and use that information. My main question is how do I stop the Window from closing when the first EXE terminates because likely the OS will automatically start cleaning things up.
Sidenotes:
Its not a super big deal, I can always start a new program and recreate a window, but I think it would just be a nice aesthetic touch to not have to close the window at all, staying alive and being handled by different programs(potentially at the same time).
I am under the impression that an EXE cannot update itself while running even if the needed files/information/compiled code are not being used so if this is wrong please let me know.
What you're trying to do cannot be done. You cannot transfer ownership of a window to a different thread. This can be inferred from the documentation of DestroyWindows:
A thread cannot use DestroyWindow to destroy a window created by a different thread.
Raymond Chen expands on this as he explains in his blog entry titled Thread affinity of user interface objects, part 1: Window handles:
The thread that creates a window is the one with which the window has an inseparable relationship. Informally, one says that the thread “owns” the window. Messages are dispatched to a window procedure only on the thread that owns it, and generally speaking, modifications to a window should be made only from the thread that owns it.
As far as the OS is concerned, nothing survives the end of a process. This is literally the end. If you need to keep a window around, you cannot terminate the process that owns its owning thread.
Related
Is there any possibility of capturing opengl output of child process?
Child should not have a different window. Output should be captured and displayed by parent instead.
I know that i can create a layer that my child could use to create opengl callbacks in my parent application. And send data by socket or pipe.
Edit:
I write main and child applications.
OK, here's a rundown of how I think this can be done. This is totally untested, so YMMV.
Create your window in the parent process. According to this page, you need to create it with the CS_OWNDC style, which means it has the same HDC permanently associated with it.
Launch your child process. You can pass the HWND to it as a command line parameter, converted to hex-ascii, say, or you can devise some other method.
In the child process, call GetDC to retrieve the HDC of the parent's window and pass it to wglCreateContext (I imagine you know all about doing that sort of thing).
In the child process, draw, draw, draw.
Before exiting the child process, make sure you call ReleaseDC to free up any resources allocated by GetDC.
This ought to work. I know that Chrome uses a separate process for each browser tab, for example (so that if the code rendering into any particular tab should crash, it affects that tab only).
Also, if you're thinking of jumping through all these hoops just because you want to reload some (different) DLLs, maybe you're looking for LoadLibrary and GetProcAddress instead. Hmmm, maybe I didn't need to write all that :)
Let me explain my question with an example. In my app, I need to provide a way to automatically close it from within "itself." (An example of such function is when an installer/updater of my app needs it to close before installing an update. Another example is when my app performs actions on schedule and needs to automatically close once it's done.)
I picture that in the simplest situation posting the WM_CLOSE message to the own window will accomplish this task, but there're the following cases that will not work with just that:
My app may be displaying an arbitrary number of child dialog windows.
My app may be displaying a common control window, such as Open File dialog:
or this one, but there could be others:
And lastly what could one do if the close button is not even available:
At the current point, I simply resort to terminating my process (either with the exit() method from within, or with TerminateProcess from outside.)
But I'm curious, if there's a more graceful way of closing my GUI app (from within)?
There is no single answer, it depends on your app's architecture and what it's doing. I don't quite understand why you would want to force close your application while it is in a common dialog, but if you do, then exit() is safe. In that case the process is actually shutdown from the operating system's perspective as opposed to a forced termination (TerminateProcess). In theory TerminateProcess might leave objects in the OS (DLL global data and such) in an inconsistent state, and exit() will be cleaner in that regard.
Generally though I'd avoid having visible UI that is up for the user just disappear and instead close the windows in reaction to some user choice.
But, exit() will work.
You can use exit() but a safer way to close the window would be:
SomewWindow->ShowWindow(SW_HIDE);
You could then destroy the window object or show the window later.
I have a thread that I pass an HWND of a window where it post messages and updates a progress bar. The user can however go to another window (modal) where I would also like to show the progress of this thread. Passing the initial HWND is obviously straight forward but how can I divert the thread to post messages to the new window once its running? This is a c++ worker thread. I am using Windows 7,MFC, C++.
Put it other way around. Let progress windows get the address of the class from worker thread, and ask it periodically for progress. With timer, for example. That way, you will be able to have as much progress windows as you need.
There are two approaches. One is Daniel's way, that polls progress info from the UI window. All you need is a thread-safe 'int GetProgressPercent() const' member in the thread-implementing class (or equivalent free function).
The other approach is to use PostMessage or PostThreadMessage in the worker thread as progress happens and on the other end process the message adjusting the bar.
The main problem with either is to handle lifetime issues, prevent calls to object or HWND when it is actually gone already. For that the PostThreadMessage way is probably the safest baseline, as the main thread is supposed to be there and manage all the other threads -- and track the overall state of the program able to do meaningful dispatch to live windows or nothing. But it's the most complex too.
The subject says it all. After i closed my app, it stays in the list of processes with some memory. I tried google perf tools and hours of debugging to find the leak.
Are there other tools to test it and find the problem?
Thank you.
My guess is that you have closed the top level window, and thus all its child windows, but you have not closed the app itself.
This does not happen if your program is arranged in a 'normal' way, but if you have, deliberately or by accident, used an unusual arrangement this can happen.
Fixing it, of course, depends on how exactly you have arranged your code. However, here is a suggestion to begin.
The usual way to close the app is to call wxApp::OnExit() which normally occurs when the top level window closes.
Do you have your own class, derived from wxApp? Do you have an override of OnExit()? If not, then make it so and use the debugger to check whether or not it is being called. If it is not being called, work out how to ensure that it is called.
Another idea: use the following to check that your top level window will close the app
bool wxApp::GetExitOnFrameDelete() const
Returns true if the application will exit when the top-level window is
deleted, false otherwise.
If this return false, use the corresponding set to make it so.
A 3rd idea: The application will not exit while there are any top level windows open. So perhaps you have another top level window that is minimized or invisible but has not been closed? Any wxDialog or WxFrame or window derived from these is a top level window and will prevent the application from closing.
A 4th idea: Do you have any globals or attributes of the application object, whose destructors could enter an endless loop? These destructors are called after the windows are destroyed and if one of them does not return you would see the behaviour you describe.
You may try to look at wxWidget's sample folder. You'll find lots of small but complete applications that contain the full init/exit application cycle.
Inspect some samples and compare with your app's workflow.
Yes...problem solved. A TopLevelWindow that was not destroyed. A Memory Leak....stupid mistake.
My application is a multi threaded app (using wxThreads). At the moment, the main thread along with it's child worker threads are outputting various messages to Stdout (using cout).
I have a new frame/window with a wxTextCtrl, and would like to redirect all the StdOut messages in to it.
GuiLogFrame *logframe;
logframe = new GuiLogFrame(NULL, wxID_ANY, wxEmptyString);
logframe->Show();
logredirector = new wxStreamToTextRedirector(logframe->get_log_textctrl());
This doesn't work. But if I replace the last line
wxStreamToTextRedirector redir(logframe->get_log_textctrl());
The standard out will be redirected to the logframe wxTextCtrl as long as redir is in scope... I want it to stay even when it goes out of scope.
What I want is the wxStreamToTextRedirector to stay intact the entire time the application is running... so even the new thread's cout will also redirect in to the same wxTextCtrl.
Any thoughts?
One thing that is very important to know is that GUI operations should only be done on the main thread; if you don't, it will crash or lock up when you have more than one GUI operation happening at the same time. This is definitely true under windows, but I believe it applies to all platforms. What you will need to do is post an event to the control using GetEventHandler()->AddPendingEvent. Then wx will add the event to the object's queue and when the main thread runs, it can do the GUI operation.
This might not be the exact answer to your question, but it is relevant information.
I found one way of doing it but I didn't try it out in a multi-threaded app.
You can create a pointer to the wxStreamToTextRedirector on a constructor() using new.
And then, don't forget to delete the pointer in the destructor.
wxStreamToTextRedirector is a RAII class associating the stream with the text control in its ctor and breaking the association in its dtor. You can, of course, create it on the heap instead of using it as a local variable or even just manually do what its ctor/dtor do, i.e. call ostr.rdbuf(text) and restore the original value of rdbuf() at some later time.
However, as arolson101 wrote, you'd still could have a problem in your code if you allow multiple threads use the same wxTextCtrl and simple redirection won't help you with this. You would need to write your own custom streambuf-derived class which would avoid outputting the text immediately but post a message to the main GUI thread asking it to do it, which is not completely trivial.