CommonControls (Replacement of the MS common controls)

[Krool]

Im converting old TreeView source code to the new VBCCR TreeView but i struggle with the missing NEXT property of the tree node:

Attachment 176799

Normally the NEXT property is used to loop through the node childs:

Set xNode = Node.Child

For I = 1 To Node.Children

   xNode.Checked = True
   Set xNode = xNode.Next

Next I

Any ideas?

SOLTUION:

ok, i got it, the equivalent for the NEXT property is NextSibling...is there any reason to use another name for this property?

'Next' is a reserved keyword. So I can't use it.
So I used 'NextSibling'..

[KurtB]

Hi Krool!

My name is Kurt, and I just wanted to say a few things. I am programmer, and I'm still coding in VB6. I do not say this with shame as many others might. I know the limitations of the language and all of the "power I am missing" from not using a "modern" "non-toy" language, etc. etc. I am sure that everyone reading this forum calls "bulls___" on anyone making such claims

Yes, we suffer in ways, but we do so because we know just how close MS was to perfecting VB, all the way up to the point where they abandoned the language, and abandoned us, the coders. Krool: your work here is the continuance of the job that MS dropped: You are creating the true VB7 here, and I do not exaggerate! Thank you so much for your dedication!

I have 3 questions for you:

1. I have a very real and immediate need for a solution like yours for the intrinsic controls, the Treeview, and the Listview in Unicode-ready format. My 1st question is: Do you maintain a bug list that would help me decide on the readiness of these controls? I can't just drop them in to a 150,000+ line project, without doing tons of unit testing, unless a bug list helped me decide. I tend to maintain bug lists - I'm just wondering if you do the same, and, if so, could you please direct me to it?

2. Can I provide you any coding assistance, either directly in the main project, or in a unit mass-testing capacity?

3. Any other ways I could support? With your level of dedication, and the potential help that work could provide me, it seems like a monetary donation would be in order. Seriously. You're doing work that I have wanted to do, but haven't have the time for. And, I know how long you've been working on it. Finally, I've seen some of your code, and I can say with certainty that the length of time is not due to any lack of skill

Please send me a PM, if you have a minute or two, so we can discuss it. This is not a completely selfless thing either...as mentioned, I have a vested interest in helping you succeed!

Please stay safe, and have a nice day!
Kurt

[Semke]

in the toolbar control.
when adding buttons using property pages, if an image is added to a button, where the selected key does not exist in the associated imagelist, you get a runtime error..

PS. I hope that I am helping you by submitting these bugs, I have submitted a few, which I hope were helpful, my intention is not to criticize, I greatly appreciate your work.

[Krool]

1. I have a very real and immediate need for a solution like yours for the intrinsic controls, the Treeview, and the Listview in Unicode-ready format. My 1st question is: Do you maintain a bug list that would help me decide on the readiness of these controls? I can't just drop them in to a 150,000+ line project, without doing tons of unit testing, unless a bug list helped me decide. I tend to maintain bug lists - I'm just wondering if you do the same, and, if so, could you please direct me to it?

What you mean with bug list? I try always to fix the bugs asap so there is no long "bug list" waiting to be done. So I can't tell you right now which bugs are still existent.
The best is of course you try to replace your large project with the new controls and see what happens. Doing large project conversions helps best to improve it as every corner is used.

2. Can I provide you any coding assistance, either directly in the main project, or in a unit mass-testing capacity?

If you find something that can be improved or simplified you can advise. No problem.
Of course the biggest help so far was the crowd testing.

[LaVolpe]

What you mean with bug list?

He means 70 pages, 2700+ posts

But seriously, many of us will keep a list of why new versions/revisions were released. That list will say which 'bugs' were found/fixed and which enhancements were added, and which methods became obsolete/removed. Whether he is asking for a list of known bugs not yet fixed, not sure.

[Semke]

toolbar question:
does the toolbar have a DC? reason I am asking, because I would like to print text on the toolbar mainly on placeholders (without the need to add a picturebox on it)

