[Done] Window moves by itself

[Thunder93]

LOL

[nco2k]

@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

[chi]

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

[DontTalkToMe]

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 ?

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 ?

[DontTalkToMe]

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.

[nco2k]

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.

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.

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.

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

[chi]

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

[Thunder93]

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.

[Dude]

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.

[Thunder93]

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.

[MrMat]

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.

[nco2k]

@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

[Thunder93]

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

[Dude]

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

[Thunder93]

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