c++ - Fullscreen mode on monitor A in dual-monitor setup breaks when moving windows from monitor B onto it -


i building win7/8/10 x64 direct3d11 desktop application allows user switch between windowed , fullscreen mode (proper dedicated fullscreen mode, not maximized window*). on dual-monitor setup encountering issues.

the switch performed manually using idxgiswapchain::setfullscreenstate , works intended: monitor houses lion's share of window area (let's call monitor a) goes dedicated fullscreen mode while leaving other (monitor b) was, allowing user interact windows on b fullscreen application on a.

however, if window on b dragged or resized crosses on a, application's fullscreen state gets disturbed: reverts windowed mode (leaving application's internal tracking variable out of sync), stays in quasi fullscreen mode seemingly refuses further mode switches, , on. same thing happens if window overlapped both , b before application went fullscreen mode gets focus.

is there way prevent this?

i wish os honor application's dedicated fullscreen mode , keep in robust state if other windows dragged onto monitor. i'd want behavior similar having "always-on-top, maximized borderless window" in stead, i.e. have other windows "disappear behind it" , not affect state of fullscreen window @ all.

i have tried workarounds, responding wm_killfocus , temporarily switching application "maximixed borderless window" until receives wm_setfocus again, wm_killfocus message has lag during there time user drag window area still in fullscreen mode, thereby setting me square one.


*the reason want feature rather using maximized borderless window (which supported mode, btw) has allowing lower mouse-movement-to-rendering latency, vsync control (on/off) etc.. of - in short - important nature of application (which not game).

although not ideal (ideal there way have os handle properly), have found reasonable workaround suppose can live now. variation of concept mentioned in question ("..like responding wm_killfocus , temporarily switching application maximixed borderless window.."), without crippling delay problem:

whenever application enters dedicated fullscreen mode, captures mouse call setcapture. not affect user's ability interact other windows on monitor b, will ensure such de/activating interaction - mouse click in application - send wm_lbuttondown application before loses focus. importantly, happens immediately, unlike wm_killfocus message has significant latency.

when such wm_lbuttondown message received (while in fullscreen), application checks whether click happened outside screen area. if so, means lose focus , expose complications brought in original question. temporarily exits dedicated fullscreen mode , "replaces" (visually identical) borderless maximized window. when application regains focus, goes dedicated fullscreen.

this works ok, since don't care application's responsiveness when you're not interacting anyway. biggest inconvenience here mode switch flickering occurs on these focus transfers, given alternatives, find acceptable price pay want accomplish (but means - i'd very interested in better solution).


edit 1: worth noting since there other ways application lose focus through mouse clicks, wm_killfocus also handled.


edit 2: realized handling wm_buttondown message redundant. setcapture alone ensure wm_killfocus message received enough.


Comments

Popular posts from this blog

dns - How To Use Custom Nameserver On Free Cloudflare? -

python - Pygame screen.blit not working -

c# - Web API response xml language -