I found a work around;
by creating a label control and/or other controls and in the form load event you set the toolbar as the control container of the Label.
you will also need to position the control and make it visible. you can use the button.top, button.left properties for that

Set txtBrandName.Container = tbrToolbar
Set lblBrandName.Container = tbrToolbar

[Krool]

I found a work around;
by creating a label control and/or other controls and in the form load event you set the toolbar as the control container of the Label.
you will also need to position the control and make it visible. you can use the button.top, button.left properties for that

Set txtBrandName.Container = tbrToolbar
Set lblBrandName.Container = tbrToolbar

Sorry for the delay and not responding.

Exactly, like the MS ToolBar the VBCCR ToolBar is a "ControlContainer". (But which can't get focus; CanGetFocus = False)
So, the best is, as you just did, to change the container of external controls to the toolbar.

[KurtB]

He means 70 pages, 2700+ posts

But seriously, many of us will keep a list of why new versions/revisions were released. That list will say which 'bugs' were found/fixed and which enhancements were added, and which methods became obsolete/removed. Whether he is asking for a list of known bugs not yet fixed, not sure.

Yeah, I guess that is what I meant

Basically, what I was asking for was your level of confidence that I could replace the shipped controls with your controls, in a big project, and have a reasonable expectation that my project would remain stable. If you told me that you were pretty confident, that would be enough for me to give it a try. I might even make a project-wide mass-replacement tool that would open .frm and .ctl files, and swap out the controls. (Maybe your users could get some use out of such a tool?). But, if you said that you knew of some pending bugs that might cause me some issues, now or down the road, I suppose I'd have to go through a big testing phase first. Sure, I should probably do that anyway, but, as most programmers are, I'm strapped for time.

Based on your response, I might just give it a try By the way, I can still contribute resources, if you're interested, now, or in the future. Send a PM.

Thanks again for your time, your response, and in general, what you do!

[KurtB]

This forum software is weird...first an error, then a double post...

[wqweto]

This forum software is weird...first an error, then a double post...

Has been like that for some years. On error don't hit back and re-post as your reply is probably posted already. Just open a new tab and reload the topic to see if your request was successful on first attempt.

I might even make a project-wide mass-replacement tool that would open .frm and .ctl files, and swap out the controls. (Maybe your users could get some use out of such a tool?).

I think there is already an existing tool for this posted in the code-bank sub-forum somewhere.

cheers,
</wqw>

[Krool]

Yeah, I guess that is what I meant

Basically, what I was asking for was your level of confidence that I could replace the shipped controls with your controls, in a big project, and have a reasonable expectation that my project would remain stable. If you told me that you were pretty confident, that would be enough for me to give it a try. I might even make a project-wide mass-replacement tool that would open .frm and .ctl files, and swap out the controls. (Maybe your users could get some use out of such a tool?). But, if you said that you knew of some pending bugs that might cause me some issues, now or down the road, I suppose I'd have to go through a big testing phase first. Sure, I should probably do that anyway, but, as most programmers are, I'm strapped for time.

Based on your response, I might just give it a try By the way, I can still contribute resources, if you're interested, now, or in the future. Send a PM.

Thanks again for your time, your response, and in general, what you do!

The VTable handling is definitely clean now (was a long road to get rid of VTable subclass and lightweight COM)
Also the latest cleansing of no need for WM_MOUSEACTIVATE handlers anymore gives me the conclusion that the state as of now is pretty confident.
So go for it, now or when new VBCCR17 will be released.

[KurtB]

Has been like that for some years. On error don't hit back and re-post as your reply is probably posted already. Just open a new tab and reload the topic to see if your request was successful on first attempt.



I think there is already an existing tool for this posted in the code-bank sub-forum somewhere.

cheers,
</wqw>

Will do - I'll ignore the error!
Well, I'm happy there's already a conversion tool, but sad, because that was my big way to contribute I'll probably build it anyway, cause it sounds like a fun exercise. I'll probably end up posting it, just for an alternative.

The VTable handling is definitely clean now (was a long road to get rid of VTable subclass and lightweight COM)
Also the latest cleansing of no need for WM_MOUSEACTIVATE handlers anymore gives me the conclusion that the state as of now is pretty confident.
So go for it, now or when new VBCCR17 will be released.

That's good enough for me - I'll give it a shot! I'll keep monitoring the forum and try out VBCCR17. It's actually kinda exciting - it's like getting a new VB7

[Krool]

Will do - I'll ignore the error!
Well, I'm happy there's already a conversion tool, but sad, because that was my big way to contribute I'll probably build it anyway, cause it sounds like a fun exercise. I'll probably end up posting it, just for an alternative.


That's good enough for me - I'll give it a shot! I'll keep monitoring the forum and try out VBCCR17. It's actually kinda exciting - it's like getting a new VB7

You could contribute MUCH if you make a migration guide (documentation). :-)

