Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#125 Extend CLI to return responses for external script use


From a script (in my case, ooRexx programs), I can issue commands to VirtuaWin easily enough... but the ones that ask VW a question don't seem to produce an answer. I would like to be able to issue any of the query commands and get a response writtem to stdout, so it could be trapped or redirected and used by the script. So eg:

C:\>VirtuaWin.exe -msg 1053 -9999
"C:\My Dropbox\Programs--ALL-\Piculell VirtuaWin V4-3-0\config-IPCLP"


C:\>VirtuaWin.exe -msg 1053 -9999 > %TEMP%\VWcommandresults.txt

As it stands I see that the -msg command (for obvious reasons in a message processing environment) tells VW which window to send the reply back to. Possibly there's a dummy window handle value (eg my "-9999" above that could be used in these situations, for obviously I would not want VW actually to send a reply to any active window! Though... I suppose that one can't place a negative number in a command line as the minus sign looks like the dash before a switch? Unless: VirtuaWin.exe -msg 1053 "-9999" works?

Hmmm. This would be better handled explicitly eg:

VirtuaWin.exe -sysoutmsg 1053

in which case I'd hope that VW would not check for the reply-window's handle parameter being present, AND would write the result to sysout.

Is there any possibility that this or something like it could be implemented?

I would also quite like to see a -msg that requests VW to reply with the names of all the desktops (though if I can get the reply about the
userconfig location I guess I can read the config file for myself even though that's going to be slower); it might also be useful to have an option to dump lots of other parameters and/or the stuff that the 'Log Windows' button writes to an active log file, to sysout.


    • assigned_to: nobody --> bjasspa
  • VW returns the answer via its exit value, e.g. try the following batch script:

    VirtuaWin.exe -msg 1045 0 0
    echo %ERRORLEVEL%
    VirtuaWin.exe -msg 1046 0 0
    echo %ERRORLEVEL%
    VirtuaWin.exe -msg 1048 0 0
    echo %ERRORLEVEL%

    This will print the desktop dimensions and the current desktop. The only thing it can't do is print the values returned via COPYDATA, i.e. messages 1052, 1053 & 1067, but these are really targeted at VW modules which will need a window anyway.

    VirtuaWin is a windows app and as such it does not have a console so physically cannot print to stdout ('feature' of windows) so this is not as trivial as it may seem. It would be possible to write a simple console app which creates a window and sends the required VW command, printing the return values to stdout, but given the majority of module return values can be obtained via the exit value I'm not sure if you really do require this.

    Please let us know.

  • Sorry for the delay in replying... I've tried what you suggested, though with a different syntax, in ooREXX and I am getting return-code values, so that's certainly better than nothing. You say that only messages 1052, 1053 & 1067 will be a problem for me, but I would have thought there's more than that - eg 1064

    I understand what you're saying about stdout not being available.

    I guess I can work around not being able to ask VirtuaWin where it's installed, and where the config data is, by hard-coding that information in any scripts I write - though it's clearly not ideal.

    But I don't see any way that I can discover the window handles and which desktops particular windows are on, programmatically. I guess if I have the app configured to log events, and I can find the virtuawin.log file, I can read it. ... Yes, it will open for a shared read, ok. But this file grows and grows, recording events. I really need a list of window handles and window titles...

    How about: VirtuaWin.exe -msg nnn mmm

    which uses a new message code nnn which requires a parameter mmm. The action would be to dump a full list of windows - I suppose I'd want at least the window handle, desktop number, window co-ordinates, window size, and window title for each window.

    The list could be written to a file named, say, WindowDump<mmm>.log in the Config folder, or maybe in %TEMP% would be better.. If such a file already existed it would be overwritten. It would be up to me to choose the mmm value when I made the call if i wanted to have a series of dumpfiles at various points I could vary the value otherwise I could use the same value in each call. (I guess it would be better to vary it, to be sure the newly requested file had been created rather than me reading an old one.) VirtuaWin would not hold the file open (unlike the virtuawin.log file) so I could delete it after I had read it. Might that be possible?

  • 1064 returns a single integer value just like 1045 so this should work for you. The program you are using should have an EnumWindows type function which loops through ALL current windows and for each window you either trivially reject it (based on some criteria of yours) or call this module interface, the number returned can then be interpreted using the macros in Messages.h.

    E.g. I executed 'VirtuaWin.exe -msg 1064 xxx 0' where xxx is the handle number of a window and VW returned 33555307 or 0x0200036b in hex, which means the window is being manage (not 0) and is on desktop 2 with an info flag of 0x036b.

    The old VW_WINLIST message to pass back all window information as a big lump of data was impossible to maintain, any slight change to the data structures would break all the modules, whereas this method is relatively stable and used by many modules including WinList.

  • No response for 6+ months, can only assume the existing Module interface was sufficient so closing the issue.

    • status: open --> closed
    • Group: --> Next Release (example)