I get a popup saying that hotkeys cannot be assigned upon startup.
Intel Graphics and Media Control Panel Hotkey conflicts with hotkey assignment on install of virtualwin resulting in error message “Failed to assign hotkey”. Disabling the hotkey assigments from Intel Graphics Control Panel resolves the issue. Conflicting Hotkeys include ctl-alt-[right arrow] and ctl-alt-[left arrow].

Some applications refuse to disappear when I change desktop.
Yep. Some applications use a special type of window (ex. Winamp and ICQ). This makes it hard for VirtuaWin to find them. But it is possible to configure manually how VirtuaWin should treat them, see the help about “Window Rules”.

At first I (Johan Piculell) just wanted to try some win32 programming and try to build the perfect window manager for my needs. It turned out to be quite good, and I saw no reason to charge for it since that was never my intention. I also believe that I would not have had so many downloads as I have had if it wasn’t free. That is nice, of course.

VirtuaWin appears to freeze on first operation/action, for example on first desktop change; the problem has been related to the use of Symantec Client Firewall, specifically version 8.7.4.97. This issue has not been fully understood or resolved, however it seems that the problem can be avoided and therefore no further investigation is currently planed.So far two suggestions have been made on how to resolve the problem:

1. Disable the Symantec Firewall, start VirtuaWin and verify VirtuaWin is running correctly, re-enable the firewall and verify that VirtuaWin is still running correctly. Doing this once appears to permanently resolve the issue (which is strange but helpful).
2. Install and run MS Powertoys – TweakUI and in this tool disable the ‘Prevent applications from stealing focus’ option.

However as this problem seems a little random these solution may not work for you. See SF bug 1783794 for a more complete account of our investigation, if a solution cannot be first please create a new posting on our Questions forum.

This can be reproduced by using Explorer’s Send To -> Mail Recipient feature, the Send button in the opened Message window is unlikely to work. The main menu’s File -> Send item also does not work. This is a common Outlook issue with no known solution, the best workaround for the problem is to use the Ctrl+Enter Send shortcut key.
See the SF bug notes for further information, if you know of a solution to this problem please email it to VirtuaWin support.

This is caused by a bug in the ‘Group similar taskbar buttons’ feature of the Windows taskbar, it cannot always correctly handle the large number of window state changes that occur during desktop change. There is no possible VirtuaWin fix as the problem cannot be avoided without unacceptably affecting performance.
The issue can be avoided be disabling this taskbar option, this makes sense as the use of VirtuaWin should avoid the need of such a feature.
However, if this is not viable the gap can be removed by using the Alt+Tab to change to another task and then use Alt+Tab to change back again.

For reliability and speed considerations.The absolute top priority for VirtuaWin is reliability, VirtuaWin must not crash or lose windows, it is better for it to not start or not manage a window than to attempt to and then fail losing windows in the process. The next priority is performance, if desktop swapping is too slow the program is simply unusable.Using static data structures vastly improves the reliability and performance of VirtuaWin, basically not a lot can go wrong in the core of VirtuaWin because of this.

With the desktop limit now set to 20 is this a practical limit? We do not think so, there is another limit, the maximum number of managed windows is currently set to 160, again is this a practical limit? Can a person use as many as 160 windows at once? And if not is having 8 windows per desktop unreasonable? We do not think so.

Upgrade to Xemacs 21.4.13 or later which contains a patch for this.

This happens with most Delphi applications. As a workaround you can add the classname of the application to the ‘tricky.cfg’ file in your VirtuaWin install directory and make sure that you have enabled ‘Use alternate hiding’ in the expert options.

It’s very likely that you are starting VirtuaWin twice since a second start will display the setup. Make sure that you don’t start VirtuaWin for both default user and your current user.

VirtuaWin uses the hide technique when ‘removing windows’ from the current desktop. When an IE window is hidden (this also affects file explorers and opened folders) and a new IE window is opened, the hidden one is closed down. VirtuaWin 2.6 and up uses an alternative hiding technique which instead moves windows. This technique is used for Internet Explorer as well as other applications that exhibit this behaviour, so this should not be a problem anymore.

I don’t have as much time as I would like to work on VirtuaWin, so I would like some help from you others out there. From version 2.0, VirtuaWin is distributed under the GNU General Public License which is not exactly the same thing as giving away the code.

Nope, that was one of the things I wanted to get rid of. That’s why I began developing VirtuaWin in the first place. But since people started to ask for it (God knows why), I added module support so you should be able to fix such things yourselves. Isn’t that grand? 🙂Update: There’s now a pager module (called vwPager) available on the modules page.

