Wow, this was a treat to track down! So there have been reports on Windows of the IDE not showing up properly in the taskbar, which was just plain craziness. That's automatic functionality from the OS and programmers almost never have to deal with it. So I just assumed people had some sort of hack installed (like Window Blinds) that caused a bug. But then I started noticing it myself on my dev machine. Weird! But totally inexplicable, so I let it tickle the back of my brain for a while. Today, I decided, was the day to tackle this bug.
It turns out that the bug is actually with WM_SETREDRAW, which I have discussed before. The bug is an undocumented behavior with regards to the API (so I use the term "bug" loosely here) when used during window creation, before the window is shown. It turns out that if you call WM_SETREDRAW before the window is initially displayed, then the taskbar will not take note of its creation until after the user clicks on the window (to activate it). What's more fun, is there are no Win32 APIs which can counteract this!
You can try this out for yourself. In your window's Open event, put the following code:
Declare Sub SendMessageA Lib "User32" ( hwnd as Integer, msg as Integer, wParam as Integer, lParam as Integer )
Const WM_SETREDRAW = &h000B
SendMessageA( self.Handle, WM_SETREDRAW, 0, 0 )
SendMessageA( self.Handle, WM_SETREDRAW, 1, 0 )
self.Refresh( true )
If you run it, you'll notice that the window does not get an entry in the taskbar (though it does in the Alt+Tab window). However, if you add a self.Show before calling SendMessage, then everything works as expected. This sort of makes sense, given that the message is a way for you to turn off all redraw functionality for a given window. However, it's also something that is very hard to track down if you run into it!
The reason the IDE was having a problem with this is that we use the redraw functionality when creating new editor tabs -- it reduces the overall amount of flicker. However, when the IDE is first launched, one of the things the Open event does is create some editors and tabs (like the project item editor). The fix was to show the window before calling the Win32 API, which isn't ideal, but also isn't harmful (since the window's not going to be redrawn until we're ready anyhow).
So if you use WM_SETREDRAW in your own code (which you might, if you use FreezeUpdate in the WFS), be careful not to use it before the window has been shown as you may be in for a bit of strange functionality.
Thanks for sharing this Aaron.
Having this information on the net really helps.
Hello Aaron,
Interesting...is this the same issue of the disappearing icon in the taskbar notification area?
@Thomas Herold -- it's highly unlikely. This bug only affects the IDE (the RB framework doesn't use it), so there should be no affect.
I'd wondered what the cause of that silliness was. Most of the time my IDE taskbar entry is grouped with Explorer windows. Frustrating when you're half asleep and trying to fix a bug. :)
I recently installed and bought the Windows version of REALbasic, and the first thing I did was minimized the project window so I could go check something in Firefox. Unfortunately, I then realized that there was no button in the taskbar for REALbasic and I couldn't figure out how to get the IDE back! I ended up having to force quit RB and relaunch it.
Thank god you figured out what was going wrong there... I was beginning to wonder how you guys managed to make an app that couldn't even follow built-in and automatic behaviors! :-p
Jeez, and all this time I thought my computer was screwed up again!