looks like at a minimum, WM_DESTROY should be handled: close_myapp() PostQuitMessage() Exit()

i had it turned off, and the process would not terminate from the taskbar when its window was destroyed.

Turning it on and just calling PostQuitMessage() only unhooks the winproc, its doesnt exit.

close_myapp() is the "right" way to do it, but may be overkill, as you're terminating anyway, and windows ought to release all resources associated with the process. but its still probably safer to not rely on windows to do your cleaning up for you. in my book (my way of doing things) i'd probably have to call "not calling close_myapp()" a bad practice.

other than WM_DESTROY, i only trap mouse movement, buttons, and wheel. default winproc does all the rest. i wonder what happens when the PC goes to sleep when the game is running? never tried it. it handles lost device now, so it ought to come right back up when you wake up the PC, assuming it (windows) does a full save and restore of state on sleeping.

Does anyone know which messages are sent when switch display shortcuts are used: shift + win + left/right arrow keys?

none specific to that action that i can tell. and i just dug through them all the other day. if you're talking about windows itself, they may trap the individual WM_key messages or check the keys asynchronously if you're talking about 3rd party software it may be an application defined message.

i would think that it would send some type of message about change of window size or something. you're talking about switching between 2 monitors on a multi-monitor system, right?

Yep, for some reason my win app (CreateWindow, etc...) doesn't switch to other monitor.

2 head system, right? 2 graphics cards, 2 monitors, or 2 cards in 1 with 2 monitors.

i would think that each head would be a separate d3d device, and that you'd shut down one and startup the other on head switch.