Thursday, March 29, 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.

Saturday, March 03, 2007

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 drag in my primary coding library into even cheesy apps., which takes a while to set up properly).

That would be an interesting feature for various IDEs: Template projects. It takes an existing solution that you know works and then lets you edit the files to turn them into generic templates. What I call 'at directives' could be used (similar to MyProBB's template) to manage template substitution options. Then, when you want to create a new quick application, you can select the template and it creates everything needed for the new application...including properly named files. Files I want to rename upon running my utility, I named 'main.*' and I renamed them using the current directory. Everyone writes cheesy apps. Not very often and usually for testing purposes and usually console-based, but I don't see why such a feature couldn't be used for GUI apps. too. Visual Studio has wizards and they have their place but it forces Microsoft's style onto your style. Cleaning up their coding style issues to better match mine is a pain. My utility is pretty lame compared to this idea.