'Next' is a reserved keyword. So I can't use it.Quote:
Originally Posted by Mith
So I used 'NextSibling'..
Printable View
'Next' is a reserved keyword. So I can't use it.Quote:
Originally Posted by Mith
So I used 'NextSibling'..
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
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.
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.Quote:
Originally Posted by KurtB
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.
If you find something that can be improved or simplified you can advise. No problem.Quote:
Originally Posted by KurtB
Of course the biggest help so far was the crowd testing.
He means 70 pages, 2700+ posts :)Quote:
Originally Posted by Krool
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.
I found a work around;Quote:
Originally Posted by Semke
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
Code:Set txtBrandName.Container = tbrToolbar
Set lblBrandName.Container = tbrToolbar
Sorry for the delay and not responding.Quote:
Originally Posted by Semke
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.
Yeah, I guess that is what I meant :)Quote:
Originally Posted by LaVolpe
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!
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.Quote:
Originally Posted by KurtB
I think there is already an existing tool for this posted in the code-bank sub-forum somewhere.Quote:
Originally Posted by KurtB
cheers,
</wqw>
The VTable handling is definitely clean now (was a long road to get rid of VTable subclass and lightweight COM)Quote:
Originally Posted by KurtB
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.
Will do - I'll ignore the error!Quote:
Originally Posted by wqweto
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 :)Quote:
Originally Posted by Krool
You could contribute MUCH if you make a migration guide (documentation). :-)Quote:
Originally Posted by 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.)
@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
Quote:
Originally Posted by wqweto
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.Quote:
Originally Posted by LaVolpe
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).Quote:
Originally Posted by KurtB
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..
Sorry for late response.Quote:
Originally Posted by Semke
How stupid the behavior.. Yes the .Width property is read-only.
Luckily I put it as following
So I can change it even in the VBCCR16 without breaking compatibility.Code:Public Property Let Width(ByVal Value As Single)
Err.Raise Number:=383, Description:="Property is read-only"
End Property
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?
I believe it works this way (pseudo code):Quote:
But I need to figure out what the MS StatusBar do with the .Width property.
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
I've already opened up v16, and I'm checking it out.Quote:
Originally Posted by Krool
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.
@Kurt. This is an easy one, so I will pick it off and let Krool concentrate on the tool-related issues
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.Quote:
IsATreeView = TypeOf Form1.Controls(1) is TreeView
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
Quote:
Originally Posted by Semke
Update released.Quote:
Originally Posted by LaVolpe
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.
If you want you can make a new demo project. :)Quote:
Originally Posted by KurtB
For me it's just a testing demo and not a "show room".
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.Quote:
Originally Posted by KurtB
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.
There is already a pre-compiled OCX available. I recommend using the pre-compiled binary instead cooking your own OCX.Quote:
Originally Posted by KurtB
OLEGuids.tlb will be compiled INTO it. It's only needed for YOU the developer and just within the IDE.
LaVolpe already answered. (thank you)Quote:
Originally Posted by KurtB
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)
Stupid bugfix that was created in today's update for StatusBar. Sorry.. should be fine now.
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.
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.
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.
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.
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?
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.
@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.
VBCCR doesnt support the control property .TextWidth ...Quote:
Originally Posted by KurtB
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?Quote:
Originally Posted by Mith
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.
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!
Before i switched to the VBCCR controls i used my own unicode usercontrols with the support of AutoSize for the Checkbox & OptionButton control.Quote:
Originally Posted by Krool
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.Quote:
Originally Posted by Mith
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 VBFlexGridQuote:
Originally Posted by Krool
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.
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.
I wrote that here:Quote:
Originally Posted by Krool
http://www.vbforums.com/showthread.p...=1#post5444945
https://github.com/Kr00l/VBCCR/issuesQuote:
Originally Posted by KurtB
https://github.com/Kr00l/VBCCR/blob/...0revisions.txt
Kr00l I'm having an issue with the CommonDialog. I placed one on MDIForm1, then I need to use it from some module:
This results in:Code:Dim cDlg As VBCCR16.CommonDialog
Set cDlg = MDIForm1.ComDlg
Same if I do:Quote:
Run-time error: '13':
Type mismatch
I now looked inside MDIForm1.frm and see this:Code:Dim cDlg As CommonDialog
Set cDlg = MDIForm1.ComDlg
How do I place a VBCCR16 CommonDialog instead of a MSComDlg? I only have one CommonDialog button in the Toolbox...Code:Begin MSComDlg.CommonDialog ComDlg
Attachment 177023
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:
And it works fine.Code:Dim cDlg As VBCCR16.CommonDialog
Set cDlg = New VBCCR16.CommonDialog