Big fan of Krool's CCR works. My only objection is having
32 controls in the toolbox.
So I went to work compiling all 32 controls. Then I tested
the ocxes in a Standard Exe, with no problems.
Now you can load an individual vbp and compile to ocx.
I named all the controls with the prefix CCR so they
will be easily located in VB's toolbox.
Note, keep the zip's directory structure. You should
get 32 subdirs for each control plus one called
Common which has the bas/cls modules used in all
the vbp's.
I downloaded the latest version before starting this.
Re: Common Controls Replacement Individual Controls
Hi VBClassic04,
If you only need a couple controls, you don't need to pull the whole thing in (thinking about just pulling in source code).
I'm currently working on a little project I want to stay "portable", so I'm using two of Krool's controls, the Slider and the TreeView. To use just those two, I went through and isolated these files:
ComCtlsBase.bas
Common.bas
VisualStyles.bas
VTableHandle.bas
ISubclass.cls
TvwNode.cls
TvwNodes.cls
Slider.ctl
TreeView.ctl
I also went through and deleted the property pages for both Slider.ctl and TreeView.ctl, as I'm fine using the properties window, and also the property pages pull in many of his other controls.
For my project, I just included those in the project. However, if I wanted to, I could compile those files into an OCX, getting just my two desired controls. If I created an OCX for each control, I'd have a great deal of redundant code, which wouldn't be good.
So yeah, I see your motivation. I've just come up with a somewhat different solution.
Take Care,
Elroy
p.s. Yeah, Krool has done some incredible work, and I'm amazed at how he's stuck with it to keep polishing and stomp out every conceivable bug.
Last edited by Elroy; Feb 5th, 2020 at 11:21 AM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Re: Common Controls Replacement Individual Controls
All credit to Krool and to you for separating it all up. It needed to be done. Sometimes you want to be able to add single control without adding in the complexity of 30 or so others.
One limitation is that Krool did not offer this from the beginning.
I know we could all rip it to bits as described above but that makes it less accessible to the majority that might not have the skill to do so but who just want a simple single control and adding 32 seems like overkill (could also introduce unknown bugs and unnecessary additional complexity).
Re: Common Controls Replacement Individual Controls
Originally Posted by VBClassic04
Elroy, yerever: thanks for your comments.
Should note that the message 'Unable to set the version compatible...'
may pop up when loading the vbp's. This can be ignored.
Also, it may be necessary to register the ocx in some cases.
Yeah, for me, it's more about keeping my project "portable", rather than keeping clutter out of my Toolbox. But both are worthwhile aims.
So, in my case, I just wanted the pieces necessary to throw into my project, without bringing Krool's whole package in.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Re: Common Controls Replacement Individual Controls
I don't understand this topic of compiling 32 isolated OCX instead of 1 single big OCX.
Nowadays we don't care about a 5MB file.
Also when a project uses a OCX (that contains 32 controls) and the project uses actually only 5 then there is NO difference in
- performance or
- memory
When you bother about a "big toolbox" then just add another tab in the IDE to have a better overview.
The "General" tab has all VB controls and the "VBCCR16" tab has all VBCCR16 controls. Simple as that.
Originally Posted by Elroy
I also went through and deleted the property pages for both Slider.ctl and TreeView.ctl, as I'm fine using the properties window, and also the property pages pull in many of his other controls.
The statement "pull in many of his other controls" is wrong.
When you extracted the files from the Std-EXE version control then all property pages are VB intrinsic controls.
Only when you extracted them from the OCX version then all property pages contain VBCCR controls.
The reason is simple, the OCX control always contains ALL, so no issue to reference to VBCCR controls in property pages to allow unicode already there.
However, for Std-EXE control I intentionally contain VB Controls to allow only picking 1, 2 or 5 controls in a project.
When you only need 1 control, then it's better to embed a small portion from the Std-EXE version.
If you need 7 controls, then I would consider using reg-free OCX approach.
Conclusion:
Everything is already as flexible as possible. Std-EXE version and OCX version.
Nobody needs a OCX for just 1 control. If you need only 1 then take the Std-EXE approach.
Re: Common Controls Replacement Individual Controls
Originally Posted by Krool
The statement "pull in many of his other controls" is wrong.
When you extracted the files from the Std-EXE version control then all property pages are VB intrinsic controls.
Hi Krool,
Yeah, I might have mis-spoke there, I'm not sure. What happened to me was ... when I was trying to isolate the Slider and TreeView, I found that it was still wanting ComboBox stuff (which I didn't care about). My first attempt at solving the problem was just to delete all the property pages from the Slider and TreeView controls (and remove all property page modules), and that worked perfectly. I got it down to those 9 modules I listed in post #2. There may have been a better way, but I'm up and running, and happy.
Originally Posted by Krool
If you need 7 controls, then I would consider using reg-free OCX approach.
For this little project I'm working on, I'm trying to stay "totally portable". And, as part of that, I'd rather not have any "secondary" files at all (and no installation). The program does open and save user files, but that's on them.
-----
Krool, again, MANY thanks for your magnificent work.
Last edited by Elroy; Feb 7th, 2020 at 11:32 AM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Re: Common Controls Replacement Individual Controls
Originally Posted by VBClassic04
Elroy, yerever: thanks for your comments.
FYI, I was spurred into using your separation of Krool's controls in this change to my VB6 project and they work well to replace the MS originals. Krool won't like me using it this way but it works for me.
Re: Common Controls Replacement Individual Controls
I don't mean to hijack this thread but the capability of using just one or a few controls is already built-in to the utility I wrote for Krool's controls. I did this to specifically address the issue of using just a few controls in your code but at the same time having access to all of the controls while you are in development.
The way it works is that you develop with the OCX version so that you have access to any/all of the controls in the IDE. Then when yo are ready to produce an .EXE you do it by using my utility and it will switch to the Std-EXE version of the controls for any controls you actually have used and skipping the others. So not only do you get a smaller project you also have no dependencies in the EXE (i.e. you don't need to distribute the OCX file with your program). BTW, it does all of this without overwriting your development files so you can maintain your code using the OCX and use the utility to make the smaller EXE when no dependencies whenever yo want a new EXE.
That was my main motivation for writing the utility. Way back i the day I learned PC programming using Turbo Pascal and one of the cool feature of it was that it only pulled in code you actually used. Krool has a point that a 5 MB program is not as big of a deal as it used to be and I thought combining that with OCX development/standalone EXE was too tempting to pass up.
Re: Common Controls Replacement Individual Controls
I don't mean to hijack this thread but the capability of using just one or a few controls is already built-in to the utility I wrote for Krool's controls. I did this to specifically address the issue of using just a few controls in your code but at the same time having access to all of the controls while you are in development.
The way it works is that you develop with the OCX version so that you have access to any/all of the controls in the IDE. Then when you are ready to produce an .EXE you do it by using my utility and it will switch to the Std-EXE version of the controls for any controls you actually have used and skipping the others. So not only do you get a smaller project you also have no dependencies in the EXE (i.e. you don't need to distribute the OCX file with your program). BTW, it does all of this without overwriting your development files so you can maintain your code using the OCX and use the utility to make the smaller EXE when no dependencies whenever yo want a new EXE.
That was my main motivation for writing the utility. Way back i the day I learned PC programming using Turbo Pascal and one of the cool feature of it was that it only pulled in code you actually used. Krool has a point that a 5 MB program is not as big of a deal as it used to be and I thought combining that with OCX development/standalone EXE was too tempting to pass up.
Re: Common Controls Replacement Individual Controls
Originally Posted by MountainMan
I don't mean to hijack this thread but the capability of using just one or a few controls is already built-in to the utility I wrote for Krool's controls.
You aren't hijacking the thread at all. This is probably exactly what I was looking for when I asked the same question on an earlier thread of mine concerning just wanting to use the treeview in my program. Everyone seemed to think that I was barking up the wrong tree only wanting to add the control that my project needed. I think of maintenance, bug-fixing and implementation as being the worst part of programming and I only want to introduce the bare minimum in order to make that as easy as possible. With that in mind I need to know exactly what I have introduced into a program. Thanks for bringing it up, I will read that thread thoroughly.
Re: the name of your thread - the word documentation. The problem seems to be the perennial problem of developers doing what they do best ie. code and then ignoring the absolute essential for any major or minor project - the documentation. Krool's replacement controls seem to fall into this category, I have found the 3rd party installation and configuration guide but any further documentation seems to fragmented and hard to find, searching a massive forum thread is not my preferred route for finding fixes.
I suppose that as the replacement controls are meant to replace the originals word for word and line for line then the documentation already exists from Microsoft. However, that isn't really the case as differences in implementation do occur and each difference needs to be documented and an idiot-proof guide written for those that would like to use Krool's controls but don't have the complete set of programming knowledge to do so.
I really do think that with a professional set of tools such as Krool's, they warrant a wiki, a download page that everyone is referred to and a separate forum to discuss problems. I know this place acts as a the forum for them but a wiki can be an indispensable and essential place for user experience to form documentation. If the location is created then users can naturally add documentation in a structured manner and it grows.
I already maintain documentation for other projects and it is a do-able task. It needs to be created by the project owner and be recognised as the official location or it quickly falls apart. I'd be prepared to add my penn'orth but I am not a competent enough dev to build it.
Just my opinion but to sum up - Krool's controls are great but they need some structured documentation.
PS. if you use the quick reply it always ends up with a duplicate.
Use the advanced button.
PPS. The 3rd party documentation that I had previously read was actually your own .doc referred to in your link. I found it comprehensive with regard to installation &c, also a heavy read and a little unstructured/difficult to use. However, I think it might go well into a wiki an given some structure it could form the start of a good online documentation set. Good on you for creating it.
Last edited by yereverluvinuncleber; Feb 11th, 2020 at 08:46 AM.
Reason: post duplication and docs
Re: Common Controls Replacement Individual Controls
As you probably noticed, my documentation did not address how to use the various properties and methods of each control. I felt like that was the responsibility and right of the author of the controls. However, given what Krool has done, if I had to choose whether he wrote documentation or code, I am thankful he has been coding...
Re: Common Controls Replacement Individual Controls
Originally Posted by MountainMan
I am thankful he has been coding...
Yes, quite right. I understand why you have set about to do what you have done and it does the job.
When the dev fails to document but is clearly only capable of delivering the code through time constraints or similar then it makes sense for the user community to document what they have found. In this case we are the users and so it makes sense for us to contribute as the author is busy coding and bug-fixing or just hates documentation (more likely). It also makes sense to document just the differences/improvements as the rest should all be the same.
A wiki allows us to contribute. It would need to be either yourself or Krool that created it, you having already been accepted as Krool's de facto documentation manager (officially or otherwise) but it would be best if Krool set up the wiki as it becomes 'official'.
Last edited by yereverluvinuncleber; Feb 12th, 2020 at 04:44 AM.
Re: Common Controls Replacement Individual Controls
OK, thread thoroughly hijacked now.
These are my notes from the two controls that I have used ccrSlider.ocx and ccrTreeView.ocx, both extracted from Krool's creation. As I have come across the differences I have made notes, that is all these are, just notes and for my eyes alone. I don't know whether the terminology is correct, whether my code is 'correct' and the format is just a brain dump. However some of it might be useful for a web searcher but at the moment it sits on my C: drive only useful for me.
The Slider Control
=============
Differences:
Improvement is that you can set a backcolor that works, it was possible to set a background colour on the old slider but it would not 'take' until the colour was set and then the slider value was manually changed bu the user. Doing so in code did not seem to work and in any case might cause an adverse effect according to how you utilise the slider within your program.
Krool's slider worked out of the box with no special treatment. I simply created a slider with the same name and copied all the property values across.
If you have a lot of sliders to replace then you can easily convert all existing MSCOMCTL sliders by editing the project's .frm file.
First of all, in the IDE on the toolbar, right click and select components, tick Krool's slider component adding it to your toolbar. Then save the project and edit the project .frm file in an external editor such as Context.
You will see something like:
Object = "{13E244CC-5B1A-45EA-A5BC-D3906B9ABB79}#1.0#0"; "CCRSlider.ocx" showing that the slider object is now part of your project.
Search for all occurrences of MSCOMCTL.slider and replace it with CCRSlider.Slider - where CCRSlider is the name of the slider control.
Note that the standard slider allows the TickFrequency to be set at a value of 0. In fact, when you add a MSCOMCTL slider it inserts a TickFrequency = 0 by default. This property value is invalid for Krool's alternative slider and you will need to remove all occurrences of this property having a zero value.
Re-open the project in the VB6 IDE and if you have made changes correctly there will be no errors. If you haven't removed all the TickFrequency = 0 then an error will be generated for each Krool slider.
In the IDE on the toolbar, right click and select components, unclick the MSCOMCTL controls and if you have no existing references to MSCOMCTL it will allow you to detach Microsoft's group of objects.
The Treeview Control
===============
Where you had an MSCOM treeview in place on your form you would refer to it directly using Node. When using Krool's treeview control, you need to change any reference to the old control.
Code:
' this next line is the MSCOMTCL.OCX usage declaring a Treeview node object
'Dim tNode As Node
' this is the reference for Krool's treeview replacement of the Treeview control
Dim tNode As CCRTreeView.TvwNode ' where CCRTreeView is the name of the OCX.
How to declare an external control as a type in a subroutine.
-----------------------------------------------------------------------------
When calling a routine, a change is required to refer to the new treeview control. Where you had an MSCOM treeview in place on your form you would refer to it directly using the treeview object name. When using Krool's treview control, you need to change the reference to it so it is called by the new name.
Code:
' this next line is the MSCOMTCL.OCX usage of the Treeview object
'Private Sub addtotree(path As String, tv As TreeView)
' this next line is the alternative reference for Krool's treeview replacement passing the new Treeview object itself
Private Sub addtotree(path As String, tv As CCRTreeView.TreeView)
-oOo-
Some of the node relationship descriptors have changed, these can be found by using the VB6 in built code-assist that will list the new names
Code:
' this next line is the MSCOMTCL.OCX usage of the Treeview TvwChild property
tv.Nodes.Add path, TvwChild, path & "\" & folder1.Name, folder1.Name
' this next line is the Krool replacement usage of the Treeview TvwChild property
tv.Nodes.Add path, CCRTreeView.TvwNodeRelationshipChild, path & "\" & folder1.Name, folder1.Name
-oOo-
The old MSCOMCTL treeview, when you click on a node in the tree, the click captured using
folderTreeView_Click()
- then the returned node is the one you just clicked on as you would expect.
eg. folderTreeView.SelectedItem.Key is the current node in the tree
It would seem that using Krool's TreeView that is not the case.
eg. folderTreeView.SelectedItem.Key is now always the previously selected node in the tree and not the one you think you have just selected. The treeview click is now merely registering the click on the treeview and not on the node itself.
Instead of this event:
Private Sub folderTreeView_Click()
you now have to create a new event:
Private Sub folderTreeView_NodeSelect(ByVal Node As CCRTreeView.TvwNode)
This catches a click on the actual node and not just the treeview as a whole.
- and where using the old MSCOM treeview you might have wanted to call that event to cause a click on the selected node:
folderTreeView_Click ' this causes the node to expand
instead you need to add:
folderTreeView.SelectedItem.Expanded = True
This seems to somewhat operate in a similar manner to the .NET treeview where the click event selects the previous node and not the current one, in .NET you have to use the after event to select the currently clicked node.
Performance:
MSCOMCTL.OCX treeview on a core2duo 2.5ghz
5400rpm SATA 2 HD took 45 secs to open a large (2,530) multi-folder location and populate a tree
SATA 1 SSD took a mere 5 secs to open the same folder and populate.
Krool's OCX performance is the same.
-oOo-
Apologies for that brain dump but the point is, if just a few others just do a little of the same just as you have done then the documentation quickly starts to build. The someone adds references to the existing MS documentation and soon you have something that might be useful. The wiki format is the best as we can all contribute.
Last edited by yereverluvinuncleber; Feb 26th, 2020 at 06:59 PM.
Reason: added replacement of multiple sliders in .frm
Re: Common Controls Replacement Individual Controls
Originally Posted by yereverluvinuncleber
Yes, quite right. I understand why you have set about to do what you have done and it does the job.
When the dev fails to document but is clearly only capable of delivering the code through time constraints or similar then it makes sense for the user community to document what they have found. In this case we are the users and so it makes sense for us to contribute as the author is busy coding and bug-fixing or just hates documentation (more likely). It also makes sense to document just the differences/improvements as the rest should all be the same.
A wiki allows us to contribute. It would need to be either yourself or Krool that created it, you having already been accepted as Krool's de facto documentation manager (officially or otherwise) but it would be best if Krool set up the wiki as it becomes 'official'.
You pointed out correctly. Documentation is not my thing..
VBCCR is 98% compatible to MS behavior. Only a few things are different, like you explained in the TreeView.
In most cases, if something is different, then it has a deeper meaning. (or not, but then it's an unknown bug)
Another difference, just as an example coming to my mind, is on a ListBoxW control with .Style = CheckBox.
To change in VB.ListBox (with .Style = CheckBox) the check state of an item by code you need to set List1.Selected(Index) property to True.
However, this has the annoying disadvantage in the VB.ListBox that the selected state cannot be set anymore by code.
Therefore, in ListBoxW the .Selected property stays like in .Style = Normal to control the selected state.
Instead, the ListBoxW introduced a new property ListBoxW1.ItemChecked(Index) which can be set to True or False to control the check state.
I agree that such things need to be documented, let's say in a "migration guide".
Who is willing to do it ?
Re: Common Controls Replacement Individual Controls
Originally Posted by Krool
You pointed out correctly. Documentation is not my thing...
I expected that, and no criticism intended, I have met many, many devs (I was a dreaded Project Manager) and they all hated documentation inside the code or outside.
Originally Posted by Krool
I agree that such things need to be documented, let's say in a "migration guide".
Who is willing to do it ?
I don't have the capability to do it for you only having very limited experience of the two controls I have managed to get working. I just know that I need to document what I find as it is the ONLY way I have of retaining the information, it sort of goes 'in' when I document stuff. However I'd be happy to contribute what I find. I have just overhauled some of the documentation for ReactOS - https://reactos.org/wiki/ReactOS_FAQ - that is just to prove that documentation by others does actually work.
Also, every repository on GitHub comes with a wiki and I suppose your code is there already? So, you should have access to a wiki. The trouble is Mr. Krool - that you probably have to set up the Wiki as it gives some credibility, being 'official'.
I am sure the themountainman would contribute his installation and configuration guide, a couple of others like Elroy might be tempted to add their penn'orth. I'd add my uneducated bit and you have a start, it can only grow from that point. You, yourself could drop in from time to time and add a bit here and there.
Re: Common Controls Replacement Individual Controls
Originally Posted by Krool
VBCCR is 98% compatible to MS behavior. ...
Originally Posted by yereverluvinuncleber
... a couple of others like Elroy might be tempted to add their penn'orth.
Wait, what!
I'm being volunteered to write documentation? Eeek. Documentation isn't my thing either. Actually, truth be told, I work VERY hard to make all of my programming as intuitive as possible. My philosophy is, if you know the task that the software is trying to help you with, using the software should be obvious. But hey, that's just me.
Regarding VBCCR, I think the same idea sort of holds. (I'm not entirely comfortable saying this, but I'm going to say it anyway.) Personally, if you don't have a pretty thorough understanding of what the original controls do (and how to use them), I'm not sure you've got any business using VBCCR.
And yeah, there's nothing to stop you from making a reference (Menu --> Project --> Components) to the original controls, even when using VBCCR. Then, if you forget some property or method, throw the original on some form in your project, call up the property or method, and hit F1.
As Krool mentioned, there are a few (very few) differences, but nothing over which to get our undies in a bunch.
-----
Anyway, hey Krool, I actually DO have one (if you happen to get over this way). I've included the VBCCR Slider in my latest little project. Made it vertical, and wanted top to be + and bottom to be -. I found your Reversed property, and got all excited ... but it turned out to be all for naught. I've got it all worked out by swapping Min-Max in my head, and then negating my real Min-Max when they go in (and when .Value comes out). But it would have been nice to not have to do that. (Also, I can't turn on the tooltip because it's got the negated number in it.)
And hey, VBClassic, I'll apologize in advance for hijacking your thread a bit. I just wasn't sure this was worth a whole new thread, or more noise in the main VBCCR thread.
----
Y'all Take Care,
Elroy
Last edited by Elroy; Feb 12th, 2020 at 08:21 PM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Re: Common Controls Replacement Individual Controls
Hmmmmmm, yes Elroy but no. Unfortunately, it is the differences that need to be documented and as theMMan mentioned, he already has a several-page document already for the controls.
As I stated earlier we have the original MS documentation so we aren't proposing to redo that - but regardless, it should be quite clear as to the need for it.
In truth those that try not to do documentation (ahem) aren't necessarily those that should be determining the worth of doing it.
If something is worth doing well then it is worth doing some documentation (if not a lot). Those few things that I discovered above, those differences stated in my notes could easily have been answered in a bit of documentation and if it had been, it would have saved me quite a lot of time that I could have used for doing better things, some documentation perhaps?
Re: Common Controls Replacement Individual Controls
Originally Posted by Elroy
Anyway, hey Krool, I actually DO have one (if you happen to get over this way). I've included the VBCCR Slider in my latest little project. Made it vertical, and wanted top to be + and bottom to be -. I found your Reversed property, and got all excited ... but it turned out to be all for naught. I've got it all worked out by swapping Min-Max in my head, and then negating my real Min-Max when they go in (and when .Value comes out). But it would have been nice to not have to do that. (Also, I can't turn on the tooltip because it's got the negated number in it.)
You can turn on the tooltip and displaying the negated numbers as positive by handling the ModifyTipText event .
Code:
Private Sub Slider1_ModifyTipText(Text As String)
Text = Abs(Text)
End Sub
And the Reversed property description says: "Returns/sets a value that determines whether or not to reverse the default, making down equal left and up equal right on horizontal orientation and left equal down and right equal up on vertical orientation"
So the Reversed property is only reversing the arrow keys input handling.
Re: Common Controls Replacement Individual Controls
Originally Posted by Krool
You can turn on the tooltip and displaying the negated numbers as positive by handling the ModifyTipText event .
Thanks Krool. That worked perfectly, with a bit if head-scratching negating of things.
And VBClassic04, I apologize again for hijacking the thread.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.