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.
Related
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).
I'm building a C++/MFC desktop app that shares a lot of data with an USB device.
Because of how this devices works I need to close and open the virtual COM I use, severl times per minute.
Everything works well, but I would like to stop the annoying Windows USB connected/disconnected suound, that comes up every time I connect or disconnect the device.
So my question is: is there a way to disable/enable Windows event sounds (or a single event sound, even better) through my C++ code?
Obviously I could somehow turn down the volume, but that's not what I want, since it would stop sounds from every other app.
Is there a way to do something like this?
Thanks!
I'm trying to use QSharedMemory and QClipboard to share data between a SYSTEM process (running on the WinSta0\\Winlogon desktop) and a normal user process, but both fail to share data with others non-SYSTEM processes running on the normal desktop. I belive this is because the WinSta0\\Winlogon desktop is a isolated desktop.
My app is a program that takes shots of the Windows Secure Desktop and send it to clipboard.
The question is: Is there any way to share memory data between that process and non-SYSTEM processes? (Actually I'm using a file to do the job).
On Windows Vista and later, system services run in an isolated session ("session 0"). This is the most likely cause of your problem. (Note that all system services run in session 0, regardless of whether they are running in the SYSTEM security context or not. Similarly, it is possible to launch processes as SYSTEM in an arbitrary session.)
Each session has a separate WinSta0 workstation, and hence a separate clipboard. So clipboard functionality is not going to work here.
It is possible for file mapping objects (shared memory) to work across session boundaries. However, I don't know whether it is possible to do this with Qt. The best bet would appear to be to use setNativeKey which presumably determines the name of the file mapping; to make a file mapping cross session boundaries, use a name that begins with Global\ as described in the MSDN article on CreateFileMapping. If possible, consider using the Win32 API directly rather than Qt.
I'm working on a small C++ project which involves a launcher application that does a bit of setup work and then invokes the real application. To be precise, I'm working on the launcher application - the real application is done by a separate team. These programs are both deployed to Windows Mobile devices. Now, I'd like to be able to get notified of all keyboard and mouse activity in the real application (which my launcher starts) - and I cannot modify the real application to do this.
On Windows desktop machines I'd do this using the SetWindowsHookEx API. However, this is unavailable on Windows Mobile.
I also considered subclassing all windows in the process so that I can handle the relevant window messages for keyboard and mouse input - but I don't know how to get notified of new windows which the real process creates.
Does anybody have some thoughts on how to achieve this?
You can use SetWindowsHookEx, it is only undocumented. This is a good post about hooks and subclassing on Windows Mobile.
I have a 32bit application running on Windows 7 64bit. The application (written in C++) hosts a WebBrowser control.
When the WebBrowser control is asked to popup a new windows (through a javascript window.open() call), it launches a new Internet Explorer process. In particular, this new IE process is a 64bit IE process.
Since web pages love Adobe Flash, I unfortunately need to make sure new IE process that is launched is the 32bit version (which is the default on my machine), so that AdobeFlash content can be displayed.
Interestingly enough, IE itself (wrapper around WebBrowser/MSHTML) does not suffer this problem, implying there is some kind of configuration that could be set to hint to the WebBrowser control to launch a 32bit process.
Any ideas where I should be looking to ensure that WebBrowser / MSHTML create the right process?
I suggest you to handle the DWebBrowserEvents2::NewWindow2 event. You can either open it in a webbrowser control in your own process, or in a new CLSID_InternetExplorer object.
This might be overkill for your application, but for me, changing the Platform target to x86 prevents 64-bit IE from being used either in the controls or in popups.