Welcome Guest.   Make a donation to an author on the site October 01, 2014, 07:30:34 PM  *

Please login or register.
Or did you miss your validation email?


Login with username and password (forgot your password?)
Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.


You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.
 
Check out and download the GOE 2007 Freeware Challenge productivity tools.
   
   Forum Home   Thread Marks Chat! Downloads Search Login Register  
Pages: [1]   Go Down
  Reply  |  New Topic  |  Print  
Author Topic: Preventing fullscreen and getting back when that's failed  (Read 2649 times)
oblivion
Supporting Member
**
Posts: 354


see users location on a map View Profile Read user's biography. Give some DonationCredits to this forum member
« on: July 27, 2011, 12:00:18 PM »

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
Logged

-- bests, Tim

...this space unintentionally left blank.
steeladept
Supporting Member
**
Posts: 1,056



Fettucini alfredo is macaroni & cheese for adults

see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #1 on: July 27, 2011, 12:04:26 PM »

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?
Logged
skwire
Moderator
*****
Posts: 4,086



Another Coding Snack request? Om nom nom...

see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #2 on: July 27, 2011, 12:15:43 PM »

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

Formatted for Autohotkey with the GeSHI Syntax Highlighter [copy or print]
  1. !Enter::Return
Logged

f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #3 on: July 27, 2011, 02:19:17 PM »

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

- carpe noctem
oblivion
Supporting Member
**
Posts: 354


see users location on a map View Profile Read user's biography. Give some DonationCredits to this forum member
« Reply #4 on: July 27, 2011, 04:02:38 PM »

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

Formatted for Autohotkey with the GeSHI Syntax Highlighter [copy or print]
  1. !Enter::Return

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
Logged

-- bests, Tim

...this space unintentionally left blank.
oblivion
Supporting Member
**
Posts: 354


see users location on a map View Profile Read user's biography. Give some DonationCredits to this forum member
« Reply #5 on: July 27, 2011, 04:08:42 PM »

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?

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
Logged

-- bests, Tim

...this space unintentionally left blank.
MilesAhead
Member
**
Posts: 4,868



View Profile WWW Give some DonationCredits to this forum member
« Reply #6 on: July 27, 2011, 04:42:23 PM »

From AHK Forum search:
http://www.autohotkey.com...t=detect+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.

[copy or print]
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.

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

 
« Last Edit: July 27, 2011, 05:13:30 PM by MilesAhead » Logged

"Genius is not knowing you can't do it that way."
- MilesAhead
oblivion
Supporting Member
**
Posts: 354


see users location on a map View Profile Read user's biography. Give some DonationCredits to this forum member
« Reply #7 on: July 28, 2011, 09:58:59 AM »

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.

Thanks, but...

 Sad 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

[copy or print]
#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.  Sad

-- bests, Tim
Logged

-- bests, Tim

...this space unintentionally left blank.
MilesAhead
Member
**
Posts: 4,868



View Profile WWW Give some DonationCredits to this forum member
« Reply #8 on: July 28, 2011, 12:14:34 PM »

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. smiley
Logged

"Genius is not knowing you can't do it that way."
- MilesAhead
MilesAhead
Member
**
Posts: 4,868



View Profile WWW Give some DonationCredits to this forum member
« Reply #9 on: July 28, 2011, 01:03:43 PM »

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.
Logged

"Genius is not knowing you can't do it that way."
- MilesAhead
oblivion
Supporting Member
**
Posts: 354


see users location on a map View Profile Read user's biography. Give some DonationCredits to this forum member
« Reply #10 on: July 30, 2011, 04:25:33 PM »

Get the simplest case working first before adapting it.

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...

[copy or print]
#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.  cheesy Although I grant it's a lot less elegant than I'd like.

--tim
Logged

-- bests, Tim

...this space unintentionally left blank.
MilesAhead
Member
**
Posts: 4,868



View Profile WWW Give some DonationCredits to this forum member
« Reply #11 on: July 30, 2011, 05:28:03 PM »

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.
Logged

"Genius is not knowing you can't do it that way."
- MilesAhead
Pages: [1]   Go Up
  Reply  |  New Topic  |  Print  
 
Jump to:  
   Forum Home   Thread Marks Chat! Downloads Search Login Register  

DonationCoder.com | About Us
DonationCoder.com Forum | Powered by SMF
[ Page time: 0.062s | Server load: 0.31 ]