How to convert my MDI Application to open each window as a separate instance of the application
-
I need my existing MDI application in MFC to be transformed with the below requirement. Every window should look like a completely separate instance of the application – with its own button in the Windows Taskbar. However the windows should be still part of the single application. If there are multiple monitors used, each window of my application can be viewed in the various montitors Please give your suggestions how to convert
-
I need my existing MDI application in MFC to be transformed with the below requirement. Every window should look like a completely separate instance of the application – with its own button in the Windows Taskbar. However the windows should be still part of the single application. If there are multiple monitors used, each window of my application can be viewed in the various montitors Please give your suggestions how to convert
Make a client-server architecture. Each window (running as a separate program) is nothing but a display facilty, just like a web browser, with no application logic, no (application) data structures. Everything is done in your server, i.e. your old application deprived of display facilities. The architecture would be like a database accessed across the web.
-
Make a client-server architecture. Each window (running as a separate program) is nothing but a display facilty, just like a web browser, with no application logic, no (application) data structures. Everything is done in your server, i.e. your old application deprived of display facilities. The architecture would be like a database accessed across the web.
My Application takes very less data (configuration) from text files, rest are all calculations done every second for around 20000 tags or values. If I do it using TCP/IP Sockets that my application may be overloaded for each window. Is there any other option in MFC?
-
Make a client-server architecture. Each window (running as a separate program) is nothing but a display facilty, just like a web browser, with no application logic, no (application) data structures. Everything is done in your server, i.e. your old application deprived of display facilities. The architecture would be like a database accessed across the web.
There is an option in MFC to create application type as "multiple top level documents" which meets my requirements. Can you please suggest how to convert my application from "Multiple Document Interface" type to "multiple top level documents" type. Please advise.
-
There is an option in MFC to create application type as "multiple top level documents" which meets my requirements. Can you please suggest how to convert my application from "Multiple Document Interface" type to "multiple top level documents" type. Please advise.
manoharbalu wrote:
Can you please suggest how to convert my application from "Multiple Document Interface" type to "multiple top level documents" type.
I would suggest creating a dummy program of each type and compare the boilerplate code.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
My Application takes very less data (configuration) from text files, rest are all calculations done every second for around 20000 tags or values. If I do it using TCP/IP Sockets that my application may be overloaded for each window. Is there any other option in MFC?
I do not work with MFC myself, so this is just results from a little documentation searching. TCP/IP is certainly not a lightweight mechanism, but pipes are. In the original Unix design (from the early 1970s), the processes in either end had to have a common ancestor, creating the pipe, but later we got named pipes, CreateNamedPipeA function[^] so that arbitrary processes can communicate across them. This has far less overhead than an TCP/IP socket. You also have the CSharedFile Class[^] and CMemFile Class[^], making RAM look like a file; you use file operations to access RAM. There is the opposite function: To make a disk file look like RAM, a "memory mapped file". In the old days, you couldn't do that from C#, you had to use C/C++. Now I find only the dotNet version (at MemoryMappedFile Class[^]), but of course it is still is provided in C/C++; I just can't find it :-) (I would think that CSharedFile and CMemFile are thin layers on top of that mechanism.) You may be more clever than I am in finding the C++ equivalent. It is there, somewhere... A memory mapped file does not require an underlaying disk file; you use the same facility for creating a data segment accessible from multiple processes. Using a shared segment, a.k.a. a memory mapped file, is certainly the fastest way to exchange data between processes, comparable to threads accessing shared data within a process: The memory management system handles it. The greatest advantage, compared to a file/pipe solution: You don't have to serialize (or marshal, or whatever your call it) your data structures, but can access them "as is". For pointer based struct
-
I do not work with MFC myself, so this is just results from a little documentation searching. TCP/IP is certainly not a lightweight mechanism, but pipes are. In the original Unix design (from the early 1970s), the processes in either end had to have a common ancestor, creating the pipe, but later we got named pipes, CreateNamedPipeA function[^] so that arbitrary processes can communicate across them. This has far less overhead than an TCP/IP socket. You also have the CSharedFile Class[^] and CMemFile Class[^], making RAM look like a file; you use file operations to access RAM. There is the opposite function: To make a disk file look like RAM, a "memory mapped file". In the old days, you couldn't do that from C#, you had to use C/C++. Now I find only the dotNet version (at MemoryMappedFile Class[^]), but of course it is still is provided in C/C++; I just can't find it :-) (I would think that CSharedFile and CMemFile are thin layers on top of that mechanism.) You may be more clever than I am in finding the C++ equivalent. It is there, somewhere... A memory mapped file does not require an underlaying disk file; you use the same facility for creating a data segment accessible from multiple processes. Using a shared segment, a.k.a. a memory mapped file, is certainly the fastest way to exchange data between processes, comparable to threads accessing shared data within a process: The memory management system handles it. The greatest advantage, compared to a file/pipe solution: You don't have to serialize (or marshal, or whatever your call it) your data structures, but can access them "as is". For pointer based struct
All you are talking about is called IPC ([Interprocess Communications - Win32 apps | Microsoft Docs](https://docs.microsoft.com/en-us/windows/win32/ipc/interprocess-communications)). However, the OP didn't ask about IPC. instead the OP wants to have exactly one application in which all the opened "documents" look like in MS Office (Word, Excel, ...)
-
All you are talking about is called IPC ([Interprocess Communications - Win32 apps | Microsoft Docs](https://docs.microsoft.com/en-us/windows/win32/ipc/interprocess-communications)). However, the OP didn't ask about IPC. instead the OP wants to have exactly one application in which all the opened "documents" look like in MS Office (Word, Excel, ...)
-
I cannot disagree... however, it depends.:cool:
-
All you are talking about is called IPC ([Interprocess Communications - Win32 apps | Microsoft Docs](https://docs.microsoft.com/en-us/windows/win32/ipc/interprocess-communications)). However, the OP didn't ask about IPC. instead the OP wants to have exactly one application in which all the opened "documents" look like in MS Office (Word, Excel, ...)
Thanks that you got my requirement correctly. All I need... is a single application in which all the opened documents looks like in MS Office (Word, Excel). There is already an option in MFC to create application type as "multiple top level documents" which meets my requirements. Can you please suggest how to convert my existing MDI application from "Multiple Document Interface" type to "multiple top level documents" type. Please help.
-
Thanks that you got my requirement correctly. All I need... is a single application in which all the opened documents looks like in MS Office (Word, Excel). There is already an option in MFC to create application type as "multiple top level documents" which meets my requirements. Can you please suggest how to convert my existing MDI application from "Multiple Document Interface" type to "multiple top level documents" type. Please help.
David Crow already answered it: [Re: How to convert my MDI Application to open each window as a separate instance of the application - C / C++ / MFC Discussion Boards](https://www.codeproject.com/Messages/5757598/Re-How-to-convert-my-MDI-Application-to-open-each)