Multiple processes rendering to one window
Two processes, two windows, but one window acts as another window's child window.
For example a window contain a edit ctrl, but the edit ctrl is belong to another process.
How can I implement such a MFC application?
I don't think having more than one thread managing UI stuff is a good idea at all.
You should just have one thread in charge of the UI (main thread) and create as many working threads as you need. But these working threads do not access UI directly but they notify (SendMessage / PostMessage) the main thread to do the UI work.
The window and its child must belong to the same process. Period.
What you can do is redirect the output of a process (such as stdout) to a pipe. The GUI process in turns reads the pipe and display the contents into the dedicated child window (edit box or other).
This MSDN article about input/output redirection may help.
Actually you can achieve this, but has some limitation.
For example, you can embed MS word in your app. The Word window is embedded as a child window in your app. but actually, there is another process winword.exe.
Your app works as compound document container and the embedded one act as compound document server.
Please find "compound document" related stuff from MSDN.
Related
OK, so a noob question here: How do you code this functionality that browsers have for example? You open a chrome browser for example and you can open multiple tabs open. Then you can move one tab out of the window and it becomes another window, having its own separate process. Then you can drag that tab into another window and they become one frame? Similar to docking in windows applications, but how do you do it with executables?
Windows-specific answer, though I think other OSs work pretty much the same: the HWND handle that you get for a window is global. If you send its numeric value to a different process, that process can use it to do things with the window: get its information, resize it, even draw on it. What it can't do is replace its event handler function.
To get process separation like browsers have nowadays, the key is to create a container window and send the handle to the child. The child then creates its own window as a child of the container. The child window simply fills out the entire content area of the container.
This way, the content process is contained within the parent's window, but can handle events.
Now, if you want to drag out a tab into its own top-level window, the parent process creates a new top-level window with all the UI inside, and then re-parents the content container to this new top-level window. The content child follows along.
I can't tell you how to code it, you should search the feature inside the chromium code to know how it's coded but I can tell you how it works:
Inside chromium every tab, extension, utility, etc is a process, each one of these processes is child of the "Browser" process, the "Browser" process manages everything (creating new windows, opening new tabs, closing tabs, destroying windows etc) so, for example, whenever you open a new instance of chromium you are telling the "Browser" process to create a new tab and put it inside a new window.
Every window is managed by the "Browser" process and every tab is managed by a process that is child of the main process.
Now to reply your question: when you drag & drop a tab outside a window you're triggering an event that is caught by the "Browser" process which then create a new window and assign the tab to the new window.
Those informations should give you a hint on how you could develop this feature yourself.
If you want to know more about the chromium architecture I suggest you to read how chromium is designed at https://www.chromium.org/developers/design-documents
I have dialog box and in it, it has OK and Cancel buttons then it also has a ListBox to display text in two columns. I would like to continue adding text into the ListBox after the dialog box is shown. How can I do that? Because after I call DoModal() to show the dialog box, the code does not continue to execute. Or should I create two threads (one is display dialog box while another thread continues adding text to dialog box)?
Make your dialog 'pull' the data it needs, maybe polling the data source with window messages every second, or every 100ms or so. Or, if you go the 'two threads' route (the better but more complicated option), have your data source post a window message to your dialog when there is new data, and then have the dialog fetch the data it needs. The reason for this is that it's much easier to use the existing CDialog infrastructure to get a window that behaves like an actual dialog, compared to building a modal window that acts like a dialog but isn't really.
If you do go the two threads route, your division of labor should be: one thread that does all the UI work (including showing the dialog), and one that 'generates' data and lets the UI know when there is new data. So the worker thread should not do anything related to the UI, nor call any methods on the dialog directly - you can't access windows from several threads. The only cross-thread window communication should happen through window message (i.e., use ::SendMessage()). So certainly don't do something like myDialog->m_theList.AddString("blah") from another thread, or something like it.
Showing a dialog box modally halts further execution until you close the box. Instead of showing it modal, show it normal but make it always on top so you can continue executing the code after the call to DoModal(). Alternatively, populate the box with all the info it will need before you call DoModal().
If you decide to take the "two threads" approach you will discover that the controls on MFC dialogs should not be updated or accessed from a thread other than the one that created the dialog. Even if you have pointers to these controls available in another thread it is not thread-safe to access them. This rule applies whether or not the dialog is modal.
Instead, your second thread would need to PostMessage or SendMessage to the dialog window, so the updates occur on the thread that created the dialog (most likely the main UI thread of the application).
I have a simple win32 application that uses the createProcess method to call Qt application.
The problem is that I like to bring the Qt application to the foreground.
Who is responsible for this? The parent win32 app or the Qt application?
The application that currently has the foreground focus is the only one that is allowed to change the foreground focus. You need to use the SetForegroundWindow function to exercise this right.
The "Remarks" section in the documentation contains an applicable list of restrictions:
The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true:
The process is the foreground process.
The process was started by the foreground process.
The process received the last input event.
There is no foreground process.
The foreground process is being debugged.
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
No menus are active.
An application cannot force a window to the foreground while the user is working with another window. Instead, Windows flashes the taskbar button of the window to notify the user.
The real question is why you need to do this at all. Changing the foreground application is very likely to get you into trouble, either with all of the restrictions that Windows places on it, or with your users. It's a very user-hostile action, which is one of the reasons why Windows has tightened up the restrictions on it in recent years.
Get the window handle of the Qt application and call SetForegroundWindow
http://msdn.microsoft.com/en-us/library/ms633539.aspx
You probably want to do it from the parent process. The cleanest/most dependable way to use SetForegroundWindow is to call it from the process that's currently in the foreground.
I'm programming a very big software.
It has a lot of projects inside it.
One of my projects is a UI thread. I want to post messages to this UI thread, from the main project.
When I use PostThreadMessage (after getting the thread by GetCurrentThreadId() ), everything works fine, except the times when a MessageBox is open...
So I want to send messages from the main project by PostMessage. How exactly can I send messages in that way? how do I know which window to send the message to?
Thanks
If it is an UI thread then you must have a primary window created in that thread. Just post message to this window. That's it.
EDIT 1: If it is another process, then probably you can create a hidden window with some unique title with special characters and underscores and use FindWindow API to find that window or use EnumWindows to enumerate top level windows and match the title.
I have written a sample MFC application in which there are two threads:
-Main thread ( UI thread)
-Worker thread ( non-UI thread)
I have a specific requirement to create a Modal dialog in Non-UI ( worker thread).
When I create the CDialog object and call DoModal on the same, it works. The dialog gets created and acts as Modal to the application. ( Win XP SP2 machine) But this does not work in Windows 2003 server machine.
The behavior in 2003 server is that, the Modal Dialog goes behind the application main Window and dialog will be brought to front only when I click on Main Window. It is not acting as Modal dialog to my application.
What could be the problem -- any ideas?
If creating UI controls in non-UI thread is the issue then is there any Win32 API which will allow me to link my worker thread to Main UI thread such that DoModal happens in Main thread. I tried AttachThreadInput but it is not working.
There is no reliable way to spread GUI modality across multiple threads. Every window is represented by an object referenced through a HWND which in turn has thread affinity. This is a left-over from the 16-bit days of Windows, where there was no multi threading. Consequently the HWNDs are not protected against concurrent access. The Old New Thing has an excellent series on "Thread affinity of user interface objects" (Part 1 2 3 Addendum).
Modality is implemented by first enabling the dialog window and then disabling its parent. The first step is safe while the second attempts to disable a window from a thread which is not the window's owning thread. Since en-/disabling windows modifies the object referenced through the HWND it represents a race condition.
The suggested solution is to confine your GUI to a single thread and communicate from your worker thread to the GUI thread to have it perform user interaction on the worker thread's behalf. The easiest way to accomplish this is to call SendMessage from the worker thread to block until the GUI thread's message handler returns. If the worker thread should continue to run while the dialog is displayed you could use PostMessage instead and communicate back to the worker thread using PostThreadMessage or signaling a synchronization object like an Event Object.
First of all, I'd like to agree with other posters that it's probably better to show the dialog on the main UI thread.
However, if you must, you can make a dialog on another thread modal with the following steps:
Pass your active window as an owner when creating the dialog.
When dialog is showing, iterate over your other windows and do them EnableWindow(FALSE). When the dialog is hiding, do the reverse. You will probably have to remember windows' enabled state and restore the original state, not just EnableWindow(TRUE).
Ensure that accelerators and other global commands will be ignored while the dialog is shown.
Note that (2) shouldn't be necessary provided that you do (1), but you've mentioned MFC, and I don't remember exactly how it behaves. It has it's own modal dialog implementation which may not exactly match Win32. If you're lucky, (1) and (3) will be enough.
While i don't know about the specifics of dialog handling on Server 2003, the simplest workaround to get on the main thread would be to use a custom window message, do ::SendMessage() and display the dialog in the message handler.
I recommend you not to do what the question subject suggests, and confine all UI to one thread. If you need the other thread to communicate with the user, create some messaging mechanism that will ask the UI thread to do it, and transport the results back.