Skip to main content


Showing posts from March, 2007


Can't software developers respect the window ordering of users? The AttachThreadInput()/SetForegroundWindow() hack completely hoses the window order so badly any more that when you go to switch to another application, 40 others change position and come to the foreground as well - and sometimes the window focus doesn't change as expected. My message to all software developers: This hack is clearly labeled as such and you should NEVER use it more than very rarely. Seriously, watch the window stack order get hosed as you make those calls. People clearly don't understand what AttachThreadInput() does...nor HOW to actually call and use the function...they just copy the code and assume it works to steal the foreground window without any respect to how Windows operates. There is a proper way to use AttachThreadInput(), but most people don't realize how to use it. This message brought to you out of sheer frustration with application switching.

You know you are... esoteric areas of an application/operating system/etc. when you go to use an API that has no documentation on it. Cutting-edge stuff that is bound to change and keep life interesting. Not that I really care in this particular case, but I needed some information from a DLL. In this case, the API was documented but whoever wrote it did a bad job. Read: Incorrectly documented and I had to hash my way through multiple debugging sessions to figure it out. Ironically, Google searches for sample source code turned up only VB examples. No C/C++ examples. My C++ version is about 1/10 the length of the VB versions. Oh, and I wrote a program today that helps me write quickie little throwaway projects. Visual Studio along with the other IDEs I use takes forever to set up for cheesy projects. So now I've got a nifty little utility that I can just copy and paste some files, run the utility, and I have a new console project set up. Cuts out about 15 minutes of work (I like to dr