AlwaysOnTop, why hast thou forsaken me? Topic is solved

Report problems with documented functionality
User avatar
svArtist
Posts: 62
Joined: 08 Mar 2015, 18:16

AlwaysOnTop, why hast thou forsaken me?

01 Feb 2017, 11:10

This is weird...
Yesterday I expanded my standard script to enable me to take screenshots, crop and drag them around on screen.
They're borderless, without caption and AlwaysOnTop.
Everything worked fine.

Until today, when I wrote in a save file dialog on ctrl+s.
Since the GUI kept getting in my way, I turned AlwaysOnTop off before showing the dialog. So far so good.

But now I can't seem to turn it back on.

Code: Select all

{
	winget, twin, ID
	winset, AlwaysOnTop, off, ahk_id %twin%

	sleep, 100
	winset, AlwaysOnTop, on, ahk_id %twin%
	msg("set")
}
I've double checked and triple checked, as well as copy/pasted.
I don't know what's causing this.
I'm now using the same identifier for both calls (off and on), to eliminate any funny business there.
I've removed the whole dialog business for testing purposes, and I've added a sleep for good measure.
Yet the GUI won't turn back to AlwaysOnTop again.


Any ideas why I'm having this trouble?
Here is a video:

At first, everything is fine. Then (when I click on it) I hit ctrl+s and boom goes the AOT property.
The code is running, see the little message "Set" pop up in the top left corner as the last call of the subroutine.
:morebeard:
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: AlwaysOnTop, why hast thou forsaken me?

01 Feb 2017, 11:21

post a complete, trimmed down snippet of failing code. i want to copy, paste, run, and see the problem

very often in that process you will discover your error yourself

User avatar
svArtist
Posts: 62
Joined: 08 Mar 2015, 18:16

Re: AlwaysOnTop, why hast thou forsaken me?

01 Feb 2017, 11:53

guest3456 wrote:post a complete, trimmed down snippet of failing code. i want to copy, paste, run, and see the problem

very often in that process you will discover your error yourself
Of course!
Pardon me...
Here it is as code:
Spoiler
and attached as an .ahk file, too, for convenience.

ALT+A to create one of those floating windows
DEL on one of those windows removes it
CTRL+S on one of those windows ... well, illustrates the problem.


All the things important to the project are pretty much still in there.
Sadly, I did not stumble across what ever spanner I seem to have written into my works during the process :/
Attachments
tmp.ahk
(1.55 KiB) Downloaded 308 times
:morebeard:
4GForce
Posts: 553
Joined: 25 Jan 2017, 03:18
Contact:

Re: AlwaysOnTop, why hast thou forsaken me?

01 Feb 2017, 23:09

Weird, I couln't get it to work either but I got alternatives for you

Code: Select all


WinHide ahk_id %twin%
   ; ...
WinShow ahk_id %twin%

or if you can get the gui name/id this also works ...

Code: Select all


Gui, ClipWin0:-AlwaysOnTop
    ; ...
Gui, ClipWin0:+AlwaysOnTop

just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: AlwaysOnTop, why hast thou forsaken me?  Topic is solved

02 Feb 2017, 03:40

