I’ve released updates of DateTimeControls, ProgressBar, TabStrip and TrackBar. Nothing spectacular, mainly bugfixes. I could also lower the usage of GDI objects and make the binaries a bit smaller.
ProgressBar and TrackBar support Windows 7 now, too. Both controls also got 1-2 new features. Actually, version numbers 2.2.0 and 1.3.0 would have fit better, but this awareness comes a bit too late…
TabStrip also has got a new feature. Using the OLEDragImageStyle property, you can choose between Aero style OLE drag-images and classic OLE drag-images. If the system supports only classic ones, then of course those will be used even if the control is configured to produce Aero drag images. And of course all this applies only if you let the control create the drag-image instead of doing it yourself.
Comments
5 responses to “DateTimeControls 1.0.1, ProgressBar 2.1.2, TabStrip 1.3.0, TrackBar 1.2.2”
Thanks a million for your initiative to create these useful controls.
I am only missing one control to feel that I can be continuing to use VB 5/6 at all levels of legacy code support and that would be the label control which has the nice feature of having background transparency and click event sensitivity.
I wish there was a simple tutorial somewhere on how to write your own unicode aware controls as well but that still seems to be one area which is greatly lacking information on the web.
Thank you again.
Well, I’ve a Unicode aware Label control that’s practically complete, but has some serious drawing bugs that I cannot fix. If you like to, I can give you the sourcecode so that you can try to fix the problems yourself. The control is written in Visual C++ 2008 using ATL and WTL.
Most problems I have with writing the controls are related to COM and not to the fact that the controls use the Unicode charset instead of ASCII. If you want to know anything, just ask me (but the forum would be a better place). I’m willing to share my knowledge, because I know how difficult it is to find out how to correctly write ActiveX controls that are a bit more complex than the ones you create in the usual tutorials.
A million thanks TiKu. Had I not gone through my server logs today I would not have seen this reply from you. You can reach me through the website linked to the name displayed above the reply here.
I would be very interested in seeing the source to see how you did these things.
I will of course share again if I manage to find a fix for the drawing bug described.
Mike
I believe the solution to our previous discussion is simplest resolved by a few relatively simple additions to the “textbox” / edit control.
Adding the necessary properties for;
1) AutoSize (the control scales inherently by the length of the string displayed when set to True)
2) Transparent Background (allows the control to appear floating over backgrounds)
Even if it was only the addition of transparency in the control it would be great and I could work out the resize by the TextWidth property. (though with Unicode you might get an odd count)
All other properties and events in the Edit Control are already there to allow it to function as a title caption replacement once you get used to not type Caption but Text as the default property.
Then you wouldn’t have to mess with the rebuilding source in the other control, nor add more controls than necessary to the menu of a project.
Just an idea, I have not had time to weed through the source yet on the one you sent me but I do believe this could be a faster approach to a solution.
This approach has a major disadvantage: a textbox is a window and therefore consumes a lot more resources than a windowless label would consume. It doesn’t matter if you have only a few controls in your app. But the more controls you have, the more noticeable this disadvantage becomes.