I spent the last two days working on nothing but framework bugs, paying special attention to Windows issues (especially issues coming from some of our 10,000 new VB users we got this week). Here's a sneak peek at what you'll see in the next beta:
- "Properly" drawn EditFields with the Windows XP theme (more on this later)
- Proper handling of the Enter key with regards to push buttons on Windows. Basically, the "default" button is whatever button currently has the focus. If no button has the focus then the PushButton you've set as default becomes the default button.
- ListBox bug fixes: on Windows, it now draws disabled properly, on the Mac the CheckBox rows now draw with a disabled check box. Selected rows no longer disappear when the ListBox is disabled
- On Windows, now properly handling password EditFields on Windows. Before, you could drag text into the password field and the text would stay plain text (and no, you could not drag it back out if it was truly password chars).
- Can now use the Uppercase and Lowercase mask properly on Windows
- Windows EditFields now get the F keys in the KeyDown event
- Floating windows no longer get hidden behind the MDI frame if their parent was a Plain box
- and a handful of other things that I just can't remember off the top of my head
Basically, it was a very productive two days in terms of getting bugs fixed. Granted, I still have to pour more time into the IDE side of things next week (fixing more registration issues, finalizing the menus and toolbars, etc). So that sucks. I much prefer fixing framework issues since those bugs carry over into the applications people write -- but then again, bugs are bugs and they all need to be fixed.
So more on that "properly drawn editfield" bug. It really isn't a bug -- Microsoft has not made a single version of RichEdit theme-savvy. So any RichEdit control gets drawn with the "old" look instead of the themed look. You can see this in VB applications as well as other applications (check out WordPad for example). Since we always use RichEdit controls (because they're much more powerful, and much more annoying to work with internally), we were always getting non-themed EditFields. What made the bug look worse is that we were *drawing* the themed EditField in the window editor. Oops!
Well, using the crappy simple EditField wasn't an option (too many things would break), so I got creative. I subclassed the RichEdit control and handled the painting of it myself. We already know how to properly draw an EditField (as shown in the window editor), so I simply handled figuring out the metric and draw the control's borders myself (assuming it has borders, of course). To save myself some headaches, I decided that the control would be hand-drawn if it was a non-styled, single line edit field. It should be possible to draw a multiline editfield as well, but then I'd have to handle figuring out when the scrollbars are shown, and that's a lot of pain I don't really feel like dealing with. The good news is -- simple, single line editfields now look "proper" on themed XP. Thank you Microsoft. :: grumbles :: Aren't you glad we take care of these sort of things for you?
What?! No comment from the color nazi?! I purposely go out of my way to make it as bright as possible. However, this time it is color coordinated. Right down to the font :) You couldn't comment because it's perfect ;) Hee hee....
I remember something else I fixed -- serial controls on Windows now can use ports > COM9, and SerialPortCount returns the proper count when you have ports over COM9 as well. Heh, there were a handful of other little goofy fixes like that as well.