You might try the following (I didn't test it):

Code: Select all

#ifWinActive, ClipWin ahk_class AutoHotkeyGUI ; added the class criterium
del::
winclose
return

^s::
GUIID := WinExist() ; the 'last found' window has been set by #IfWinActive
Gui, %GUIID%:+OwnDialogs ; the FileSelectFile dialog will be owned by the GUI window and shown on top of it
FileSelectFile, curCropLoc,S,% DateString(true) . ".bmp",Save Image, Bitmaps (*.bmp)  ;  <-- references not included, but the SaveFileDialog wasn't the issue after all anyway...
; if(curCropLoc)
; {
	; wingettitle, mtit
	; mid := substr(mtit,8)
	; floc := clipCrop%mid%.img
	; logg(curCropLoc . " - " . floc)
	; filecopy, %floc%, %curCropLoc%
; }
msgbox, set
return
#ifWinActive
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: AlwaysOnTop, why hast thou forsaken me?

02 Feb 2017, 04:04

still, i wonder why the WinSet isn't working properly..

just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: AlwaysOnTop, why hast thou forsaken me?

02 Feb 2017, 04:43

Found something in the AHK source I don't understand.

Code: Select all

#NoEnv
Gui, +hwndHGUI +Lastfound +AlwaysOnTop -SysMenu -Caption +OwnDialogs
Gui, Show, w400 h400, Test
Winget, ExStyles, ExStyle, ahk_id %HGUI%
MsgBox, 0, Original ExStyles, %ExStyles%              ; <<< 0x00000008
WinSet, AlwaysOnTop, Off, ahk_id %HGUI%
Winget, ExStyles, ExStyle, ahk_id %HGUI%
MsgBox, 0, ExStyles after AlwaysOnTop Off, %ExStyles% ; <<< 0x00000000
ExitApp
Script2.cpp -> ResultType Line::WinSet()

Code: Select all

	case WINSET_ALWAYSONTOP:
	{
		if (   !(exstyle = GetWindowLong(target_window, GWL_EXSTYLE))   )
			return OK;
		HWND topmost_or_not;
		switch(ConvertOnOffToggle(aValue))
		{
		case TOGGLED_ON: topmost_or_not = HWND_TOPMOST; break;
		case TOGGLED_OFF: topmost_or_not = HWND_NOTOPMOST; break;
		case NEUTRAL: // parameter was blank, so it defaults to TOGGLE.
		case TOGGLE: topmost_or_not = (exstyle & WS_EX_TOPMOST) ? HWND_NOTOPMOST : HWND_TOPMOST; break;
		default: return OK;
		}
		// SetWindowLong() didn't seem to work, at least not on some windows.  But this does.
		// As of v1.0.25.14, SWP_NOACTIVATE is also specified, though its absence does not actually
		// seem to activate the window, at least on XP (perhaps due to anti-focus-stealing measure
		// in Win98/2000 and beyond).  Or perhaps its something to do with the presence of
		// topmost_or_not (HWND_TOPMOST/HWND_NOTOPMOST), which might always avoid activating the
		// window.
		SetWindowPos(target_window, topmost_or_not, 0, 0, 0, 0, SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE);
		break;
	}
Will this do anything if exstyle is 0?
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: AlwaysOnTop, why hast thou forsaken me?

02 Feb 2017, 05:14

if exstyle 0 then that first if statement should return, no?

maybe move to bug reports?

User avatar
svArtist
Posts: 62
Joined: 08 Mar 2015, 18:16

Re: AlwaysOnTop, why hast thou forsaken me?

02 Feb 2017, 07:11

4GForce wrote:Weird, I couln't get it to work either but I got alternatives for you

Code: Select all


WinHide ahk_id %twin%
   ; ...
WinShow ahk_id %twin%

or if you can get the gui name/id this also works ...

Code: Select all


Gui, ClipWin0:-AlwaysOnTop
    ; ...
Gui, ClipWin0:+AlwaysOnTop

Indeed, talking to the GUI inheritance does work, still!
Of course I could've hidden and shown, but that's a less pleasing UX :)

