9 replies to this topic

[Raik]

#NoTrayIcon
GUICreate('', 200, 19,@DesktopWidth-255,0,$WS_POPUP,BitOr($WS_EX_TOPMOST,$WS_EX_CONTROLPARENT,$WS_EX_TOOLWINDOW)) 

after longer time this window "disappears" (lost his "ontop"-state) and is hidden behind the other windows.
i dont know how to recognize this and i have no idea what to check.

any ideas, why it looses "ontop"-state and how to fix this?

[Aipion]

Since you are not showing how to get this bug going again i would suggest you to use the WinSetOnTop ( "title", "text", flag ) function.

[JTravolta]

you are right will follow you@ )

[JTravolta]

yes that's very interesting..

[Raik]

Since you are not showing how to get this bug going again i would suggest you to use the WinSetOnTop ( "title", "text", flag ) function.

exactly thats the problem. after start the window remains ontop for hours and i cant stare the whole time on it, while doing other things on the computer. until now i have not managed, to catch the moment and even if i could, that would not help to see the reason. i switch between all the windows, but it does not occur on a specific window at the first moment. maybe after many switches of a specific window, but i have not managed to catch the moment.

Does WinSetOnTop work different to $WS_EX_TOPMOST ? Does'nt set the same Bit?

Edited by Raik, 16 February 2012 - 04:28 AM.

[Aipion]

exactly thats the problem. after start the window remains ontop for hours and i cant stare the whole time on it, while doing other things on the computer. until now i have not managed, to catch the moment and even if i could, that would not help to see the reason. i switch between all the windows, but it does not occur on a specific window at the first moment. maybe after many switches of a specific window, but i have not managed to catch the moment.

I agree with your statement "i cant stare the whole time on it".

Does WinSetOnTop work different to $WS_EX_TOPMOST ? Does'nt set the same Bit?

They do pretty much the same thing which is just to set the window to stay on top.
Did it work for you?
If you did not try it out yet, please try it then feedback.

[Raik]

to know if it works first i have to catch the moment, when it "dissapears". WinGetState() will always tell "Window is visible".

[Aipion]

Here use this function to find out if the window is OnTop.

;===============================================================================
;
; Function Name:   _WinIsOnTop
; Description::    Gets the OnTop State of a window
; Parameter(s):    $WindowHandle : Handle or Title of Window
; Requirement(s):  WinAPI.au3
; Return Value(s): Window OnTop: True, otherwise False
; Author(s):       Prog@ndy
;
;===============================================================================
;
Func _WinIsOnTop($WindowHandle)
    Local $long = DllCall("User32.dll", "int", "GetWindowLong", "hwnd", WinGetHandle($WindowHandle), "int", -20)
    Return BitAND($long[0],8)=8 ; $WS_EX_TOPMOST = 8
EndFunc

[Raik]

another idea: if i read pixelcolor at coordinates of the window, i can detect, if it is the windowcolor.
but may take a while to reproduce the event again, i call back then.

[Raik]

OK, found a solution for it, but not the cause of the behavior.

Opt("PixelCoordMode",0)
    If $COLOR<>'0x'&Hex(PixelGetColor(1,1,$GUI),6) Then
  Beep(500,50)
     WinSetOnTop($GUI,"",0) 
     WinSetOnTop($GUI,"",1)
    EndIf

($COLOR is the color of a progressbar at this position, witch changes frequently.)

because i have to disable "ontop" first, to reenable it, i think, the $WS_EX_TOPMOST style is not lost, but windows does not consider it by any case.
My fix works for me, but i have no idea, how to track down this bug(?).