Chaya
asked on
Desktop / MDI clone
We are developing an application that serves as a container to other applications - sort of a "desktop".
The container is to work like an MDI program, in which independent "child" applications work like child
windows in relation to the container application. Our application works in Win'95 and Win'98 and should be Win NT compatible.
The way the program runs is as follows:
* The container application is run.
* Subsequently - from withing the container application, various applications (not all in-house) are invoked using CreateProcess.
The container should then serve as a parent window for each application run.
Originally, after using CreateProcess, we set the container as the parent of this application using the SetParent
function. The problems with this method was:
1. The official Microsoft help documentation states clearly that this method is not allowed (help for the ::SetParent function). It works fine most of the time but upcoming versions may not support it.
2. On some computers, there are problems moving the child applications. The mouse and the window don’t move together, and so on…
So we switched to another method.
Instead of using SetParent, we developed a class that re-implements most of the MDI window features (like: tile, cascade, autotile, close all application, and so on..) But the problem was with handling the focus of the container window. When the container window is activated, we change the z-order of the child applications with the SetWindowPos() function. It works most of the time. But there are specific cases - which we have not been able to pinpoint any generalization of, it doesn’t work. The cases are not consistent so we can’t describe the cases, but it happens. Using SPY we found that the message WM_WINDOWPOSCHANGING is sent to the child
applications but sometimes they don’t get the WM_WINDOWPOSCHANGED.
Creating the applications as ActiveX/COM components does not seem to be an option due to the fact that not all the run applications have been developed by us, and performance loss for those that are "in-house" would probably be too great. Would an ActiveX wrapper be a possibility?
What is your advice? Can we solve the problems in either of our previous methods or do you have another recommended method?
Thank you
Chaya Finkelstein
haya_u@ultramind.co.il
The container is to work like an MDI program, in which independent "child" applications work like child
windows in relation to the container application. Our application works in Win'95 and Win'98 and should be Win NT compatible.
The way the program runs is as follows:
* The container application is run.
* Subsequently - from withing the container application, various applications (not all in-house) are invoked using CreateProcess.
The container should then serve as a parent window for each application run.
Originally, after using CreateProcess, we set the container as the parent of this application using the SetParent
function. The problems with this method was:
1. The official Microsoft help documentation states clearly that this method is not allowed (help for the ::SetParent function). It works fine most of the time but upcoming versions may not support it.
2. On some computers, there are problems moving the child applications. The mouse and the window don’t move together, and so on…
So we switched to another method.
Instead of using SetParent, we developed a class that re-implements most of the MDI window features (like: tile, cascade, autotile, close all application, and so on..) But the problem was with handling the focus of the container window. When the container window is activated, we change the z-order of the child applications with the SetWindowPos() function. It works most of the time. But there are specific cases - which we have not been able to pinpoint any generalization of, it doesn’t work. The cases are not consistent so we can’t describe the cases, but it happens. Using SPY we found that the message WM_WINDOWPOSCHANGING is sent to the child
applications but sometimes they don’t get the WM_WINDOWPOSCHANGED.
Creating the applications as ActiveX/COM components does not seem to be an option due to the fact that not all the run applications have been developed by us, and performance loss for those that are "in-house" would probably be too great. Would an ActiveX wrapper be a possibility?
What is your advice? Can we solve the problems in either of our previous methods or do you have another recommended method?
Thank you
Chaya Finkelstein
haya_u@ultramind.co.il
ASKER
Adjusted points to 400
ASKER
Edited text of question
ASKER
Adjusted points to 1000
If your application is just for windows NT, then you can try CreateDesktop. This desktop will serve as an additional desktop similar to windows desktop. You can run any application on it like you run on the original desktop.
You can switch between desktops using SwitchDesktop.
Other APIs are:
OpenDesktop();
SetProcessWindowStation();
SetThreadDesktop();
CreateWindowStation();
OpenWindowStation();
I hope this serves as another approach to solve your problem.
You can switch between desktops using SwitchDesktop.
Other APIs are:
OpenDesktop();
SetProcessWindowStation();
SetThreadDesktop();
CreateWindowStation();
OpenWindowStation();
I hope this serves as another approach to solve your problem.
ASKER
Thank you rakeshkalra, but, the program MUST work in '95 and '98. I know about the Desktop functions in NT, but they don't help me for '95 and '98. Do you know how to "downgrade them"?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
so you can change the position for a few times.
i think it will work though it is not a good idea.