dcsimg
Results 1 to 12 of 12

Thread: Krools Common Controls - Documentation and an Update/Compile Utility

  1. #1

    Thread Starter
    Lively Member
    Join Date
    Feb 2015
    Location
    Colorado USA
    Posts
    102

    Krools Common Controls - Documentation and an Update/Compile Utility

    Krool has been developing a set of common controls replacements for the past 6 years. I use them all the time and have found them to be an indispensable part of my VB6 programming library. I have developed some tools to make use of these controls easier which is the basis of this thread. There are 3 major items I cover:

    A user guide. I stumbled through usage of these controls for quite some time and decided to share what I have learned with the community. This is not how to use each control; the controls are fairly similar to those we have been using for years. Rather, I cover
    o There are 4 sets of controls. First, there are all of the controls in one package except for the FlexGrid control and it is in a different package. Then, for each of those there is a pre-compiled version (the OCX versions) and the source code you embed in your code versions Krool calls the StdEXE versions. Where are they, which ones should I use, how do I update them, etc.?
    o What are the pros and cons of using the OCX versions versus the StdEXE versions? Is there some way to take advantage of the best features of each?
    o What type libraries are required and in which versions of the controls?
    o What are visual styles (themes) and how do I use them with Kroolís controls so my programs donít have that Windows 95 look to them? These require manifest files embedded into resource files embedded into your programs. This sounds intimidating but once you see whatís required itís not that difficult.
    o What is ďside-by-sideĒ and can I use it with Kroolís controls? If so, how?
    An update utility. I develop with the OCX versions of the controls which have progressed over time from version 1.0 in 2012 to the present version 1.6 (just to complicate matters the FlexGrid controls have gone from 1.0 to 1.2). To change from 1.6.12 to 1.6.13 is not too difficult but to go from 1.5 to 1.6 is not trivial. I have a utility that (hopefully) makes that a trivial exercise.
    A compilation utility. I like to develop with the OCX version of the controls because there is one file to manage instead of 153, I donít have to worry about type libraries and compilations times are at least 10 times faster. However, I like the StdEXE version in my final programs that I distribute because everything is in one executable file, I donít have to be concerned with side-by-side and I donít have to distribute anything to my users except that one executable file.

    The update and compilation utilities are in the same program, the code for which is at the end of this post. Many of the modules in the utility are from my personal libraries and I think you may find some useful in other programs. I do have user guides for almost all of them if you are interested.

    The user guide for Kroolís controls is a Word file also at the end of this post. If you canít use the Word file please let me know what file format you can use and Iíll get it to you.

    If you donít use Kroolís controls you should really take a look at them. They are far superior to what is built in to VB6 and to any of the controls Microsoft or others have provided over the years for these types of controls.

    This thread will be for the user guide and the utility. If you have questions on the control packages, bug reports, request for new features, etc. please do this in the appropriate thread of Kroolís.
    Attached Files Attached Files

  2. #2
    Hyperactive Member
    Join Date
    Aug 2016
    Posts
    346

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    Quote Originally Posted by MountainMan View Post
    Krool has been developing a set of common controls replacements for the past 6 years. I use them all the time and have found them to be an indispensable part of my VB6 programming library. I have developed some tools to make use of these controls easier which is the basis of this thread. There are 3 major items I cover:

    A user guide. I stumbled through usage of these controls for quite some time and decided to share what I have learned with the community. This is not how to use each control; the controls are fairly similar to those we have been using for years. Rather, I cover
    o There are 4 sets of controls. First, there are all of the controls in one package except for the FlexGrid control and it is in a different package. Then, for each of those there is a pre-compiled version (the OCX versions) and the source code you embed in your code versions Krool calls the StdEXE versions. Where are they, which ones should I use, how do I update them, etc.?
    o What are the pros and cons of using the OCX versions versus the StdEXE versions? Is there some way to take advantage of the best features of each?
    o What type libraries are required and in which versions of the controls?
    o What are visual styles (themes) and how do I use them with Krool’s controls so my programs don’t have that Windows 95 look to them? These require manifest files embedded into resource files embedded into your programs. This sounds intimidating but once you see what’s required it’s not that difficult.
    o What is “side-by-side” and can I use it with Krool’s controls? If so, how?
    An update utility. I develop with the OCX versions of the controls which have progressed over time from version 1.0 in 2012 to the present version 1.6 (just to complicate matters the FlexGrid controls have gone from 1.0 to 1.2). To change from 1.6.12 to 1.6.13 is not too difficult but to go from 1.5 to 1.6 is not trivial. I have a utility that (hopefully) makes that a trivial exercise.
    A compilation utility. I like to develop with the OCX version of the controls because there is one file to manage instead of 153, I don’t have to worry about type libraries and compilations times are at least 10 times faster. However, I like the StdEXE version in my final programs that I distribute because everything is in one executable file, I don’t have to be concerned with side-by-side and I don’t have to distribute anything to my users except that one executable file.

    The update and compilation utilities are in the same program, the code for which is at the end of this post. Many of the modules in the utility are from my personal libraries and I think you may find some useful in other programs. I do have user guides for almost all of them if you are interested.

    The user guide for Krool’s controls is a Word file also at the end of this post. If you can’t use the Word file please let me know what file format you can use and I’ll get it to you.

    If you don’t use Krool’s controls you should really take a look at them. They are far superior to what is built in to VB6 and to any of the controls Microsoft or others have provided over the years for these types of controls.

    This thread will be for the user guide and the utility. If you have questions on the control packages, bug reports, request for new features, etc. please do this in the appropriate thread of Krool’s.
    You are such a very enthusiastic person.Merry Christmas

  3. #3

    Thread Starter
    Lively Member
    Join Date
    Feb 2015
    Location
    Colorado USA
    Posts
    102

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    Nineteen years ago I had a cardiac arrest and I was dead for 10 minutes. That really makes you look at life differently. I realize that a)I am not in control like i thought I was and b)I don't know if i will be on this planet for another nano-second so I'd better make the most out of what I have.

    I have benefited a lot from this forum and this is one way I can give back. My contribution to this is tiny compared to what Krool has done. I hope you find it worthwhile...

  4. #4
    Hyperactive Member
    Join Date
    Aug 2016
    Posts
    346

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    As a business vb enthusiast, I look forward to your more good sharing. Here may be the last forum

  5. #5
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,595

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    Quote Originally Posted by MountainMan View Post
    Nineteen years ago I had a cardiac arrest and I was dead for 10 minutes. That really makes you look at life differently. I realize that a)I am not in control like i thought I was and b)I don't know if i will be on this planet for another nano-second so I'd better make the most out of what I have.

    I have benefited a lot from this forum and this is one way I can give back. My contribution to this is tiny compared to what Krool has done. I hope you find it worthwhile...
    There are a lot of enthusiasts in this forum, including some gentlemen, and Krool is a gentleman. Thank you, MountainMan.
    Last edited by dreammanor; Dec 21st, 2018 at 10:23 PM.

  6. #6
    Junior Member
    Join Date
    Aug 2016
    Posts
    19

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    Hello,
    I have created a script to alternative.
    I had a problem with the module parser with the program of "MountainMan", so, it was easier for me to create a program that does the same as the program OCX2StdEXE


    convert_OCX2StdExe.zip

  7. #7

    Thread Starter
    Lively Member
    Join Date
    Feb 2015
    Location
    Colorado USA
    Posts
    102

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    Duplicate post (grrr...)
    Last edited by MountainMan; Jan 1st, 2019 at 02:41 AM. Reason: Duplicate post

  8. #8

    Thread Starter
    Lively Member
    Join Date
    Feb 2015
    Location
    Colorado USA
    Posts
    102

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    The parser is only used for commandline execution of the utility. I don't do much script but I don't think that the "CommandW" function or "Command$" will work in Linux, at least as you have it written. You don't need this if you were to use the input forms but I also don't know if you can do forms in Linux Bash scripting. If you were to make a text file (default ANSI is fine) with the lines you need to add (such as the location of Krool's Demo files) then you could likely do everything in your script and not need to make a new project file that requires further editing before it can be compiled.

    You have an interesting start. Here are some things I suggest you consider:

    - Right now you only have support for VBCCRxx.OCX. At some point you might want to add support for VBFLXGRD.OCX as well. They really are very similar. I am guessing that by version 1.7 or 1.8 Krool will include VBFLXGRD into the larger common controls packages.

    - You also only have support for v1.6 of VBCCRxx.OCX. At some point there will likely be a 1.7, 1.8 and so on. Rather than assume the code is only for 1.6 you might want to read the project file and determine which version is being used and then adjust accordingly.

    - Starting in line 298 you list out the possible module that need to be added to the project file in order to use the ComCtlsDemo version of the controls. At the very least you should have a path to where they are located or tell the user to locate them and modify the script. It wouldn't seem to hard in any script language to put a reference to each of them in the new project file instead of requiring hand editing later. Also, it would be helpful if you checked the project file to ensure that the end user doesn't already have files with any of these name already in the project.

    - Starting in line 308 you list all of Krool's controls and then ask the user to modify the script to un-comment each one that is in use. After a user has 3 or 4 programs that use different controls, this is likely going to get very confusing and will lead to have a special script for each program. Also you would have to remember which controls you add or delete from the project over time. it is not that difficult to read in the project file and from that get all of the controls used in the project from the various module and forms in the project. I started out doing what you are doing and after a couple of months I drove myself crazy so I have my utility find the used controls.

    - It appears in function Main that you make modifications to the references to modules, forms and classes as well as the individual files containing the controls. After I got comfortable with my code I didn't like the fact that I have all of these XXX_ files scattered across my hard drive so I put in an option to delete them after they are used.

    - You will likely need to modify the project's resource file if it has one. It may or may not have an embedded manifest which may or may not be affected by which version of Krool's controls you use. For example, you may have been using the OCX version of the controls but when you switch to the StdEXE version you almost certainly will want to strip out the side-by-side references for Krool's controls since they are no longer going to be side-by-side but instead included in the executable. This get more complicated by 2 factors: 1) there may be other OCX controls the user has in the project that are not like Krool's and there is no source code version to use so the user may want to use side-by-side for the non-Krool OCX controls but not for Krool's controls. So you would need to cut Krool's references out of the resource file but not any other side-by-side references. That was a real hassle in my program. 2) The manifest extracted from a resource file may or may not be in conventional ANSI lines. It is okay to have one big long line that skips the CrLf's (LaVolpe's utility suggests doing this BTW) so you can't just treat the embedded manifest file like lines of text.

    - I am not a Linux guy but I found it to be nice to be able to shell straight from my utility to start an instance of VB6.exe and compile the new code. It's not that difficult to do (do you use Wine for this?) and the code is in my utility. this keeps everything nice and tidy. The user says he/she wants to have a non-OCX version and she/he gets one.

    Good luck with it. If you have any questions, don't hesitate to ask.

  9. #9
    Junior Member
    Join Date
    Aug 2016
    Posts
    19

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    Quote Originally Posted by MountainMan View Post
    - You also only have support for v1.6 of VBCCRxx.OCX. At some point there will likely be a 1.7, 1.8 and so on. Rather than assume the code is only for 1.6 you might want to read the project file and determine which version is being used and then adjust accordingly.
    Now you can modify the variable VBCCRXX with version you use

    Quote Originally Posted by MountainMan View Post
    - Starting in line 298 you list out the possible module that need to be added to the project file in order to use the ComCtlsDemo version of the controls. At the very least you should have a path to where they are located or tell the user to locate them and modify the script. It wouldn't seem to hard in any script language to put a reference to each of them in the new project file instead of requiring hand editing later. Also, it would be helpful if you checked the project file to ensure that the end user doesn't already have files with any of these name already in the project.
    Now the new script v1.1 scan de *.frm and detect the VBCCR Controls used and add to *.vbp

    Quote Originally Posted by MountainMan View Post
    - Starting in line 308 you list all of Krool's controls and then ask the user to modify the script to un-comment each one that is in use. After a user has 3 or 4 programs that use different controls, this is likely going to get very confusing and will lead to have a special script for each program. Also you would have to remember which controls you add or delete from the project over time. it is not that difficult to read in the project file and from that get all of the controls used in the project from the various module and forms in the project. I started out doing what you are doing and after a couple of months I drove myself crazy so I have my utility find the used controls.
    Is no more necessary. Now modify the Visual Basic Project (XXX_*.vbp)

    Quote Originally Posted by MountainMan View Post
    - It appears in function Main that you make modifications to the references to modules, forms and classes as well as the individual files containing the controls. After I got comfortable with my code I didn't like the fact that I have all of these XXX_ files scattered across my hard drive so I put in an option to delete them after they are used.
    I like this, if you don't like the XXX_* file, you could delete this with cmd.exe /C del XXX_*

    Quote Originally Posted by MountainMan View Post
    - You will likely need to modify the project's resource file if it has one. It may or may not have an embedded manifest which may or may not be affected by which version of Krool's controls you use. For example, you may have been using the OCX version of the controls but when you switch to the StdEXE version you almost certainly will want to strip out the side-by-side references for Krool's controls since they are no longer going to be side-by-side but instead included in the executable. This get more complicated by 2 factors: 1) there may be other OCX controls the user has in the project that are not like Krool's and there is no source code version to use so the user may want to use side-by-side for the non-Krool OCX controls but not for Krool's controls. So you would need to cut Krool's references out of the resource file but not any other side-by-side references. That was a real hassle in my program. 2) The manifest extracted from a resource file may or may not be in conventional ANSI lines. It is okay to have one big long line that skips the CrLf's (LaVolpe's utility suggests doing this BTW) so you can't just treat the embedded manifest file like lines of text.
    The Resource could modify with program Resource Hacker:
    http://www.angusj.com/resourcehacker/

    Quote Originally Posted by MountainMan View Post
    - I am not a Linux guy but I found it to be nice to be able to shell straight from my utility to start an instance of VB6.exe and compile the new code. It's not that difficult to do (do you use Wine for this?) and the code is in my utility. this keeps everything nice and tidy. The user says he/she wants to have a non-OCX version and she/he gets one.
    Now you can exec "convert_ocx2stdexe.bat" and run this mutiple times. This features is enable with variable "CreateBatchWindows=TRUE"


    I'm update the script. v1.3

    convert_OCX2StdExe_1.3.zip
    Last edited by pepegriyo2016; Apr 21st, 2019 at 08:17 PM.

  10. #10

    Thread Starter
    Lively Member
    Join Date
    Feb 2015
    Location
    Colorado USA
    Posts
    102

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    It probably is best at this point for you to make your own thread on what you've done so we don't't get everyone confused.

  11. #11
    Lively Member
    Join Date
    Jul 2016
    Posts
    86

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    Fantastic, MountainMan! Your guide greatly reduces the hurdle of starting to use Krool's CC and explains how to do it properly. Thank you for documenting it!

  12. #12

    Thread Starter
    Lively Member
    Join Date
    Feb 2015
    Location
    Colorado USA
    Posts
    102

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    Thanks. Most of us using VB6 are, shall we say, not newbies in programming or VB6 so it is very easy for each of us to take 20+ years of learning the intricacies of thunks, inline assembly, RtlMoveMemory, manifests, side-by-side, etc. and use them within our projects. Krool's work is brilliant but I found myself having to learn a lot of new things and things I didn't really know well in order to get his package to really work well (and it does!). The farther I got into it the more I thought that surely I can't be the only one stumbling over a lot of these concepts. Initially I started documenting it for myself but then morphed it into the user guide. I am glad you found it worthwhile.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width