DonationCoder.com Software > Find And Run Robot

Running FARR (and other) on virtual desktop

<< < (2/2)

JamesWatt:
I have now tried using VirtuaWin and It seems to be
capable of handling my demands.

So there should be no immediate necessity to
change FARR  :-[

yarond:
Hi,

I know I'm reviving a really old thread here, but since it does contain the background I figured it will be better than starting over.

Basically I came up the same problem, I've started to test Desktops, and have the same issue with FARR opening its window on the original first desktop rather than the active ones.

But... Looking a bit at the relevant APIs and documentation, I think that handling this is fairly straight-forward, and depending on what FARR does behind the scenes might even be very quick and easy.

So, some additional details that were missed in the original discussion: True, there is no way to transfer windows between desktops. But, and it's a big but, there is no problem creating new windows, from new threads, on different desktops.
Once an application thread interacted with the UI it's locked to a desktop. But a new thread, on the same application, can work with other desktops (such as the "currently active" one) without a problem.

The cost on the program is to have a different UI thread for different desktops. Which depending on how the existing code goes would mean either creating a new UI thread any time the window is shown, or instead just creating new duplicate threads for different desktops and keeping that pool.

For example, basic C code with WIN32 API that creates a message-box on whatever the currently active desktop is. Calling this from within the thread procedure, before the thread interacts with any windows, creates the messagebox on the active desktop instead of the one originally used by the application:


--- ---Sleep(4000);   // Just to give the user time to switch desktop for testing, without any UI interaction
HDESK hDesk=OpenInputDesktop(0,TRUE,GENERIC_ALL);  // Gets the currently active desktop
if (hDesk!=NULL)
{
BOOL bSuccess=SetThreadDesktop(hDesk);  // fails if the thread already interacted with a window, but on a new thread should be fine. Also, if keeping existing threads and switching between them then this isn't needed when hDesktop is known
if (bSuccess)
{
MessageBox(NULL,TEXT("Switched to the active desktop"),TEXT("Success"),MB_OK|MB_ICONINFORMATION);  // This will appear on the active desktop
CloseDesktop(hDesk); // Not to leak the handle
} // No error handling in this sample, but it won't fail if the thread really didn't do any UI interactions.
} // No error handling in this sample. But shouldn't realistically fail when generated by a user on the computer since there will be a desktop

Any chance of you considering making such a change in the foreseeable future? I really do like the behavior of Desktops compared to the other (hide/show windows) programs of the type, but using FARR with it currently is very clunky.

Navigation

[0] Message Index

[*] Previous page