Preventing fullscreen and getting back when that's failed

[oblivion]

I have a problem.

I've built an autohotkey script that, amongst other things, prevents Alt-Enter from doing anything. That was on purpose...

Thing is, under certain circumstances, a DOS app can force Windows to push it to fullscreen. If that happens, there's no way back...

Is there a way I can detect if that's happened and temporarily re-enable Alt-Enter?

-- tim

[steeladept]

I am not sure if this is a solution or not, but can't you just Alt-Tab to minimize the window and work as normal?

[skwire]

How are you blocking Alt-Enter within your script?  Are you doing it like this?:

Code: Autohotkey [Select]

1. !Enter::Return

[f0dder]

Move to a 64-bit OS, then you've moved beyond all that trouble

[oblivion]

How are you blocking Alt-Enter within your script?  Are you doing it like this?:

Code: Autohotkey [Select]

1. !Enter::Return

-skwire (July 27, 2011, 12:15 PM)

Yes. I wondered if I could make something that would check to see if something was fullscreen before allowing the command to be processed.

Effectively, what I think I want to achieve is a situation where Alt-Enter works in one direction only -- back from fullscreen to windowed.

-- bests, Tim

[oblivion]

I am not sure if this is a solution or not, but can't you just Alt-Tab to minimize the window and work as normal?

-steeladept (July 27, 2011, 12:04 PM)

It gets you back to the desktop, but it doesn't re-window the fullscreen app. Not quite what I want to achieve.

There's a side-query to this: is there a better way to resize the display font in said DOS window than use a set of mouse- and keyboard macros to do "right-click on title bar, select Properties, select Font tab"... and so on? It works (and reasonably well) but feels inelegant...

-- bests, Tim

[MilesAhead]

From AHK Forum search:
http://www.autohotke...ect+full+screen+mode

animeaime's post in the thread

Ok. This should. I remember how NiftyWindows would always suspend on a full screen program. So, this should do the job. Use WinExist (or some other means) to get the Unique ID (HWND) of the desired window.

[Select]

isWindowFullScreen(WinID)
{
    ;checks if the specified window is full screen
    ;code from NiftyWindows source
    ;(with only slight modification)

    ;use WinExist of another means to get the Unique ID (HWND) of the desired window

    if ( !WinID )
        return

    WinGet, WinMinMax, MinMax, ahk_id %WinID%
    WinGetPos, WinX, WinY, WinW, WinH, ahk_id %WinID%

    if (WinMinMax = 0) && (WinX = 0) && (WinY = 0) && (WinW = A_ScreenWidth) && (WinH = A_ScreenHeight)
    {
        WinGetClass, WinClass, ahk_id %WinID%
        WinGet, WinProcessName, ProcessName, ahk_id %WinID%
        SplitPath, WinProcessName, , , WinProcessExt

        if (WinClass != "Progman") && (WinProcessExt != "scr")
        {
            ;program is full-screen
            return true
        }
    }
}

edit: I haven't tried it but according to the help you can get the handle of the active window like this:  WinExist("A")

so isWindowFullScreen(WinExist("A")) should return true if the active "window" is in full screen mode.  At least for single monitor systems anyway.

If it returns true just Send the !{Enter}.  If not just eat the key combo.

[Select]

!Enter::
  If isWindowFullScreen(WinExist("A"))
    Send, !{Enter}
  else
    ; send something else or just eat the keys
return

 

[oblivion]

edit: I haven't tried it but according to the help you can get the handle of the active window like this:  WinExist("A")

so isWindowFullScreen(WinExist("A")) should return true if the active "window" is in full screen mode.  At least for single monitor systems anyway.

If it returns true just Send the !{Enter}.  If not just eat the key combo.

-MilesAhead (July 27, 2011, 04:42 PM)

Thanks, but...

  I can't make this work.

The dos app is running in a window with title "Joe System."

I'm using the code pretty much as you've given it, except that I'm using it after a

[Select]

#IfWinActive, Joe System

directive.

It certainly blocks !{enter} as it should, but it continues to block it when the program's full screen.

I've tried to find variants on the WinExist("A") function to return the correct process in case the NTVDM doesn't react the way a fullscreen Windows program would -- which is what I suspect the issue is -- but I've had no success at all.

So still the only thing I can do is deactivate the script (I've set ^!x::ExitApp up at the top) and then use !{Enter}.

Can I check my understanding of this is right? The isWindowFullScreen function goes at the bottom of the script, after a return that ensures the code is only executed when called, WinID is the variable into which the value returned by WinExist("A") is stuffed, and the true returned by the function is the boolean state not a variable I need to initialise elsewhere?

If I have that right and I'm not missing something else I should be doing, then a fullscreen 16-bit DOS app can't be detected in the same way as a fullscreen Windows prog. 

-- bests, Tim

[MilesAhead]

I would try commenting out the IfWinActive.  The hotkey should be global.

You are right about the function.  I'm on Win7 and if I do Alt Enter in a command prompt it tells me it's not supported. So I can't test the script.

Commenting out IfWinActive would be the first thing to try.
Also posting on AHK forum would get programmers with a lot more AHK experience than I have. I mainly use it if I need mouse hotkey support. I'm still a novice afa AHK goes.

[MilesAhead]

Generally speaking it's a good practice to create a test stub.  Or in this case it may be suitable for a separate app.  Just create a script with

isWindowFullScreen(WinID)

function at the bottom and the
!Enter::

hotkey at the top,
until you get the feel of it, rather than sticking it into another script.
Get the simplest case working first before adapting it.

[oblivion]

Get the simplest case working first before adapting it.

-MilesAhead (July 28, 2011, 01:03 PM)

I did that; still failed. I asked over at the AHK forum; lots of people read my post, but nobody answered.

Eventually, I came to the comclusion that the reason it didn't work was because a fullscreen DOS app doesn't have the same attributes that are being tested for to detect a fullscreen Windows app, and racked my brains for a while to see if I could come up with an alternative approach.

I discovered that (under XP, anyway) Alt-Enter with the desktop as the foreground app brings up display properties. That led me to a plan...

[Select]

#IfWinActive, MyCode
; MyCode should be replaced with the appropriate window title -- can be set in a batchfile with Title "<whatever>"
; semi-disable Alt+Enter
!Enter::
SetMouseDelay, 70
click 2000,2000 ; click somewhere far, far away from any open windows
; Alt-enter on desktop brings up XP display properties, in a fullscreen DOS app it pushes it back to a window
send !{Enter}
click 275,430 ; the Cancel button on the XP Display Properties dialog, regardless of tab
WinActivate, MyCode
return

So I don't actually test for the state, I do something that affects both states differently and deal with the outcome -- I click cancel, or I click in the window with the DOS app in it, which just selects it or some text in it depending on whether quickedit mode is on or not. Either way, I have a solution.

I felt quite clever.  Although I grant it's a lot less elegant than I'd like.

--tim

[MilesAhead]

Sometimes it's just easier to send some keys or clicks. AutoIt3/AHK is handy then.

I've been waiting years for FreeCommander file manager to add a /Layout=n command line switch so I could open it to a combination of tabbed folders.

In the meantime I use an AutoIt3 app that launches it, waits for it to be active, then Sends Alt-1 to open the top Layout. Kludge but it works.