I am working on a feasibility task, where I need to start an application in a custom desktop (programmatically created desktop, using CreateDesktop()).
Scenario:
ConsoleTestApplication: Use ShellExecute() to start an MFC application, LaunchingApp
LaunchingApp: Creates a new custom desktop and start a WPF application using ShellExecute(). The WPF application should open in the custom desktop.
The above scenario works while using CreateProcess(). When I tried with ShellExecute(), the custom desktop just glitched away, and didn't work.
Does ShellExecute() work along with custom desktop creation?
Is there any possible way to solve the above scenario using ShellExecute()? Can you suggest a solution for this?
Neither ShellExecute() nor ShellExecuteEx() support launching processes on alternative desktops, only on the desktop of the calling thread.
So, you would have to either use SetThreadDesktop() before ShellExecute/Ex(), or else just use CreateProcess() instead, which supports alternative desktops, as you noted.
ShellExecute/Ex() will simply delegate to CreateProcess() when launching an EXE file, so you really should just use CreateProcess() directly. Use ShellExecute/Ex() only when launching data files (or when you need to force an EXE to launch with UAC elevation).
Related
Basically, I was expecting CloseDesktop() would do something like this, but looks like it only closes the handle to the desktop (it returns 1, however) and I can always get a new handle to the desktop by its name via OpenDesktop().
Is there any way to kill everything created in this desktop and the desktop itself?
Windows are tied to the desktop they are created on so you can use EnumDesktopWindows to enumerate and close/kill the windows/processes on a specific desktop. Killing the process might be a bit extreme since it can have windows (belonging to other threads) on a different desktop.
I've been making a simple application which is able to launch a variety of other applications through QT5 (using QProcess class) but I've been running into a few key issues with the design. Specifically, it seems that Qprocess cannot set focus to windows that have been created via QProcess' start() function. This means that once a user opens more than one window, it can never return to the previous window that has been opened. After looking further into this dilemma, it has become clear that my program will need to be able to handle basic window management in order to fulfill my specifications.
I've decided that the best example to study for my program is Docky, which is capable of opening, closing and switching windows. Looking at the source code for that project was helpful, but there were many C# system calls that were used for fetching the list of client-windows which aren't available for my C++ program.
How can I get a list of all the X11 Windows that the client is running and provide basic window management (Switch To/ Open / Close Window) using C++? Is there a cross platform way of doing this through QT? Can I get this information directly using XServer?
I may be approaching this in completely the wrong way as I am pretty new to the C++ language and the overall way this kind of application should be structured, but I hope to confirm the correct method here.
Essentially, I have one cpp file which operates as a console application & a separate cpp file which runs as a windowed application. I want to be able to launch the windowed application when a certain point is reached within the console application. Is this possible? If so, how would I go about doing this?
Some more detail - The console application acts as a 'server' using winsock to communicate with another console application (the client). When the console server application reaches a certain point (a client connects with it) I wish to then launch the other windowed application I have created which will render certain graphics onscreen using Directx. Currently I have both these cpp files as separate projects in a single C++ 2010 Express solution. Currently, there are no links between the two cpp files and they both operate correctly when run separately.
If any more specifics are required, I can provide them but I really want to find out if this approach in general will work.
Thanks.
If you are not running a managed C++ application, then CreateProcess is the canonical WIN32 system call to use.
Do you just want to run the exe from another exe?
System::Diagnostics::Process::Start("C:\\Folder\\file.exe");
I did a project of Server Socket in Visual studio in C++ MFC based. Now, after debugging the project, server GUI opens, then after clicking on the CONNECT button on server GUI, you can connect the clients to that server and so on.
Now I want to use that server exe file in some other computer. So that whenever that computer starts, that server exe automatically starts. so for this i need to disable the connect button, so that after debugging, server GUi opens and connected automatically. But i don't want that server GUI opens in another computer in autostart as well. i want to disable that server GUI.
I got an idea of modalless dialog to work on it. Is it good or what approach should I use ?
You probably want to separate GUI part and server part of your application. Ideally, if your server is actually a server, you should start it as service. Then you will have separate GUI tool to control it.
Another approach is to have command line argument that determines whether server should be started with GUI enabled or disabled.
The only professional and stable solution of such an application is, to splitt it in a console part, which you put under the control of service control and a gui part wich the user can start when he wants.
I tried solutions like yours and so I can tell you from my own experience, that you will face a lot of problems.
However, a possible solution would be to hide the window and lay the app down to systray and this is a very interesting discussion about hinding windows.
Additionaly I have two good advices in case of MFC:
Never ever just "copy-past" code without to know what MFC is doing in the background (Win32api).
Do not use MFC. Have a closer look at QT or wxWidges when you need windows, to shortcut encapsulation of win32api also have a look at boost library. It is realy worth the time you spend on!
Good luck!
I need to customize right click so that I can scan a directory with my anti-virus. I know how to do that using registry keys, but the problem is that I don't want to start a new instance of my program every time I want to scan a directory. My anti-virus needs to load some signature databases so it will take around 15 seconds for the program to load those. I need to use the instance of the program which I have already opened and is running for scanning the directory. How can I do that?
I am using C++Builder.
Thanks.
Considering you already know how to add the item to the right click contextual menu, I suggest implementing a client/server set of applications:
A server that loads up when you turn your computer on and does the scanning, and
The client that tells it what to do using IPC - inter-process communication.
You then add the client application to various contextual menus, passing it arguments that indicate what it should get the server to do depending on what you right-clicked on.
IPC is a bit of a pain in the butt, the easiest way is to use TCP/IP to and do local networking using a network library. There are many out there, however given you'll likely want to have other features such as UI elements and a tray icon, I suggest you look at Qt, namely the following components:
QtNetwork: For performing communication between the client and the server executable.
QSystemTrayIcon: For displaying a small icon on the tray.
There are quite a few other little bits of Qt you'll no doubt encounter (like all the fabulous UI stuff), and fortunately Qt is well documented and help is always available here, and from the Qt Developer Network. You can get started with Qt by downloading and installing the SDK:
http://qt.nokia.com/downloads/
Best of luck :).
Implement a DDE server in your anti-virus, and then add a ddeexec subkey to your Registry key. Alternatively, add an OLE Automation object to your app that implements the IDropTarget interface, and then add a DropTarget subkey to your Registry key that specifies the object's CLSID.
Either way, whenever your menu item is then invoked, Windows will call into your existing app instance if it is already running, otherwise it will launch a new instance and then call into it. Either way, Windows is handling all of that for you. All you are doing is providing an entry point for Windows to call into.
I would suggest the IDropTarget method, because DDE is deprecated, and because IDropTarget is more flexible. While your app is running, you could re-use the same IDropTarget object to handle OLE Drag&Drop operations on your app's UI window and Taskbar button, and support automated invokations of your scanner by other apps.