[KurtB]

I think that would involve said conversion program. It would also involve:
1. Me working with the new controls and identifying differences, new properties, changes to properties, etc.
2. Making any changes necessary to my code that references the controls.

As of yet, I have no experience with the controls, so what I can do is, first, convert the controls in a significant program, and, second, get some experience working with them, and, third, document anything I have to do to get them working. That should provide a good-as-any starting place for a migration guide, right? Any idea when version 17 will be released? (I want to start with the latest release.)

[LaVolpe]

@Krool. You may want to give Kurt a heads up of any standard methods that had to be renamed so he is aware of them when his first run fails due to "Method not Found" type errors. For example, NextSibling, FirstSibling, etc

[KurtB]

Has been like that for some years. On error don't hit back and re-post as your reply is probably posted already. Just open a new tab and reload the topic to see if your request was successful on first attempt.



I think there is already an existing tool for this posted in the code-bank sub-forum somewhere.

cheers,
</wqw>

@Krool. You may want to give Kurt a heads up of any standard methods that had to be renamed so he is aware of them when his first run fails due to "Method not Found" type errors. For example, NextSibling, FirstSibling, etc

I think that maybe what Krool would like to see in this future Migration guide. I'm thinking that some of that will become obvious when I try to compile a freshly converted project. I might even be able to make the convertor update property names and property-related function names.

So, unless there is already a list of changed property names that you can easily send me, maybe give me a chance to discover these, and create some documentation myself. Like I mentioned before, I am extremely busy, but not so busy that I can't do a little bit of documentation on a nice set of controls that makes my life a lot easier Thanks.

[Krool]

I think that maybe what Krool would like to see in this future Migration guide. I'm thinking that some of that will become obvious when I try to compile a freshly converted project. I might even be able to make the convertor update property names and property-related function names.

So, unless there is already a list of changed property names that you can easily send me, maybe give me a chance to discover these, and create some documentation myself. Like I mentioned before, I am extremely busy, but not so busy that I can't do a little bit of documentation on a nice set of controls that makes my life a lot easier Thanks.

VBCCR16 has all latest fixes. And for a replacement it has all it needs. VBCCR17 will still take a while as I wish to include some missing features (e.g. VirtualMode List/ComboBox like already done in ListView).

Concerning names. Like LaVolpe explained for TreeView, since the original method named "Next" and since it is a restricted keyword I was forced to name it "NextSibling".

I don't have notes listing all the differences..

[Krool]

StatusBar

StatusBar.Panels("aPanel").Width = lWidth

returns error 383:Property is read-only
in the MS Controls this was Read/Write

Sorry for late response.

How stupid the behavior.. Yes the .Width property is read-only.
Luckily I put it as following

Public Property Let Width(ByVal Value As Single)
Err.Raise Number:=383, Description:="Property is read-only"
End Property

So I can change it even in the VBCCR16 without breaking compatibility.

But I need to figure out what the MS StatusBar do with the .Width property.

When AutoSize = sbrContents the .Width just changes the .MinWidth property. (redirection)
When AutoSize = sbrSpring the .Width changes nothing. (no-op w/o error)
When AutoSize = sbrNoAutoSize the .Width will be applied 1:1

Am I missing something, Semke?

[LaVolpe]

But I need to figure out what the MS StatusBar do with the .Width property.

