Some programs don't move to new desktops

[eksime]

[ChipRab]

This happens to me when i try to start Skype in a separate desktop......no matter what i do, it starts on the current desktop....

[eksime]

It's to do with the way the applications start their main window I think.

I'm looking for an alternative way to move an application. I may have to resort to what the old vdesk did, in that it created the new desktop first; switched to that desktop; and then started the program.

The issue with that method is that switching back to the previously used desktop is difficult, since it still relies on being able to detect when a process has created its main window, which is the issue with the way it works currently.

[ghost]

Double that. VirtualBox instance starts on the current desktop no matter what. Although new desktop is created as well. Starting VBox as described in readme here.

[dlgltlzed]

I run several commands and notepad always opened in the current virtual desktop:

vdesk run notepad test.txt vdesk run-switch notepad test.txt vdesk run-on 2 notepad test.txt vdesk run-on-switch 2 notepad test.

[egeozcan]

For me, notepad works. Chrome, however, not. I have Windows 10 Anniversary Edition.

[dlgltlzed]

I updated windows to the latest version. Now it works. I tested "vdesk run" with notepad and Chrome.

[egeozcan]

@moglars If that's what you mean, I applied all the updates and I still have the same behavior.

[egeozcan]

@moglars nevermind, windows decided to restart by itself and now it seems to work. I looked for the specific update which would fix this issue but haven't found something yet.

Can anyone else confirm this?

(unrelated rant, ignore: why on earth windows thinks it can trash all my working state and restart without asking me!)

[eksime]

This should be fixed in the latest release, see the readme for more information regarding chrome.

If you could let me know if it is fixed, I'll mark the issue as resolved.

More info: Programs launching in the current desktop was a result of them not launching their main window in a predictable manner, or using another process to launch their window (Chrome). Vdesk would previously launch a process, then wait for that process's main window handle to be != 0. This did not work for certain applications, but was the only solution to launching a program on another desktop without first having to switch to that desktop.

Of course if you could predict if a program was going to ever provide a main window handle that would be ideal... but that's a whole other can of worms as far as I can work out

*-switch commands now cause windows to switch to the desktop, then launch the process, not the other way around. The "new" behaviour is how vdesk 0.1 worked and it had less issues with programs like chrome, although it was far less flexible.

[ChipRab]

I noticed that you fixed the issue with the *switch command, but i actually use the "run-on" command to start Skype.......should i use "run-switch" instead?

[eksime]

Yes, unfortunately there isn't a way to fix the "run-on" commands to work with programs like Skype or Chrome (That I know of - a pull request would be welcome here!)

Using run-switch will switch to the desktop in addition to (hopefully) launching Skype on it.

[mjsure]

Visual Studio 2015 always seems to launch on the current desktop when using the run-on command as well.

[mzomparelli]

A fix for this could be to let the app load up and then check which desktop it is on. If it's on the wrong desktop then move it. The user might see the window flash, but I think this would be acceptable. I'm trying to implement similar functionality into an app that I built. I'm going to fork this to see if I can come up with something to resolve this for you.

https://github.com/mzomparelli/zVirtualDesktop

[eksime]

@mzomparelli That is sort of what vdesk currently does; however the issue is that some programs do not launch in the same way as others - like chrome, which requires extra flags to create new windows, or metro apps. Currently vdesk launches the process then immediately tries to swap it to the correct desktop, if it can't find the window handle, it waits x seconds and tries again. This process repeats and the value of x increases exponentially until the wait time is around 8 seconds, before giving up.

The problem is: how do you tell when a program is "done" starting up? Some programs don't present a main window until they're fully loaded, others will never present a main window, and instead launch a child process which does. I do appreciate any help, but it's something I've been thinking about a lot and can't see any simple solution that will work in all cases.

[mzomparelli]

Maybe you can use a Windows hook and know when a window has been created and when it gets foreground focus. I use both of these already and I'm going to give this a try.

SetWinEventHook(EVENT_SYSTEM_FOREGROUND, EVENT_SYSTEM_FOREGROUND,
                IntPtr.Zero, WindowChangedCallback, 0, 0, WINEVENT_OUTOFCONTEXT | WINEVENT_SKIPOWNTHREAD);

SetWinEventHook(EVENT_OBJECT_CREATE, EVENT_OBJECT_CREATE,
                IntPtr.Zero, WindowCreatedCallback, 0, 0, WINEVENT_OUTOFCONTEXT | WINEVENT_SKIPOWNTHREAD);

[DllImport("user32.dll")]
        private static extern IntPtr SetWinEventHook(uint eventMin, uint eventMax, IntPtr
                hmodWinEventProc, WinEventDelegate lpfnWinEventProc, uint idProcess,
            uint idThread, uint dwFlags);


        const uint WINEVENT_OUTOFCONTEXT = 0x0000; // Events are ASYNC
        const uint WINEVENT_SKIPOWNTHREAD = 0x0001; // Don't call back for events on installer's thread
        const uint EVENT_SYSTEM_DESKTOPSWITCH = 0x0020;
        const uint NOTIFY_FOR_ALL_SESSIONS = 1;
        const uint WM_WTSSESSION_CHANGE = 0x2B1;
        const uint WTS_SESSION_LOCK = 0x7;
        const uint WTS_SESSION_UNLOCK = 0x8;
        const uint EVENT_OBJECT_CREATE = 0x8000; // hwnd ID idChild is created item
        const uint EVENT_OBJECT_DESTROY = 0x8001; // hwnd ID idChild is destroyed item
        const uint EVENT_SYSTEM_FOREGROUND = 3;

[Cyber5imon]

In case anyone is interested, here is a workaround: vdesk on:5 run:ping & "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" "http://www.google.com" Any app can be run after the & and will correctly open on the virtual desktop.

Granted this does go to the virtual desktop, but if you want to return, simple add & timeout 3 & vdesk on:3 run:ping after the chrome statement. The entire command would look something like this: vdesk on:5 run:ping & "C:\Program Files (x86)\Google\Chrome\Application\Chrome" /new-window "http://www.google.com" & timeout 3 & vdesk on:3 run:ping