New Multi-Monitor UDF and Applications (moved)

[Mbee 13]

Hello, all!

Today I'm posting several files: The first is a UDF to provide information regarding all the connected monitors that are part of the system's "Virtual Screen" (See: The Virtual Screen) It returns two tables, one of which is a one-dimensional table that reports general information about the monitor setup in the running system, and the other is an n-dimensional table that reports information about each individual monitor.

Both tables contain user-available elements that the developer using this UDF may find useful, such as an optional handle to a GUI she/he may construct and associate with a specific monitor. These are identified as such in the UDF documentation.

The other files are applications and support files -- primarily AutoWinSwitch -- that as a user with multiple monitors, I've found to be extremely valuable, and I suspect others will as well. It uses the above UDF, so I thought it made sense to post them together.

I will quote from the documentation for AutoWinSwitch:

    On systems with multiple monitors, there may be times in which one of the monitors is temporarily
    dedicated to some purpose other than as a computer display. For example, if one uses an HDTV as a
    computer display, there will be times when you simply want to watch TV on it. But if some popup or
    normal window comes up on that monitor -- for example, to issue a notification or to run an app --
    you wouldn't want to be forced to switch the display from TV mode to computer display mode to
    deal with it.

    So this utility can be run in the background to watch for such cases and then automatically relocate
    the window to a free, aka "open", monitor.

    NOTE that this tool obviously cannot distinguish which CURRENTLY open windows on the blocked display
    the user wants switched at launch, so the assumption is made that ONLY windows which come up AFTER
    launch will be switched over.

    The user can change which monitor is "blocked" and which is "open" with this application's GUI.
    
    The desired operation mode is stored in the registry, including the choice to stop auto-switching
    windows. This state is thus preserved across reboots by default. Also included are two pre-built
    32-bit support applications. "AutoWinSwitchChooseState" is a small GUI that allows the user to
    place AutoWinSwitch into the desired mode of operation: Disabled; Switch to Primary Monitor; and
    Switch to Secondary Monitor. This is how one chooses the Blocked and Open monitors.
    
    The other small application, "AutoWinSwitchStateReset", always sets the mode to Disabled without
    launching a GUI. I've found it useful to set this to run automatically as a startup application
    in those instances when I do not want the operational mode to be retained across reboots.

    Currently, both the UDF and the application only supports systems with two active monitors. If it
    becomes desirable to support more than that, please contact me and I will provide such capabilities.
 

Here's why I find these applications so valuable: One of my computer monitors is my HDTV. I prefer using
it as my main computer monitor because, as an older man, it makes reading code and other text on the
screen much easier. However, sometimes I want to watch TV -and- so some light work on the computer.
Before this app, it drove me completely crazy with frustration when a notification window or other window
would come up on the HDTV monitor! I'd have to pause what I was watching, switch the HDTV input to the
computer, deal with the new window, and then change everything back. I was forced to do this perhaps
50 or more times a day!

So now I simply set the HDTV as the "blocked" monitor, and whenever a NEW window pops up on the HDTV,
this application automatically moves it to the "open" monitor and thus prevents many a screaming fit.

Note the references to "NEW" windows. You see, the reason its taken me so long to develop the apps is
because I spent literally months trying to design an algorithm to analyze a window on a given monitor
to see if it's one that I have to operate on and move to a different monitor. But after all those months,
I learned on a coding forum that such an algorithm is simply impossible under Windows! So more time
passed before I realized that there was an utterly trivial solution: Don't try to figure out if a new window
is of a particular type or purpose, but instead just move ALL windows that show up but weren't there
a moment ago. Just keep in mind that any window that was already on the "blocked" monitor will stay
there even while AutoWinSwitch is running. Also, if a window is moved to a different monitor that you
didn't want moved, just drag it back and the application won't keep trying to move it again.

Finally, I've attached the UDF, the applications, and a separate UDF created by @Bilgus which would
be needed if one wants to recompile the UDF or applications. If any of you wise folks have valuable
input on my code or what have you, please bring it to my attention however you wish, including
PM if you like.