just me wrote:You might try the following (I didn't test it):

Code: Select all

#ifWinActive, ClipWin ahk_class AutoHotkeyGUI ; added the class criterium
del::
winclose
return

^s::
GUIID := WinExist() ; the 'last found' window has been set by #IfWinActive
Gui, %GUIID%:+OwnDialogs ; the FileSelectFile dialog will be owned by the GUI window and shown on top of it
FileSelectFile, curCropLoc,S,% DateString(true) . ".bmp",Save Image, Bitmaps (*.bmp)  ;  <-- references not included, but the SaveFileDialog wasn't the issue after all anyway...
; if(curCropLoc)
; {
	; wingettitle, mtit
	; mid := substr(mtit,8)
	; floc := clipCrop%mid%.img
	; logg(curCropLoc . " - " . floc)
	; filecopy, %floc%, %curCropLoc%
; }
msgbox, set
return
#ifWinActive
:D Thanks so much for showing me that I can compare for AHK classes at the same time as Titles! I felt so dirty doing it the wrong way before!
And +OwnDialogs is definitely the right move here!


Well, of course the small problem I had is solved (or rather circumvented)
...But now there's still the question of why.

just me, guest3456: If it helps, I'm running 1.1.23.01
:morebeard:
4GForce
Posts: 553
Joined: 25 Jan 2017, 03:18
Contact:

Re: AlwaysOnTop, why hast thou forsaken me?

02 Feb 2017, 14:43

The 0 in those msgbox line is the option for an OK button message box, not the exstyle
just me wrote:Found something in the AHK source I don't understand.

Code: Select all

#NoEnv
Gui, +hwndHGUI +Lastfound +AlwaysOnTop -SysMenu -Caption +OwnDialogs
Gui, Show, w400 h400, Test
Winget, ExStyles, ExStyle, ahk_id %HGUI%
MsgBox, 0, Original ExStyles, %ExStyles%              ; <<< 0x00000008
WinSet, AlwaysOnTop, Off, ahk_id %HGUI%
Winget, ExStyles, ExStyle, ahk_id %HGUI%
MsgBox, 0, ExStyles after AlwaysOnTop Off, %ExStyles% ; <<< 0x00000000
ExitApp
Script2.cpp -> ResultType Line::WinSet()
Now here its checking if the 'exstyle' you are trying to set is the same as the current exstyle of that window ... ( if so, no changes are made and it returns OK )
just me wrote:

Code: Select all

	case WINSET_ALWAYSONTOP:
	{
		if (   !(exstyle = GetWindowLong(target_window, GWL_EXSTYLE))   )
			return OK;
		HWND topmost_or_not;
		switch(ConvertOnOffToggle(aValue))
		{
		case TOGGLED_ON: topmost_or_not = HWND_TOPMOST; break;
		case TOGGLED_OFF: topmost_or_not = HWND_NOTOPMOST; break;
		case NEUTRAL: // parameter was blank, so it defaults to TOGGLE.
		case TOGGLE: topmost_or_not = (exstyle & WS_EX_TOPMOST) ? HWND_NOTOPMOST : HWND_TOPMOST; break;
		default: return OK;
		}
		// SetWindowLong() didn't seem to work, at least not on some windows.  But this does.
		// As of v1.0.25.14, SWP_NOACTIVATE is also specified, though its absence does not actually
		// seem to activate the window, at least on XP (perhaps due to anti-focus-stealing measure
		// in Win98/2000 and beyond).  Or perhaps its something to do with the presence of
		// topmost_or_not (HWND_TOPMOST/HWND_NOTOPMOST), which might always avoid activating the
		// window.
		SetWindowPos(target_window, topmost_or_not, 0, 0, 0, 0, SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE);
		break;
	}
Will this do anything if exstyle is 0?
I don't see any problem there, I'll try on a non ahk window later when I got some time
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: AlwaysOnTop, why hast thou forsaken me?

02 Feb 2017, 20:32

4GForce wrote:The 0 in those msgbox line is the option for an OK button message box, not the exstyle
you've misread.

we're not talking about the first parameter 0, we're talking about just me's comment in the script about the msgbox output

did you even run the code?

4GForce wrote: Now here its checking if the 'exstyle' you are trying to set is the same as the current exstyle of that window ... ( if so, no changes are made and it returns OK )
maybe i'm misunderstanding c++, but i read the code as an assignment, not a comparison

4GForce
Posts: 553
Joined: 25 Jan 2017, 03:18
Contact:

Re: AlwaysOnTop, why hast thou forsaken me?

02 Feb 2017, 21:46

Well, I'm sorry, I really read that too fast.
Still I don't think the problem is ahk related, this is some kind of operating system protection.
In addition, this command may have no effect due to the operating system's protection against applications that try to steal focus from the user (it may depend on factors such as what type of window is currently active and what the user is currently doing).
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: AlwaysOnTop, why hast thou forsaken me?

02 Feb 2017, 23:06

and now you've read too fast AGAIN. you're quoting the docs for the Top subcommand, not AlwaysOnTop. and you left out the VERY NEXT SENTENCE which instructs the user to USE AlwaysOnTop

whats going on tonight?

i think it certainly is an AHK bug because it only happens when Gui, -Caption. if that option is left turned on, or another ExStyle is used in conjunction such as -Caption +ToolWindow, then the ExStyle of the GUI never becomes 0 when WinSet, AoT, off , and then obviously it can be turned back on

Code: Select all

#NoEnv
Gui, +hwndHGUI +Lastfound +AlwaysOnTop -SysMenu +OwnDialogs ;-Caption   ;<<<<<<<
Gui, Show, w400 h400, Test
Winget, ExStyles, ExStyle, ahk_id %HGUI%
MsgBox, 0, Original ExStyles, %ExStyles%

WinSet, AlwaysOnTop, Off, ahk_id %HGUI%
Winget, ExStyles, ExStyle, ahk_id %HGUI%
MsgBox, 0, ExStyles after AlwaysOnTop Off, %ExStyles%

WinSet, AlwaysOnTop, On, ahk_id %HGUI%
msgbox, always on top is back on
ExitApp
Last edited by guest3456 on 02 Feb 2017, 23:23, edited 6 times in total.

guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: AlwaysOnTop, why hast thou forsaken me?

02 Feb 2017, 23:18

just me wrote:Found something in the AHK source I don't understand.

Code: Select all

#NoEnv
Gui, +hwndHGUI +Lastfound +AlwaysOnTop -SysMenu -Caption +OwnDialogs
Gui, Show, w400 h400, Test
Winget, ExStyles, ExStyle, ahk_id %HGUI%
MsgBox, 0, Original ExStyles, %ExStyles%              ; <<< 0x00000008
WinSet, AlwaysOnTop, Off, ahk_id %HGUI%
Winget, ExStyles, ExStyle, ahk_id %HGUI%
MsgBox, 0, ExStyles after AlwaysOnTop Off, %ExStyles% ; <<< 0x00000000
ExitApp
Script2.cpp -> ResultType Line::WinSet()

Code: Select all

	case WINSET_ALWAYSONTOP:
	{
		if (   !(exstyle = GetWindowLong(target_window, GWL_EXSTYLE))   )
			return OK;
		HWND topmost_or_not;
		switch(ConvertOnOffToggle(aValue))
		{
		case TOGGLED_ON: topmost_or_not = HWND_TOPMOST; break;
		case TOGGLED_OFF: topmost_or_not = HWND_NOTOPMOST; break;
		case NEUTRAL: // parameter was blank, so it defaults to TOGGLE.
		case TOGGLE: topmost_or_not = (exstyle & WS_EX_TOPMOST) ? HWND_NOTOPMOST : HWND_TOPMOST; break;
		default: return OK;
		}
		// SetWindowLong() didn't seem to work, at least not on some windows.  But this does.
		// As of v1.0.25.14, SWP_NOACTIVATE is also specified, though its absence does not actually
		// seem to activate the window, at least on XP (perhaps due to anti-focus-stealing measure
		// in Win98/2000 and beyond).  Or perhaps its something to do with the presence of
		// topmost_or_not (HWND_TOPMOST/HWND_NOTOPMOST), which might always avoid activating the
		// window.
		SetWindowPos(target_window, topmost_or_not, 0, 0, 0, 0, SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE);
		break;
	}
Will this do anything if exstyle is 0?
move this thread to Bug Reports

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: AlwaysOnTop, why hast thou forsaken me?

03 Feb 2017, 03:42

guest3456 wrote:i think it certainly is an AHK bug because it only happens when Gui, -Caption. if that option is left turned on, or another ExStyle is used in conjunction such as -Caption +ToolWindow, then the ExStyle of the GUI never becomes 0 when WinSet, AoT, off , and then obviously it can be turned back on
Thanks for the analysis. I agree.
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: AlwaysOnTop, why hast thou forsaken me?

03 Feb 2017, 03:45

GetWindowLong wrote: If the function fails, the return value is zero.
Source
Seems like a bad choise by microsoft.
just me
Posts: 9424
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: AlwaysOnTop, why hast thou forsaken me?

03 Feb 2017, 04:27

Code: Select all

	case WINSET_TRANSPARENT:
	case WINSET_TRANSCOLOR:
	{
		// IMPORTANT (when considering future enhancements to these commands): Unlike
		// SetLayeredWindowAttributes(), which works on Windows 2000, GetLayeredWindowAttributes()
		// is supported only on XP or later.

		// It appears that turning on WS_EX_LAYERED in an attempt to retrieve the window's
		// former transparency setting does not work.  The OS probably does not store the
		// former transparency level (i.e. it forgets it the moment the WS_EX_LAYERED exstyle
		// is turned off).  This is true even if the following are done after the SetWindowLong():
		//MySetLayeredWindowAttributes(target_window, 0, 0, 0)
		// or:
		//if (MyGetLayeredWindowAttributes(target_window, &color, &alpha, &flags))
		//	MySetLayeredWindowAttributes(target_window, color, alpha, flags);
		// The above is why there is currently no "on" or "toggle" sub-command, just "Off".

		// Since the color of an HBRUSH can't be easily determined (since it can be a pattern and
		// since there seem to be no easy API calls to discover the colors of pixels in an HBRUSH),
		// the following is not yet implemented: Use window's own class background color (via
		// GetClassLong) if aValue is entirely blank.
		if (  !(exstyle = GetWindowLong(target_window, GWL_EXSTYLE))  )
			return OK;  // Do nothing on OSes that don't support it.
... might have to be checked also.
lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: AlwaysOnTop, why hast thou forsaken me?

03 Feb 2017, 05:17

They're both fixed in v1.1.24.05.
User avatar
svArtist
Posts: 62
Joined: 08 Mar 2015, 18:16

Re: AlwaysOnTop, why hast thou forsaken me?

03 Feb 2017, 05:37

lexikos wrote:They're both fixed in v1.1.24.05.
Damn, that was fast!
Really good to see how active and effective AHK dev is! :)
:morebeard:
guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: AlwaysOnTop, why hast thou forsaken me?

03 Feb 2017, 09:05

svArtist wrote:
lexikos wrote:They're both fixed in v1.1.24.05.
Damn, that was fast!
Really good to see how active and effective AHK dev is! :)
+1
:clap:


Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 47 guests