Running FARR (and other) on virtual desktop

[JamesWatt]

Hello,

I've encountered a problem with programs like FARR when using hotkeys.
I'm using Desktops by Sysinternals from Microsoft.
Desktops in this context are separated views for the screen which are based
on distinct processes.
So one desktop doesn't know of other programs running on other desktops
and a program does'nt get the messages or keystrokes.
Therefore you have to start e.g. FARR on every desktop you wanted to run it.
But the effect is, that only one process of FARR gets the keystroke "Break".
So when I'm on another desktop the "Break"-Button will not work.
My question is, does anyone have similar experiences and knows of a workaround?

I have already contacted Mouser and he encouraged me to post it.

Thanks
Markus

[mouser]

Very interesting.. anyone else know anything about this?

It's the first i've heard of it and it does seem like something we need to fix so that it gets invoked no matter what desktop one is on.

I will try downloading the Sysinternals Desktops program.. the only other multiple desktop tool i've used is VirtuaWin, but i see we've discussed it here and the comments are pretty negative.

We've discussed a bunch of alternative virtual desktop tools here and here.

This must be something that affects other kinds of programs.. I wonder if there is some setting somewhere in the sysinternals program (or other virtual desktop tools) that can solve it.


-jesse

[mouser]

Reading the Sysinternals page on their "Desktops" program is quite interesting, and might be something those of you who like this kind of esoteric windows-internals stuff would be interested in:

http://technet.microsoft.com/en-us/sysinternals/cc817881.aspx

Unlike other virtual desktop utilities that implement their desktops by showing the windows that are active on a desktop and hiding the rest, Sysinternals Desktops uses a Windows desktop object for each desktop. Application windows are bound to a desktop object when they are created, so Windows maintains the connection between windows and desktops and knows which ones to show when you switch a desktop. That making Sysinternals Desktops very lightweight and free from bugs that the other approach is prone to where their view of active windows becomes inconsistent with the visible windows.

Desktops reliance on Windows desktop objects means that it cannot provide some of the functionality of other virtual desktop utilities, however. For example, Windows doesn't provide a way to move a window from one desktop object to another, and because a separate Explorer process must run on each desktop to provide a taskbar and start menu, most tray applications are only visible on the first desktop. Further, there is no way to delete a desktop object, so Desktops does not provide a way to close a desktop, because that would result in orphaned windows and processes. The recommended way to exit Desktops is therefore to logoff.

SO.. it sounds to me like Desktops is a very strange virtual desktop tool.  I think the best solution to the FARR problem might be in fact to stop using Desktops and start using something like VirtuaWin or Dexpot, or another "normal" virtual desktop tool.

But it still leaves two questions: 1. is there a way to make programs like FARR work right on Sysinternals Desktops, and 2. Is there some real value in the unusual way Sysinternals Desktops works that offsets the strangeness of the way it works (or is it more of a circus attraction)?

[skajfes]

Unlike other virtual desktop utilities that implement their desktops by showing the windows that are active on a desktop and hiding the rest, Sysinternals Desktops uses a Windows desktop object for each desktop. Application windows are bound to a desktop object when they are created, so Windows maintains the connection between windows and desktops and knows which ones to show when you switch a desktop. That making Sysinternals Desktops very lightweight and free from bugs that the other approach is prone to where their view of active windows becomes inconsistent with the visible windows.

Desktops reliance on Windows desktop objects means that it cannot provide some of the functionality of other virtual desktop utilities, however. For example, Windows doesn't provide a way to move a window from one desktop object to another, and because a separate Explorer process must run on each desktop to provide a taskbar and start menu, most tray applications are only visible on the first desktop. Further, there is no way to delete a desktop object, so Desktops does not provide a way to close a desktop, because that would result in orphaned windows and processes. The recommended way to exit Desktops is therefore to logoff.

SO.. it sounds to me like Desktops is a very strange virtual desktop tool.  I think the best solution to the FARR problem might be in fact to stop using Desktops and start using something like VirtuaWin or Dexpot, or another "normal" virtual desktop tool.

Hmm, running 4 instances of explorer.exe doesn't seem very much lightweight to me. It is an interesting concept but I think it provides too much separation between virtual desktops so you can't move windows between desktops etc.

I've been using VirtuaWin for some time now and I am very satisfied with it.

[JamesWatt]

Hello,

I've also tried other desktop programs and my experience was that sometimes windows tend to get hidden when moving from
one desktop to another and that in my opinion the separation of the view is rather an advantage than a disadvantage.
I've never experienced something like a crash of the desktop program and had never to start again as a result of lost windows.

As other normally use the functionality to hide and show windows they seem to be more prone to errors.

Markus

[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:

Code

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.