PureBasic Forums - English

Posted: **Thu Mar 16, 2017 3:54 pm**

@Thunder93
well yea, but non-pb apps can trigger this too.

it can also happen if you have an event loop, but block your app from processing it for too long.

click the button and switch to another app. after a while the window will move a bit, to notify the user that the app is not responding. also the close button appears as hovered and when you click it, you can choose to force quit the app:

Code: Select all

OpenWindow(0, 100, 100, 200, 100, "Test", #PB_Window_SystemMenu)
ButtonGadget(0, 5, 5, 100, 25, "Click")

Repeat
  Select WaitWindowEvent()
    Case #PB_Event_Gadget
      If EventGadget() = 0
        Delay(10000)
      EndIf
    Case #PB_Event_CloseWindow
      Break
  EndSelect
ForEver

c ya,
nco2k

Posted: **Thu Mar 16, 2017 4:32 pm**

The misaligned window is not the original window, it's the ghost window!
You can disable this behavior with DisableProcessWindowsGhosting_() (for the whole process) or by setting the #GWL_EXSTYLE to include #WS_EX_MDICHILD (for the specified window). But both ways disable the ability for the user to close/minimize a hung window and you won't see the "busy" mouse cursor...

cheers, chi

Posted: **Thu Mar 16, 2017 4:38 pm**

nco2k wrote:it can also happen if you have an event loop, but block your app from processing it for too long.

Because it just results in the same thing ? Not processing events ? Is that a surprise ?

nco2k wrote: after a while the window will move a bit, to notify the user that the app is not responding

Where did you read the OS does that when a program is not processing the event queue ?

Posted: **Thu Mar 16, 2017 4:53 pm**

chi wrote:The misaligned window is not the original window, it's the ghost window!

Yes, but that not explain why the window is shown in another position, the reason for that is another one.

People experiencing this should try to link with /subsystem:windows,6.0 and see if the windows still move.

If they don't, then it's the usual offset problem due to the appcompatibility flag used by the os since pb don't set 6.0 for the subsystem.

Posted: **Thu Mar 16, 2017 5:55 pm**

DontTalkToMe wrote:Because it just results in the same thing ? Not processing events ? Is that a surprise ?

what are you trying to tell me here? i was just responding to Thunder93's statement that he never noticed this behavior, because he always uses an event loop. so no idea why you are even quoting this.

DontTalkToMe wrote:Where did you read the OS does that when a program is not processing the event queue ?

i didnt, it was just an observation. every app that wasnt specifically targeting vista/7 was behaving this way, which is totally normal behavior.

DontTalkToMe wrote:Yes, but that not explain why the window is shown in another position, the reason for that is another one

well, they choose to implement it like that. not the first weird decission of microsoft, wont be the last one either.

DontTalkToMe wrote:People experiencing this should try to link with /subsystem:windows,6.0 and see if the windows still move.

correct, when you specifically target vista/7, then the ghosting window should stay at the same position. no idea how win8/10 behaves, since i dont use either one of those two.

either way, this is not a pb bug. this is normal windows behavior. pb doesnt know wether you want to target win xp, 7, 8 or 10. imho its not a big deal, setting the subsystem on our own. but of course it would be more comfortable, if we could choose the target platform from a dropdown menu.

c ya,
nco2k

Posted: **Thu Mar 16, 2017 5:57 pm**

Yes, but that not explain why the window is shown in another position

That is because with Aero enabled the windows X and Y isn't 100, 100 as requested, it's 95, 95 (only visually). For some reasons (MS bug maybe) the ghost window doesn't behave like the real window and shows at 100, 100. That's why it's "moving". If you use SetWindowTheme_(WindowID(0), #Null$, "") to disable the theme, the window doesn't move (but the ghost window is still themed).

Btw: If you add #PB_Window_SizeGadget to the window flags it works like expected...

Better visible if you start the window with X, Y at 0, 0

Code: Select all

OpenWindow(0, 0, 0, 200, 100, "Test", #PB_Window_SystemMenu) ;|#PB_Window_SizeGadget
;SetWindowTheme_(WindowID(0), #Null, "")
ButtonGadget(0, 5, 5, 100, 25, "Click")

Repeat
  Select WaitWindowEvent()
    Case #PB_Event_Gadget
      If EventGadget() = 0
        Delay(10000)
      EndIf
    Case #PB_Event_CloseWindow
      Break
  EndSelect
ForEver

Posted: **Thu Mar 16, 2017 6:02 pm**

After close inspection, It isn't actually jumping to the right side. It just shrinks, or the window is cropped down, or theme needs to be re-applied.

Anyways, as already been said countless times. This isn't PureBasic bug.

Posted: **Thu Mar 16, 2017 10:40 pm**

MrMat wrote:it is just the lack of event loop... Adding that in is fine.

The code I posted was just a quick example before bed. Even with an event loop, the window still moves around by itself:

Code: Select all

OpenWindow(1,10,10,50,50,"")
OpenWindow(2,100,10,50,50,"")
OpenWindow(3,200,10,50,50,"")

Sleep_(2000) ; Click Calculator during this time!

GetForegroundWindow_()

Repeat : Until WaitWindowEvent()=#PB_Event_CloseWindow

So the consensus seems to be that we can't use any non-event delays in our apps, lest our windows start moving by themselves.

That's something I never knew before.

Posted: **Thu Mar 16, 2017 10:52 pm**

Dude wrote:So the consensus seems to be that we can't use any non-event delays in our apps, lest our windows start moving by themselves. That's something I never knew before.

consensus, not mine.

The example code provided last, I can't replicate the behaviour with either PB 5.60 Stable, PB 5.44 Stable under Windows 10 x64.

Posted: **Thu Mar 16, 2017 10:59 pm**

It should take 5 seconds before it happens:
https://blogs.technet.microsoft.com/ask ... r-windows/

I can't reproduce it either, unless I stick the delay up to just over 5000.

Posted: **Thu Mar 16, 2017 11:03 pm**

@Dude
it depends on your HungAppTimeout value, which should be 5000ms by default. if the app hangs for that long, the ghosting window will appear. i really dont know what you are trying to do here, but a window should be responsive and things that need a long time to process, should be put in a separate thread. i mean, you could put a window and its loop in one thread and download+write a file in the very same thread, by processing it in small chunks, but that really is not good practice.. at all. so maybe you could elaborate what your actual problem is.

https://msdn.microsoft.com/en-us/librar ... s.85).aspx

c ya,
nco2k

Posted: **Thu Mar 16, 2017 11:24 pm**

Whether it's event delay or not, how currently the delay is used affects the operation of the window to be-able to respond in a timely fashion to window messages.

Not sure what the goal is suppose to be.... but here's the better approach;

Code: Select all

#GetForegroundWindow = 1

OpenWindow(1,10,10,50,50,"")
OpenWindow(2,100,10,50,50,"")
OpenWindow(3,200,10,50,50,"")

AddWindowTimer(1, #GetForegroundWindow, 2000)

Repeat
  Event = WaitWindowEvent()
  If Event = #PB_Event_Timer And EventTimer() = #GetForegroundWindow
    Debug "Timer Triggered"
    Debug "Window #: "+EventWindow()
    
    GetForegroundWindow_()
    
    RemoveWindowTimer(EventWindow(), #GetForegroundWindow)        
  EndIf  
  
Until Event = #PB_Event_CloseWindow

Posted: **Fri Mar 17, 2017 8:04 am**

Thanks for all replies... I'll approach my app differently to prevent Windows moving it.

Posted: **Fri Mar 17, 2017 5:58 pm**

Windows not moving it, it's shrinked or chopped down. When the window hangs the titlebar dimensions changes along with the window dimensions.

Run the following and bring this red background colored window quickly to the foreground after launching the other code.

Code: Select all

OpenWindow(0, 100, 100, 200, 100, "Test", #PB_Window_BorderLess|#PB_Window_TitleBar)
SetWindowColor(0, RGB(255, 0, 35))
Repeat : Until WaitWindowEvent()=#PB_Event_CloseWindow

Code: Select all

OpenWindow(0, 100, 100, 200, 100, "Test", #PB_Window_BorderLess|#PB_Window_TitleBar)
StickyWindow(0, 1)
Delay(99999)
Repeat : Until WaitWindowEvent()=#PB_Event_CloseWindow

PureBasic Forums - English

[Done] Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself

Re: Window moves by itself