I believe it works this way (pseudo code):

' thumb is triangle in bottom right corner if applies
    Offset = 0: Size = 0
    For n = 1 to nrPanels
        Select Case panel(n).AutoSize
        Case sbrNoAutoSize: Size = panel(n).Width
        Case sbrContents: 
            If TextWidth(panel(n).text) > panel(n).MinWidth Then
                Size = TextWidth(panel(n).text)
            Else
                Size = panel(n).MinWidth
            End If
        Case sbrSpring:
            Size = TextWidth(panel(n).text)
        End Select
        draw panel text @ Offset not exceeding Offset + Size
        Offset = Offset + Size + SizeOf(separator)
        If Offset > sbar.ScaleWidth + SizeOf(thumb) Then Exit For 
    Next

[KurtB]

VBCCR16 has all latest fixes. And for a replacement it has all it needs. VBCCR17 will still take a while as I wish to include some missing features (e.g. VirtualMode List/ComboBox like already done in ListView).

Concerning names. Like LaVolpe explained for TreeView, since the original method named "Next" and since it is a restricted keyword I was forced to name it "NextSibling".

I don't have notes listing all the differences..

I've already opened up v16, and I'm checking it out.

I'm sure I'm going to have 100 questions for you, but I'm going to make a log of the questions, and send them all in one step, to avoid overwhelming you. I imagine that most of them can be answered by combing through 70 pages of forum, and eventually I will download these, locally compile them into a single page, and read them. However, I do want to ask and mention a few right off the bat, if that's ok. I'll number them to make conversation a bit easier. Please forgive my ignorance, as I have very little experience in VBCCR as of yet.

1. I've just run the Standard EXE ComCtrls Demo. First off, I must say that this demo needs a lot of work. Sorry for the criticism, right at the start. But this demo has a few flaws:
a. It barely scratches the surface, as far as showing the power of the new controls.
b. All the text is in ANSI English, missing a great opportunity for showing Unicode capabilities, which is a BIG selling point!
c. It's very difficult to see what each component is supposed to do. Sometimes 2 components interact, sometimes not. Some components don't seem to do anything.
d. It takes an experienced VB programmer to realize just how cool it is to be able to load 100,000 items into a ListView in less than one second!
e. There's more, but I don't want to be more negative in my first comment (sorry)

Honestly, I don't expect a demo to be perfect. I already know the controls are good and powerful. But the demo is where first impressions happen. Maybe I can eventually create a demo that showcases the power of the controls.

2. What's the difference between the Standard demo and the ActiveX demo? Is the ActiveX version the same as the Standard version, but without the demo forms? Am I missing something?