Note that I have not followed the recommended AutoIt coding and variable naming styles. I have
no criticism of them; it's simply that I've found over the course of almost four decades of professional
software development that including the variable's scope in its name has saved my bacon many,
many times, so I've employed that technique in my own code by including the scope as the first one
or more letters of the variable name. But since in the standard coding style the first letters specify
the variable's type, I've moved that information to the end. So a global variable starts with $G_, a
global constant starts with $Gc_, and so forth. If the variable is an array, the last letters will be
"Ara", if a string, "Str", and reals/floats with have "Flt". If the variable lacks any of these, then it
stores an integer by default. Someday when I have the time, I will go back and ensure my code
consistently uses that style, but there may be instances where I failed to do so.

 

MBee -- 01-Dec-2020

 

 

AutoWinSwitch Release 1.00.zip

Edited December 2, 2020 by Mbee
Upload problem

[JockoDundee 237]

Hi Mbee!

Just looking at the code on my phone, I saw this intriguing statement:

$Lf_Minimized = ($Lf_Minimized <> 0) ? True : False

Without a PC handy to test, I’m wondering what the effect/purpose of the statement might be.

Are you attempting to cast from Integer to Boolean?

 

[JockoDundee 237]

btw, if you are trying to cast a number to a boolean, (which, imo, is rarely needed), here's a couple of other ways to do it:

First, you can do what you did but you can omit what's after the ? since True=True and False=False:

$Lf_Minimized = ($Lf_Minimized <> 0)

or even just

$Lf_Minimized = $Lf_Minimized <> 0

and, if you are a contrarian by nature, this might appeal to you:

$Lf_Minimized = Not Not $Lf_Minimized

[Mbee 13]

Hello again, my friends and all you wise and generous teachers! 😌 

I'll try not to bore you with my horrible Covid-19 sob story, and how that caused me to be away for so long. Unless you will forgive me for at least a a brief attempt to try to rehabilitate my now-miserable reputation as a coder here. I mean, I previously posted words to the effect that I'd never post garbage -- followed immediately by posting garbage (in my OP here). How utterly humiliating! You see, the COVID-19 post-recovery "Brain Fog" is as terrible as has been reported, and once the fog lifted a bit, I found a ludicrous number of design flaws and massively stupid bugs in what I posted above!

Anyway, I've got most of it working correctly now, except I'm apparently not smart enough to learn how to do something new to me, which I will ask about elsewhere.

Once I've reached the point where I think my code will be ready for proper beta testing, I'll update the code.

Sorry for my mistakes and for your patience!

Edited February 4 by Mbee
typo

[argumentum 664]

On 2/4/2021 at 12:03 PM, Mbee said:

I'm apparently not smart enough

look, you can replace: 

$Lf_WinState = WinGetState( $Lf_WinHdl )
    $Lf_Minimized = BitAND( $Lf_WinState, $WIN_STATE_MINIMIZED )
    $Lf_Minimized = ($Lf_Minimized <> 0) ? True : False
    If $Lf_Minimized Then
        Return 0
    EndIf

with: 

If BitAND(WinGetState($Lf_WinHdl), $WIN_STATE_MINIMIZED) = $WIN_STATE_MINIMIZED Then Return 0

so, am I smarter than you ?  

Look, experience takes time. Don't beat yourself up. None of us is like, "OMG you're the best there is ever being".
You are sharing a project and it's always welcomed. And welcomed should be corrections. I'm a better coder thanks to that. Tho, I do disregard emotional content, as it, is open to interpretation and sense of humor or lack of it, from either me or the one correcting me.

In any case, correct all that needs correcting and, thanks for sharing   

[Mbee 13]

Thanks a huge bunch-o-beers, @argumentum !  Perhaps I should have been more effusive in what I wrote in the "Thanks" portion of the UDF header I posted above, because I really *do* feel so utterly positive and grateful to you and all my teachers here. I also should have added that this community is universally replete with some of the friendliest and most welcoming people I have ever encountered in my real-life and virtual travels.

Thank you once more for your kind and gracious words, pal argumentum!