Chances are that a couple of config changes to your system could greatly improve the performance of VirtuaWin desktop changing (note: the figures given are based on performance measuring on an XP SP2 machine with about 25 application windows; they are meant as a guideline only):VirtuaWin Setup -> Expert -> On desktop change preserve setting
Setting this to ‘Taskbar order‘ can reduce the time taken by around 10% compared to using ‘Taskbar & Z order‘.System Properties -> Performance Options -> Slide taskbar buttons
When this option is enabled, the taskbar buttons of new or closing windows are visually slid off. Typically when VirtuaWin changes desktop, all current buttons must be slid off and a new set slid on. This has around a 25% performance hit! It is strongly recommended that this option is disabled. To access this option right click on ‘My Computer’ and select Properties. In the ‘System Properties’ dialog that opens, go to the ‘Advanced’ tab. In the Performance group select ‘Settings’. In the Performance Options dialog go to the ‘Visual Effects’ tab; this setting is in the list of effects.System Properties -> Performance Options -> Use visual styles on windows and buttons
This option enables the Windows XP theme. The overhead of drawing all the fancy window borders is around 25%. See ‘Slide taskbar buttons’ option above for information on getting to this option.Taskbar and Start Menu Properties -> Group similar taskbar buttons.
When this option is enabled the taskbar starts to group several related window taskbar buttons into a single button which creates a drop-down menu. Enabling this option does not seem to directly effect the VirtuaWin desktop change performance, however if it is used the taskbar can take a very long time to catch up if you change desktops a lot (like I do to measure performance). Given the purpose of VirtuaWin is to provide multiple desktops to reduce the clutter, why would you need to use this option? You can access the Taskbar and Start Menu Properties dialog from the main Start -> Settings menu.
So if your computer is currently configured to use the XP theme with sliding taskbar buttons and for VirtuaWin to preserve Taskbar & Z order, VirtuaWin is probably taking more than 50% longer to change desktops than it needs to.

The short answer is you can’t. A deliberate design decision has been made to not introduce system hooks that can affect the reliability and responsiveness of both VirtuaWin and your computer. So VirtuaWin has no built in mouse wheel support.

However, VirtuaWin does have an easy to use windows message interface which can be used by external programs (such as VirtuaWin modules) through which support for the mouse wheel can be created (see the SDK package for a full list of messages supported by VirtuaWin).

There are probably lots of third party ‘hotkey’ programs that could be used to provide support. The following is a script for AutoHotkey (http://www.autohotkey.com) which will change desktops when the wheel is used on the desktop and change a window’s desk when used on its title bar:

---- vw_wheel_mouse.ahk ----

CoordMode, Mouse, Screen
DetectHiddenWindows, On
WinGet, dtHwnd, ID, Program Manager ahk_class Progman

WheelUp::
MouseGetPos, mx, my, id, control
if (id == dtHwnd)
	PostMessage, 1034, 1026, 0, , VirtuaWinMainClass
else if (control <> "")
	Send, {WheelUp}
else
{
	lPrm := (my << 16) | (mx & 65535)
	SendMessage, 132, 0, %lPrm%, , ahk_id %id%
	if (ErrorLevel = 2)
		PostMessage, 1049, %id%, -1026, , VirtuaWinMainClass
	else
		Send, {WheelUp}
}
return

WheelDown::
MouseGetPos, mx, my, id, control
if (id == dtHwnd)
	PostMessage, 1034, 1025, 0, , VirtuaWinMainClass
else if (control <> "")
	Send, {WheelDown}
else
{
	lPrm := (my << 16) | (mx & 65535)
	SendMessage, 132, 0, %lPrm%, , ahk_id %id%
	if (ErrorLevel = 2)
		PostMessage, 1049, %id%, -1025, , VirtuaWinMainClass
	else
	Send, {WheelDown}
}
return

---

This script sends the message 1034,1026,0 to VirtuaWin (a window with the class name VirtuaWinMainClass) to change to the next desktop, 1034,1025,0 to change to the previous desktop. It sends the message 1049,,-1026 to move the window the id to the next desktop and follow (note, if 0 is given then the current window is moved) and 1049,,-1025 to move the window to the previous desktop.

These key combinations must be manually set using the following process. Click here to view the complete answer (it’s a tad long).

A portable installation is one which correctly runs from a directory without having been installed, this is useful when you do not have admin privileges on the machine you wish to run VirtuaWin on.A portable installation can be created from any installation of VirtuaWin version 3.0 or later by doing the following:

1. Copy all the contents of the VirtuaWin installation to a new empty directory, for example ‘c:\portable_virtuawin\’.
2. Use a text editor, e.g. notepad, to edit the userpath.cfg within this new directory, i.e. ‘c:\portable_virtuawin\userpath.cfg’. This file is unlikely to exist at first so use the editor to create it. The file should have only the following text in it, this should be at the very top of the file:

${VIRTUAWIN_PATH}\config

1. Save the file and quit the editor.
2. Check the modules that are within the modules directory, it is likely that modules that do not require v3.0 or a later version of VirtuaWin will not be portable so they should be removed. The WinList and VWassigner modules that came with your installation will work.
3. Test the installation by exiting VirtuaWin if it is already running and then run the VirtuaWin.exe within the new directory, i.e. ‘c:\portable_virtuawin\VirtuaWin.exe’. If the installation is successful VirtuaWin should open the ‘Welcome to VirtuaWin’ dialog and create a new ‘config’ directory within the directory (i.e. c:\portable_virtuawin\config).
4. Configure VirtuaWin as normal and then exit VirtuaWin.

The directory now contains a fully configured and portable installation, simply copy this folder onto any required machine (or memory stick) and run as normal.

Note: The userpath.cfg configuration file can be used to create user specific and/or computer specific configurations, i.e. every computer you use could still have its own configuration by changing the file to:

${VIRTUAWIN_PATH}\config\${COMPUTERNAME}

See the Configuration Files help page for more information.