3. I noticed a strange form lack-of-refresh issue while paused (debug mode), and I got a crash when stopping the project with the stop button. Is this due to the subclassing stuff? Is it generally a bad idea to stop the program in this manner? And, more importantly, does this only occur when running in the IDE?
(The "lack-of-refresh" is better described as follows: When paused, the VB form would not repaint when passing other windows on top of it. And, in the immediate window, I typed a command that produced a VB error msgbox. But, the msgbox was hidden under this non-painting VB form, and it was nearly impossible to answer the msgbox, giving me the impression that VB had locked up. Eventually, I was able to get focus under that form, and press ENTER, answering the msgbox, and giving me back control of the project. By the way, I'm running VB6 SP6 on a Win7 box).

4. When I start developing "for real" with CCR, I'm going to want to compile the controls into a single OCX, I think, to avoid loading all the UserControls, modules, and Property Pages into the design environment.
a. Have you done this before?
b. Does it work ok?
c. Will it compile the OleGUIDs.tlb into the OCX, so I don't have to load OleGUIDs.tlb into my project?
d. If I do this, and it works, I should probably name the OCX a static name, like VBCCR.OCX, instead of VBCCR16.OCX, right?
e. To extend the previous question, will I have any binary compatibility problems when version 17 is released? Will I be able to compile version 17 into a VBCCR.OCX file, and use it with projects built with version 16, or will I have to rebuild all of my forms?

5. I noticed that some of your controls have a "W" suffix like "ListBoxW" and some do not, like TreeView. I can create a form with the original TreeView and a CCR Treeview on the same form, and they both work. Furthermore, for an original Treeview, the following command evaluates to True, but for a CCR TreeView, it evaluates to False:
IsATreeView = TypeOf Form1.Controls(1) is TreeView

In fact, I cannot determine what name to use to get that statement to return True. I tried a few names. I tried ComCtlsDemo.TreeView, and I tried VBCCR16.TreeView. I actually do have a function that uses TypeOf to check all the controls on a passed form. It's used for language translation. When I open a form, I call a function that loads a language-specific translation for all controls on the form, and applies the translation to the form's controls, in the manner required for each control (sometimes it's .Caption, sometimes it's .ColumnHeaders(n).Text, etc.)

a. The properties window and the toolbox button tooltip both name this control "TreeView". What programmatic control type name is required?
b. Why didn't you name the TreeView "TreeViewW"? Don't get me wrong - I'm not trying to tell you your business. I just mean that it adds a level of confusion in various places that doesn't need to be there, in my humble opinion. I think VB knows it has 2 control types with the same name, so it's forcing me to be more specific and qualify the control name. The toolbox icon looks different, so that helps a bit. And renaming a control type, at this stage, would probably break a lot of projects. I'm just trying to be complete, and document an accurate picture of exactly what I experience from the beginning, through a complete implementation. I hope this explains my intentions of this whole reply.

All in all, everything seems pretty darn nice, so far. I think I'm going to have to build a suite of Unicode string functions that will help me make the most out of the controls. I can't believe that MS forced everyone to store strings 2-bytes per character, but provided no way to get any use out of it I saw some code on the web that allows Unicode Form captions. Do your controls, by chance, provide this capability?

Thanks again for your time. From now on, I'll queue up my questions. I had to ask these to help me determine and plan a starting point.

[LaVolpe]

@Kurt. This is an easy one, so I will pick it off and let Krool concentrate on the tool-related issues

IsATreeView = TypeOf Form1.Controls(1) is TreeView

If you have controls having the same name from different libraries, you will need to include the library name else VB picks one based on some hierarchy. The same would apply if you added both v6 & v5 of Windows common controls to the same project.

IsATreeView = TypeOf Form1.Controls(1) is ComctlLib.TreeView (MSComctlLib.TreeView)
IsATreeView = TypeOf Form1.Controls(1) is ComCtlsDemo.TreeView ' << works for me
If in doubt, hit F8 and see what library names are loaded into project

Of course, in the compiled ocx, its library name will not be ComCtlsDemo

[Krool]

StatusBar

StatusBar.Panels("aPanel").Width = lWidth

returns error 383:Property is read-only
in the MS Controls this was Read/Write

I believe it works this way (pseudo code):

Update released.

Semke, the Width property of a Panel is now not read-only anymore. Luckily VBCCR16 could be updated w/o break of compatibility. (technical sense)
Please confirm that it's fine. Thanks

LaVolpe, the algo was already sufficient. Only a small addition was needed to have the Width property behaves as MS.
Just a new internal per panel variable 'FixedWidth' which is initialized as -1 (alias for invalid).
It will be taken into consideration when it is > -1 and AutoSize is None.
For AutoSize Content MS really only changes the MinWidth (redirection), so I did the same.
For AutoSize Spring MS really does nothing when applying a Width property. It also does not cache something which will be taken when switching to another AutoSize property.

1. I've just run the Standard EXE ComCtrls Demo. First off, I must say that this demo needs a lot of work. Sorry for the criticism, right at the start. But this demo has a few flaws:
a. It barely scratches the surface, as far as showing the power of the new controls.
b. All the text is in ANSI English, missing a great opportunity for showing Unicode capabilities, which is a BIG selling point!
c. It's very difficult to see what each component is supposed to do. Sometimes 2 components interact, sometimes not. Some components don't seem to do anything.
d. It takes an experienced VB programmer to realize just how cool it is to be able to load 100,000 items into a ListView in less than one second!
e. There's more, but I don't want to be more negative in my first comment (sorry)

Honestly, I don't expect a demo to be perfect. I already know the controls are good and powerful. But the demo is where first impressions happen. Maybe I can eventually create a demo that showcases the power of the controls.

If you want you can make a new demo project.
For me it's just a testing demo and not a "show room".

2. What's the difference between the Standard demo and the ActiveX demo? Is the ActiveX version the same as the Standard version, but without the demo forms? Am I missing something?

There is no ActiveX demo. The ActiveX project is a real project for compilation. The Standard demo is just for confusion and the "possibility" to compiled into the Std-EXE version without a need for a OCX. The standard demo is the leading source which will be derived into the OCX at some point.
However, using OCX version is better. If there is an update, just replace the OCX and there you go.
Also it's stable for IDE usage and with the SxS reg-free approach just convinient.

4. When I start developing "for real" with CCR, I'm going to want to compile the controls into a single OCX, I think, to avoid loading all the UserControls, modules, and Property Pages into the design environment.
a. Have you done this before?
b. Does it work ok?
c. Will it compile the OleGUIDs.tlb into the OCX, so I don't have to load OleGUIDs.tlb into my project?
d. If I do this, and it works, I should probably name the OCX a static name, like VBCCR.OCX, instead of VBCCR16.OCX, right?
e. To extend the previous question, will I have any binary compatibility problems when version 17 is released? Will I be able to compile version 17 into a VBCCR.OCX file, and use it with projects built with version 16, or will I have to rebuild all of my forms?

There is already a pre-compiled OCX available. I recommend using the pre-compiled binary instead cooking your own OCX.
OLEGuids.tlb will be compiled INTO it. It's only needed for YOU the developer and just within the IDE.

5. I noticed that some of your controls have a "W" suffix like "ListBoxW" and some do not, like TreeView. I can create a form with the original TreeView and a CCR Treeview on the same form, and they both work. Furthermore, for an original Treeview, the following command evaluates to True, but for a CCR TreeView, it evaluates to False:
IsATreeView = TypeOf Form1.Controls(1) is TreeView

In fact, I cannot determine what name to use to get that statement to return True. I tried a few names. I tried ComCtlsDemo.TreeView, and I tried VBCCR16.TreeView. I actually do have a function that uses TypeOf to check all the controls on a passed form. It's used for language translation. When I open a form, I call a function that loads a language-specific translation for all controls on the form, and applies the translation to the form's controls, in the manner required for each control (sometimes it's .Caption, sometimes it's .ColumnHeaders(n).Text, etc.)

a. The properties window and the toolbox button tooltip both name this control "TreeView". What programmatic control type name is required?
b. Why didn't you name the TreeView "TreeViewW"? Don't get me wrong - I'm not trying to tell you your business. I just mean that it adds a level of confusion in various places that doesn't need to be there, in my humble opinion. I think VB knows it has 2 control types with the same name, so it's forcing me to be more specific and qualify the control name. The toolbox icon looks different, so that helps a bit. And renaming a control type, at this stage, would probably break a lot of projects. I'm just trying to be complete, and document an accurate picture of exactly what I experience from the beginning, through a complete implementation. I hope this explains my intentions of this whole reply.

LaVolpe already answered. (thank you)

About this "W" suffix. I made it according to following logic:

If there is a VB intrinsic comparable control -> "W" suffix
Else not, because I assume that the MS Common Controls are replaced and ComctlLib and such are not referenced anymore. Thus there is no conflict with same namings.
The "W" is really just put to make it easier to distinguish between VB and VBCCR. (not for the MS Common Controls)

[Krool]

Stupid bugfix that was created in today's update for StatusBar. Sorry.. should be fine now.

[KurtB]

Thanks LaVolpe and Krool. It all makes sense.

@Krool: I meant no insult about your demo. As a testbed, it's fine, and the "audience" is made up of programmers. But even programmers want to see what your controls can do! And, honestly, I think you deserve a showcase for your controls. I'll see what I can do. It's going to take me some time, however.

I think, to avoid asking foolish questions, I'll need to combine and read this thread in its entirety, and spend some time with the controls. It looks like you put a lot of care into emulating the original controls as much as possible, which I value very highly - it means that replacing the originals with your controls should be nearly seamless for everyone (and probably a nightmare for you, huh?

It's going to take me some time, but I'll get back to you. Take care.

[KurtB]

Uh - one more comment:

This code is freakin' insane! (I mean that in the best way possible.) How did you learn how to do all of this? Was there some disassembling involved? Why are you building VB6 controls, instead of just building your own language???

Very impressive, man, I gotta say. What's your secret? Me like.

[MountainMan]

You will find that there are quite a few guys on this site that do stuff with VB6 that you would have thought was not possible...

BTW, I had that double post problem and someone told me to do "Go Advanced" on replies and you only get 1 post. I do that now and it seems to work.

[KurtB]

Oh, I already knew they were good. In all honesty, risking sounding conceited, I'm good enough to know 'good' when I see it.
Most guys will chuck a jar of lukewarm cat piss in your general direction. Many of the guys on this site can lob a grenade 100 feet towards you, and you better run. This code is like a laser-guided precision strike, and there's no need to run...Boom! It's all over.

Don't get me wrong - I'm no mastermind. But, when you've been coding for 40+, you just know. I know enough to recognize that the API calls being made here are pretty darn close to what the original C code was doing. It's all the meat, with very little fat. Sure, you could beat on it for a while, and maybe wring 5 to 10% more this-or-that out of it.

From what I've seen, it's quite a clean codebase - nicely named vars, enums instead of magic numbers, VB quirks maintained. Obviously a labor of love. I don't know how much collaboration was involved, but, again, I'm impressed, which is rare.

In my career, I've developed a pet-peeve when end-users don't realize just how much work went into the final product. You put in a ton of work behind-the-scenes, and the end-users see it and think "Of course it works that way, how else would it work?" They don't realize that your program is only easy for them to use because you put in countless hours making it that way. They don't realize that you added a clever optimization that reduced runtime from hours to seconds. And, they don't care, as long as it always runs that fast!

I think these controls are like that in a way: A ton of work has given us exactly what we expected to get in 1995. If we hadn't dealt with the quirky MS controls for 25 years, the CCR controls do what you expect. Which is awesome. We are the only people that can really appreciate them for what they are - that's just the way it is.

I knew VB could be made to do it, after beating it into submission. I've been wanting to do something like this for a long time. But, I'm glad I don't have to, because it would have been the most difficult project I've ever done, I'm sure. I wish you guys knew my capabilities, only so that you would believe me when I say that this is a top-notch accomplishment! I am rarely such a cheerleader...it's kinda making me sick to read it back I'm sure it sounds over-the-top to everyone reading it. I can say no more.

[Mith]

Hey Kurt8,

i have some information for you about "mass-testing" the VBCCR control.

The popular freeware AllDup uses the VBCCR OCX control. The freeware is available in 20 different languages.
They have a lot of users with different computer setups, Windows versions and so on.

A good proof that the VBCCR OCX control is running stable, or?

[Mith]

The label control features the useful AutoSize property.

Is it possible to add the AutoSize property to the CheckBox and OptionButton control?

This would be very useful when dealing with multi-language apps!

Currently i extend the width of every CheckBox/OptionButton to the max. visible size to fit text from different languages.

[KurtB]

@Mith: Yes, that's good proof! Naturally, a programmer always has to do some testing. But I like to ask the developer himself, because good developers are always honest about the state of their wares!

When sizing controls, I use this:
controlName.Width = controlName.TextWidth(Caption)

Of course, a built-in property is nicer.

[Mith]

controlName.Width = controlName.TextWidth(Caption)

VBCCR doesnt support the control property .TextWidth ...

having a AutoSize property would be very handy...

sometimes when needed i use the API GetTextExtentPoint32W to determine the width of unicode text.

[Krool]

VBCCR doesnt support the control property .TextWidth ...

having a AutoSize property would be very handy...

sometimes when needed i use the API GetTextExtentPoint32W to determine the width of unicode text.

Does the VB control support TextWidth?
I guess he was referring to the Form's TextWidth function.

The problem is that BCM_GETIDEALSIZE works only for push button. So for a check and radio button it would need to be calculated manually.. will look after it.

[KurtB]

Controls that can be PRINTed on support the TextWidth and TextHeight property, so, for example, Forms, Picture Boxes, and User Controls. If you set a form's ScaleMode property to vbPixels, and both the label and the form use the same font, you can auto-size a label on the form as follows:

BorderWidth = 4: Label1.Width = Form1.TextWidth(Label1.Caption) + BorderWidth

It would probably be better to request the BorderWidth via a Windows API, instead of hard-coding '4', but unless I'm building a library (like VBCCR), I usually can't be bothered.

I actually prefer to set the width myself, to handle special cases, like if the label's caption would make the label wider than the form it's on!

[Mith]

The problem is that BCM_GETIDEALSIZE works only for push button. So for a check and radio button it would need to be calculated manually.. will look after it.

Before i switched to the VBCCR controls i used my own unicode usercontrols with the support of AutoSize for the Checkbox & OptionButton control.
I used the windows API GetTextExtentPoint32W to determine the width of the unicode text. t's quite easy to implement such a feature. The only tricky thing was to take care of the Alignment property, for example, if you have a RightAlignment you need to move the control to the left and not only extend the usercontrol width! Just my 2 cents...

[Krool]

Before i switched to the VBCCR controls i used my own unicode usercontrols with the support of AutoSize for the Checkbox & OptionButton control.
I used the windows API GetTextExtentPoint32W to determine the width of the unicode text. t's quite easy to implement such a feature. The only tricky thing was to take care of the Alignment property, for example, if you have a RightAlignment you need to move the control to the left and not only extend the usercontrol width! Just my 2 cents...

In the VBFlexGrid I already included a TextWidth function.
It also takes into account multi-line text, like VB Form's TextWidth.

So I will include soon some TextWidth function to certain VBCCR controls. (Where it makes sense)

Thanks for your comments always.

[Semke]

In the VBFlexGrid I already included a TextWidth function.
It also takes into account multi-line text, like VB Form's TextWidth.

So I will include soon some TextWidth function to certain VBCCR controls. (Where it makes sense)

Thanks for your comments always.

speaking of VBFlexGrid

I remember some time ago, there was a discussion of whether to include/combine it with VBCC.
so, I wonder if it will be so, in my opinion, it would be very good idea.

[Arnoutdv]

In my opinion it's not a good idea.
Why put an independent control in the same OCX?
Makes it more difficult to maintain and for the developer nor the end user it makes no difference.

[OldClock]

You could contribute MUCH if you make a migration guide (documentation). :-)

I wrote that here:
http://www.vbforums.com/showthread.p...=1#post5444945

Do you maintain a bug list

https://github.com/Kr00l/VBCCR/issues
https://github.com/Kr00l/VBCCR/blob/...0revisions.txt

[OldClock]

Kr00l I'm having an issue with the CommonDialog. I placed one on MDIForm1, then I need to use it from some module:

    Dim cDlg As VBCCR16.CommonDialog
    Set cDlg = MDIForm1.ComDlg

This results in:

Run-time error: '13':
Type mismatch

Same if I do:

    Dim cDlg As CommonDialog
    Set cDlg = MDIForm1.ComDlg

I now looked inside MDIForm1.frm and see this:

   Begin MSComDlg.CommonDialog ComDlg

How do I place a VBCCR16 CommonDialog instead of a MSComDlg? I only have one CommonDialog button in the Toolbox...

[OldClock]

Well I solved/worked around this by:
1. Deleting all CommonDialog controls from my forms.
2. This allowed me to remove the "Microsoft Common Dialog Control 6.0" component.
3. With no actual CommonDialog control on any form, I then changed the code to:

    Dim cDlg As VBCCR16.CommonDialog
    Set cDlg = New VBCCR16.CommonDialog

And it works fine.