Krools Common Controls - Documentation and an Update/Compile Utility

Version 3.5 is available for download at the bottom of this post. The program now handles all versions of VBCCRxx,OCX up through the current v1.8 and it handles all VBFLXGRDxx.OCX versions up through the just-released v1.7.

Krool has been developing a set of common controls replacements since 2012. 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.7 (just to complicate matters the FlexGrid controls have gone from 1.0 to 1.6). 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.

This is version 3.5 of this utility.Attachment 192022

Quote:

---

Originally Posted by MountainMan

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

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...

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

Quote:

---

Originally Posted by MountainMan

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.

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


Attachment 164373

Duplicate post (grrr...)

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.

Quote:

---

Originally Posted by MountainMan

- 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

- 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

- 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

- 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

- 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

- 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.4

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.

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!

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.

MountainMan, I had to replace the #949 line of code in zVBandVBA module. Now it works fine for me:

Code:

---

If Len(OldOCXNameNoExtFlex) Then BS.Replace OldOCXNameNoExtFlex, VB6ProjectName, 1, -1, vbTextCompare

---

The "Replace" method replaced the initial characters in a regular module with the project name from VB6ProjectName variable.

Thanks. I overlooked that. I am getting ready to issue an update that covers the last 2 versions of VBFlexGrid so I will ensure I have this correction included.

MountainMan, how can I use the CommonDialog class? This is a part of OCX too, but the program uses some other logic. I have to manually add the CommonDialog.cls file to the project before using OCX2StdExe. Using the checkbox in "Options" window does not give the desired effect.

Hi, MountainMan!
Please, come back! We need you:)

I've modified the Set_xx_Flex sub. Is it enough to work with FlexGrid 1.4? Now it works fine for me, but...

VB Code:

'Changes in "zMain" module:
'**************************
'Sub Set_xx_Flex()
'=================
'REPLACED:
'
'FROM:
'  MaxOCXVerFlex = 12
'TO  :
   MaxOCXVerFlex = 14
'ADDED:
 
   GUIDxx(14) = "{3E5D9624-07F7-4D22-90F8-1314327F7BAC}"
   Verxx(14) = "1.0"
   NamexxFlex(14) = "VBFLXGRD14.OCX"
   'HKEY_CLASSES_ROOT\VBFLXGRD14.VBFlexGrid\Clsid
   Control_GUIDFlex(1, 14) = "25017520-D6C7-473A-A17B-2DC89C44B84D"
   'HKEY_CLASSES_ROOT\CLSID\{3C1D9D59-7E05-496F-9F49-0ADD34002AE5} = "VBFLXGRD14.PPVBFlexGridGeneral"
   'HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{3C1D9D59-7E05-496F-9F49-0ADD34002AE5} = "VBFLXGRD14.PPVBFlexGridGeneral"
   Control_GUIDFlex(2, 14) = "3C1D9D59-7E05-496F-9F49-0ADD34002AE5"
   'HKEY_CLASSES_ROOT\CLSID\{3EAAE612-84B4-409B-83C1-F68BBF706DD7} = "VBFLXGRD14.PPVBFlexGridStyle"
   'HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{3EAAE612-84B4-409B-83C1-F68BBF706DD7} = "VBFLXGRD14.PPVBFlexGridStyle"
   Control_GUIDFlex(3, 14) = "3EAAE612-84B4-409B-83C1-F68BBF706DD7"
 
   GUIDxx(13) = "{841B9BEC-FA74-433C-8494-E28FE7645254}"
   Verxx(13) = "1.0"
   NamexxFlex(13) = "VBFLXGRD13.OCX"
   'HKEY_CLASSES_ROOT\VBFLXGRD13.VBFlexGrid\Clsid
   Control_GUIDFlex(1, 13) = "9FEF8CF8-A7FE-47D6-9552-7FE3FC33E417"
   'HKEY_CLASSES_ROOT\CLSID\{57BFBDAF-8EF0-4553-A7B2-E69956800719} = "VBFLXGRD13.PPVBFlexGridGeneral"
   'HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{57BFBDAF-8EF0-4553-A7B2-E69956800719} = "VBFLXGRD13.PPVBFlexGridGeneral"
   Control_GUIDFlex(2, 13) = "57BFBDAF-8EF0-4553-A7B2-E69956800719"
   'HKEY_CLASSES_ROOT\CLSID\{5F597B1A-9C13-48C4-9350-95E445E637EE} = "VBFLXGRD13.PPVBFlexGridStyle"
   'HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{5F597B1A-9C13-48C4-9350-95E445E637EE} = "VBFLXGRD13.PPVBFlexGridStyle"
   Control_GUIDFlex(3, 13) = "5F597B1A-9C13-48C4-9350-95E445E637EE

Version 2 of the documentation and the utility has been posted to post #1 at the top of this thread. Let me know if you have any problems with any of it.

Attachment 178063

Guess the riddle and get a prize ...

OK, I give up. What's the riddle?

The riddle is how to make the program work. And four answers at once:

1. Replace vb Code:

For X = 1 To MaxOCXVerCCR ' UBound(mControlsCCR, 1)

with vb Code:

For X = 1 To UBound(mControlsCCR, 1)

2. Replace vb Code:

For X = 1 To MaxOCXVerFlex ' UBound(mControlsFlex, 1)

with vb Code:

For X = 1 To UBound(mControlsFlex, 1)

3. Replace vb Code:

BS.Replace OldOCXNameNoExtCCR, VB6ProjectName, 1, -1, vbTextCompare

with vb Code:

If LenB(OldOCXNameNoExtCCR) Then BS.Replace OldOCXNameNoExtCCR, VB6ProjectName, 1, -1, vbTextCompare

4. Replace vb Code:

BS.Replace OldOCXNameNoExtFlex, VB6ProjectName, 1, -1, vbTextCompare

with vb Code:

If LenB(OldOCXNameNoExtFlex) Then BS.Replace OldOCXNameNoExtFlex, VB6ProjectName, 1, -1, vbTextCompare

That's all! You get a prize!

Thanks for catching the bugs. Your proposed solution is close but doesn't work.

The offending section of code is is the procedure DoCompile from lines 952 to 970. At this point I am replacing the form references to the OCX version of the controls with the ones in the StdEXE versions of both VBCCR and VBFlexGrid to compile the controls into the program. I had caught all of the control names from the OCX version into the string array myControlsDotCCR() for VBCCR and myControlsDotFlex for VBFlexGrid and then I replace them with the equivalent names I had found in the StdEXE version. The problem is that within the past 2 months Krool has added 2 controls to the StdEXE version that are not in the OCX versino fo the controls (VirtualCombo and VListBox in VBCCR). The top value of the loop had been UBound(mControlsCCR) but this value was actually now 2 higher than the UBound of the string array containing the OCX controls so it caused an error. That's why I had commented it out. Unfortunately I had replaced it with the wrong variables. Your proposed fix is to put back the UBound values I had commented out but that won't work. They actually should be the values for LastControl for the VBCCR loop and LastfControl for the VBFlexGrid loop. These are the max values for the number of controls in each of the OCX versions.

So basically the correct solution is to ignore the two new controls Krool added to the StdEXE version. This is not really a problem since the OCX version doesn't contain these so I don't have to replace them. That's why I can go back to using the upper bound of the original count of controls in the OCX files. BTW, I expect both of these controls to be in the OCX version 1.7 but that's not out yet and I'll deal with them then.

So that takes care of the first 2 bugs you highlight. The other 2 I am not sure what you are driving at. You are trying to skip the call to the big string replace function by checking to ensure that the sub-string to be replaced is not a null string. In general I think that's fine but in this case, for replacing OldOCXNameNoExtCCR, the replace call won't be made if the Find function hasn't already found it. Also, I don't think there is a situation where OldOCXNameNoExtCCR can be a blank string anyway. The same arguments are made for OldOCXNameNoExtFlex.

I fixed the first two bugs and have uploaded v2.1 with the corrected code.

1. You have another riddle in the VBP file. The Trick is good.
2. OK, I give up. Let it be so. And thank you for the good program.

I had used The Trick's module which enables multi-line tooltips and it worked fine on my PC. However, the reference in the .vbp file was to a location that exists on my hard drive but not in the upload. I am still learning about putting uploads out there with everything contained in the uploaded zip file. Sorry about that. Version 2.1.1 is now uploaded...

Version 2.3 is at the bottom of post #1. Among several other improvements, the biggest change is that it supports Krool's OCX version 1.7.

Quote:

---

Originally Posted by MountainMan

Version 2.3 is at the bottom of post #1. Among several other improvements, the biggest change is that it supports Krool's OCX version 1.7.

---

Excuse me:
Version 2.3: Compilation cannot be completed when there are custom controls, and an error: File not found
Compiler Results:

File not found:'D:\vbHelperEx\Krool\Test\StdEXE\ctlControl1.ctl'

Version 2.2 can be compiled successfully

Attachment 178515
Attachment 178517

smileyoufucn,

Thanks for catching the bug. I had missed 2 "=" signs. It only affected projects with self-declared USERCONTROLs and PROPERTYPAGEs. Fixed now. your simple project compiles now.

Excuseme

MountainMan

Thank you for your update

Version 2.3.1:Error

if Resources.res file path = APP.Path\Res\Resources.res then

Compiler Results:
1、Error: Resource file 'D:\vbHelperEx\Krool\CompilationTest\CompilationTest-2\StdEXE\Res\Resources.res' in the .vbp file does not exist!
2、Other files referenced by the project (*.dll or *.ocx…For example: the referenced vbRichClient5.dll file) are not copied to the StdEXE path



Attachment 178534

Attachment 178535

Attachment 178533

Attachment 178537

thank you very much!

Hello, MountainMan! Let's improve your documentation a little bit? I don't want to create a new thread for it. There are two files in the attachment:

GetVbDescr.bas
This is a ready to use program (Sub Main) without GUI. It creates an mdb database with descriptions of the control's subs, events, properties, etc. All you need to use it is to set up the sSrcPath constant (path to "Builds" folder) and run it. The program will create a vbccr.mdb database with all the descriptions.

vbccr.pdf
This is a standard Microsoft Access report. You can use it as a help file.

I will improve this program in the future. I want to add a GUI and a translation functionality. So we will be able to automatically translate descriptions within the new versions of controls. I will translate it into Russian.

Attachment 178538

Attachment 178539

smileyoufucn,

For OCX files, if they are registered with Windows and then referenced in the vbp file I dno't copy them since they are still registered with Windows int he original spot. Is the OCX file you are referencing not registered?

Are the DLL files also not registered with Windows as ActiveX controls? If not, are they referenced anywhere in the vbp file or the res file?

For the resource file, I changed the reference to it from a relative path in the original vbp file to the same resource file but in the new resource file in StdEXE it has a new relative reference to the RES file. That way, if things were referenced in the RES fiel they would still be referenced in the same RES file. It looks like you want the sub-folder copied over (\Res in your example). How would I know what to copy from this folder or do you want the whole folder copied? Also are there any references within the RES file in the \Res folder that will now be incorrect in the new copy of the Res folder in the new location?

MountainMan, can you help me with translation of descriptions? Please, look at the screenshot. How could it be so? I have changed (translated) the "Attribute Left.VB_Description" value in the CheckBoxW.ctl file. Then I opened the ComCtlsDemo.vbp project and got two different descriptions of one property.

Attachment 178594

Nouyana,

I think I should defer to Krool on this one since he wrote the controls. Post your message here.

Quote:

---

Originally Posted by MountainMan

Nouyana,

I think I should defer to Krool on this one since he wrote the controls. Post your message here.

---

I was too busy the other day and did not reply in time. I am very sorry!
Thank you MountainMan for your help!

1. The previous OCX and DLL files are indeed not registered, but the manifest file "XXX.EXE.manifest" is used. After the registration is successful, use "OCX2StdExe2.3.1" to compile and it is already normal;
2. The resource file "Recurso.res" contains image files and is placed in a relative path. The compilation fails, "File not found: Recurso.res" (Path ....\StdEXE\Recurso.res Not exist)


[Prompt for compilation failure]
Compiler Results:

File not found:'Recurso.res'
One or more attributes in'D:\vbHelperEx\Src\PNG en ImageList\StdEXE\Proyecto2.vbp' are wrong. Some or all properties are set incorrectly.

Below is the demo file:


Attachment 178688

Attachment 178689

Attachment 178690

Compilation is normal in IDE, an error occurs when compiling with "OCX2StdExe2.3.1"

Compiler Results:

File'D:\vbHelperEx\Src\VBCCR17\Login\StdEXE\frmToolBarTemp.frm' compilation error, line 4: user-defined type is not defined
'ToolBarTest.exe' failed to compile.

Compiler Results:

Loading error. For details, see'D:\vbHelperEx\Src\VBCCR17\Login\StdEXE\ucMyUserControl1.log'
File'D:\vbHelperEx\Src\VBCCR17\Login\StdEXE\frmToolBarTemp.frm' compilation error, line 3: user-defined type is not defined
'ToolBarTest.exe' failed to compile.

Attachment 178737

Quote:

---

Originally Posted by smileyoufucn

Compilation is normal in IDE, an error occurs when compiling with "OCX2StdExe2.3.1"

Compiler Results:

File'D:\vbHelperEx\Src\VBCCR17\Login\StdEXE\frmToolBarTemp.frm' compilation error, line 4: user-defined type is not defined
'ToolBarTest.exe' failed to compile.

Compiler Results:

Loading error. For details, see'D:\vbHelperEx\Src\VBCCR17\Login\StdEXE\ucMyUserControl1.log'
File'D:\vbHelperEx\Src\VBCCR17\Login\StdEXE\frmToolBarTemp.frm' compilation error, line 3: user-defined type is not defined
'ToolBarTest.exe' failed to compile.

---

I apologize for taking so long to reply. I have had some serious medical issues I had to fight through. I have just released an update to this utility which addresses your problem as well as many others. Please see post #1.

You problem was twofold: 1)you defined one of Krool's controls in a .BAS module. I wasn't checking for this and it was compounded by the fact that the control name was defined in a string variable. 2) You used one of Krool's controls inside of your own control. I did not account for that occurrence. Both are fixed. I successfully compiled your attachment with the update.

Dear MountainMan, thank you very much for your help!
Sorry for the late reply! My recent work is very busy and I haven't tested it in time. Today, I took the time to test, and after selecting the required controls, the "ToolBarTest" project was successfully compiled. This is of great help to the projects I developed.


Compiled successfully 1
Attachment 181353

Compiled successfully 2
Attachment 181354

The version number has not been updated：
Attachment 181355

Many thanks!

Thanks, MountainMan for this fantastic tool and docs!
And thanks to Krool for continue maintaining this huge project.

MountainMan, can I ask you please ability to auto-save OCX2StdExe options on exit, like last project selected, VB6 base folder & Base folder of ComCtlsDemo?
I used your tool first time, and I found some things, you may want to improve:
- When VBCR run the first time, it has no registration of "OLEGuids.tlb", and your tool msgbox me a hint "... to use regsvr32", however, AFAIK, it is not applicable for tlb. I used my RegTLib instead. So, that message looks a bit confusing.
- When I select Options => Special => Select "ListView" only. I have a compilation error, because none of additional include files was selected by default. Can you auto-select a minimal required include files (I mean Common.bas, ISubClass.cls e.t.c.) in order to compile the project successfully? Or at least select all of them by default on first tool run.
- When I select only these includes "Common.bas" + "VTableHandle.bas" + "ISubClass.cls" + ListView in special, during compilation, the tool reported me that "project compiled OK", however project is not compiled. No exe. My source project has no code (just ListView control + OCX reference). So, error checking could be improved. BTW, when I un-select other includes, OCX2StdExe correctly displays a error message for me that happened during compilation.

Again, very cool project!
Good health to you!

Alex,

Do you have a file in the folder with my utility named OCX2StdExe.ini? That file holds all of the information you would like to save.

When I decided to use INI files I had to pick where to put the INI file. The simplest place to put the file is in the same folder where your project file is. However, as you know, if you have compiled it and put it into your Program Files set of folders, Windows doesn't let you write to anything there without a UAC elevation. If my utility determines you are running in the IDE it wills save the INI file in your project folder. However, if you are running the compiled program it can either be there or in the Apps folder. Look at the code starting at line 2007 in mVB6Core.bas and you will find a public variable named CompiledUseAppFolder which sets whether the project folder or the Apps folder is used. It is initially left False so by default the EXE file will use the project folder. Did that address your problem or do you think something else is going on?

I'll address your other concerns shortly.

Hi, and thanks for the detailed explanation.
No, I'm using folders with full access for current user.
My issue was: I just overlooked a button "Save & Exit". Now, settings are saved OK.

Quote:

---

Originally Posted by MountainMan

However, if you are running the compiled program it can either be there or in the Apps folder.

---

Well, I decided to test, I just moved OCX2StdExe.ini from OCX2StdExe.exe's folder to my project's folder. Run OCX2StdExe, select my .vbp file, but it doesn't automatically recognize ini file next to vbp.

Also I noticed, when your app ran as non-elevated, KillW => SHFileOperation is failed on my system with code 120 (DE_ACCESSDENIEDSRC, Security settings denied access to the source), when it is used with FOF_ALLOWUNDO (recycle) flag. Normal delete operation is working OK. Possible improvement is an option to delete file instantly (without recycle bin).

Also, when your tool run DoCompile => ShellW, it always pass AdminYes, every time asking me for elevation. Dunno, is it by intention. But, it is not needed for all projects. AsAdmin:=AdminOnlyIfNeeded was enough for me. Surely, it's on your own, do you want to leave it as is, or just maybe add some option in menu, which looks more preferred way as for me.

Also, I tested all command line option combinations, and this one "/s2 /a-" causes error on MCIWnd.ctl, Line 1383 - User-Defined type not defined.

All at all, I absolutely happy with your project, and especially an ability to compile silently.

Just curious, in which kind of projects you used supporting API-wrappers, and did you publish them as a separate framework? They're looks to have a lot of functionality, error checking with textual description, unicode, long path and VBA64 support. I did some similar, but yours looks a really intensive.

I didn't know you could run VB6.EXE, even the commandline version, without elevating. I never tried it (yes, I know all about the word "assume"...).

I probably wasn't clear on the location of the INI file. Absent setting CompiledUseAppsFolder = True, the program looks for the INI file in the same folder as the EXE itself (I said the project file location but that was inaccurate). If you had set CompiledUseAppsFolder was set True then the program looks for the INI file in "C:\Users\{username}\AppData\Local\Ocs2StdExe" which is where we are supposed to put program data in Vista+ instead of "C:Program Files" or "C:Program Files (x86)".

I will check to see what is causing the error with the commandline options.

By training I am a chemical engineer and I have never written commercial software. I have written a fair amount of VBA code in Excel and about 10 years ago I picked up 2 copies of VB6 because it can produce EXE's and is so similar to VBA. I started playing with API calls to deal with Unicode and long paths and then when Office 2010 came out with its 64-bit version that's when I adapted everything to run on 32 or 64-bit via conditional compilation constants. Since I am mainly a hobbyist I can take the time to make libraries and optimize everything. The only code I have ever used from someone else is LaVolpe's manifest code in this program. When I figured out that I needed to address manifests it looked like it was going to take some time and I got in a hurry and his code worked. I've been working off and on for a decade on a pretty sophisticated file manager and I am within a couple of weeks of putting it in the CodeBank. It is as fast as anything on the market and can handle millions of files. There is a VB6 and a VBA version & I think many people will be surprised at how well it works.

Looks promisingly. Looking forward to test your software =)
BTW, I'd suggest to overlook a helper code for missing Wow64RevertWow64FsRedirection, because there are some scenarios, e.g. in ShellW, where it is not paired due to using "goto" statements. It's also good practice to store "OldValue" parameter globally to prevent "out of sync" even if above case happened.
The same actual for all other functions like "File Exist" where I don't see redirector functions at all, which surely have to be implemented in tools like "file manager".

Quote:

---

Originally Posted by MountainMan

I didn't know you could run VB6.EXE, even the commandline version, without elevating.

---

This is a default behaviour after installation. Perhaps, you patched exe file via manifest, or set Admin mark in exe's or shortcut's properties, that's why it is always ask you for elevation.
I don't insist that it should be "must have" feature, since I can always create a special shortcut to bypass UAC, but ability to compile as non-elevated where possible would be good manner. Also, the user should understand he can manually start your tool elevated if he knows his project require higher privileges in order to compile.

When I installed VB6 I set my system to elevate VB6 each time it was run. I did that because everybody I had read (some here) say that because VB6 writes into a section of the registry that isn't accessible any more without elevation. What cases have you found it acceptable to run VB6.EXE without elevation?

Tell me more about helper code. When I use Goto I try to ensure that I don't have any orphaned or "out of sync" variables.If you see any in my code please let me know.

Quote:

---

Originally Posted by MountainMan

When I installed VB6 I set my system to elevate VB6 each time it was run. I did that because everybody I had read (some here) say that because VB6 writes into a section of the registry that isn't accessible any more without elevation. What cases have you found it acceptable to run VB6.EXE without elevation?

---

I'll split answer in 2 use cases:
1) Run IDE.
Personally, I see the only reason when one needs to run IDE non-elevated - to be able debug code in the same (or very close) environment as it will be run further by user to have the opportunity to catch all those possible "access denied" errors and so. Or when you, e.g., develop an application which by design should always be run with restricted permissions to prevent cases, e.g., when you think some function should work normally both as admin / and non-admin, but it is not true (like the above case with SHFileOperation).

In all other "design" cases, VB6 IDE is really suffered from those access denied errors when one try to add new, not yet registered components / references and so on, which write themselves to HKLM and thus required admin access. Such a way, yes, it's much convenient to work always as evelated.

2) Compile.
It's also convenient to compile project as elevated every time.
But it's not always convenient for end user. Like, if one wants to integrate OCX2StdExe into another builder script which by design is not intended to run as admin.
Surely, it's up to you, do a little change to support non-elevated compilation, or stay as is. But if second, than a logical question: why not force "requireAdministrator" instantly in the manifest of your tool...

Quote:

---

Originally Posted by MountainMan

Tell me more about helper code. When I use Goto I try to ensure that I don't have any orphaned or "out of sync" variables.If you see any in my code please let me know.

---

Well, look ShellW function.

Code:

---

j = Wow64DisableWow64FsRedirection(DisableWOW)

---

Firstly, I suggest to declare DisableWOW globally. So, the system can re-use those value when needed (when you'll have more such use cases in your code, of course).
Even, if Wow64RevertWow64FsRedirection pair will be lost, you will not lose tracking of DisableWOW value, used by system for special purposes to sync the redirector state.

Second, you have a lot of labels for "goto", such as Leaving/DoSee0/DoSEE1. E.g., see this part:

Code:

---

            ShellProcInfo.hProcess = 0
            GoTo Leaving
            End If
        AsAdmin = AdminYes
        GoTo RunElevated ' failed to run un-elevated & AsAdmin is AdminOnlyIfNeeded
      Else
        i = Err.LastDllError
        End If
      End If
  End If
'#If (Win64 = 0) Then
' If hModule <> 0 Then FreeLibrary hModule
'#End If
If IsWOW64 Then
  're-enable redirection
  j = Wow64RevertWow64FsRedirection(DisableWOW)
  If j = 0 Then

---

If those goto executed, it jump over Wow64RevertWow64FsRedirection, so the redirector remains disabled.
I didn't learn all the code, just a quick look.

Another potential lose of pair could happen if code trapped runtime error for some reason.

And the last, to make code (faster?/more stable): file system redirector affects only C:\Windows\System32 (with 2 exclusions), so no need to manipulate it for other paths. Simple way is to check just for "C:\Windows"). I'm using such helper routine.
Second reason is such Microsoft does not suggest to disable it for a long time. So, it's very important to track this moment carefully. Some functions from my practice are working incorrectly with redirector turned off (example: WinVerifyTrust).

Quote:

---

Originally Posted by MountainMan

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...

---

First of all, thanks a lot, MountainMan, for being always extremely kind, thankful and humble in your words. And, coming to your greatly useful work which I find many are getting benefited from, I also join them in thanking you sincerely, though I have not started using your work though.

Actually, with our dear Krool's update on 13th Oct, I thought I will start using the OCX version hereafter. So, I needed to do the reverse (StdExe2Ocx) for my situation. So, I searched in the net and found this link - https://dev.xenforo.relay.cool/index...-vbccr.882529/. I saw that you have also replied therein. So, based on the same, few days back, I attempted to do the reverse (StdExe2Ocx) on taking ComCtlsDemo itself as an example.

I just replaced## all the references in the forms (.frm files) from ComCtlsDemo to VBCCR17. Then, edited the .vbp file suitably (added object reference to VBCCR17, removed references to all user control files) and started it. It all worked correctly^^, but still you can add your own invaluable tips in confirming whether this is all that is required (or further more things need to be done). Next, I attempted a similar procedure for converting my own important project which has 50+ forms, many of Krool's controls (incl. vbFlexGrid) and SSTabEx control. It all seems to work perfectly only though I have not individually opened and checked each screen after starting the executable.

(##) Instead of sed, I searched (and searched and searched) and found out an old yet superb freeware ('Replace Text' by Ecobyte [formerly 'BK ReplaceEM' by Bill Klein]). This gem of a freeware has very powerful features. More specifically, it did what I wanted - replace multiple search strings in multiple files - with an ever so easy configuration. The 3-point 'License Agreement' for this software brought heartwarming tears in my eyes. As far as I can remember, I have never seen a 'License Agreement' of such a nature in any freeware. Sure the writer of that license agreement must be a kind soul like you. God Bless him! God Bless you! God Bless all!

(^^) except one line of code - Animation1.LoadRes 100 (which is in the Form_Load event of MainForm), when the executable (ComCtlsDemo.exe) is run. Curious to know why. I tried certain things like deleting and adding the resource file again, etc., but this line of code never worked. I felt like adding the .avi animation demo file to a different .res file, remove the existing .res file, add the new .res file and then see whether the aforesaid line of code works with the ocx version but then I am not familiar with .res files. So, could not afford to spend time on that.

As of now, I did not want to write to Krool on all of the above, since I thought you yourself can definitely help me on this, so that Krool can continue to concentrate on enhancing his controls.

I take this opportunity to once again thank, in tons, our dear Krool, for his stupendous free controls, which are a great boon to the whole world society.

More than anything, I am extremely happy today to have written to a compassionate person like you. God is Great. All Thanks to the Lord Almighty.

Kind Regards.

"Gratitude is a currency that we can mint for ourselves, and spend without fear of bankruptcy." - Fred De Witt Van Amburgh

Quote:

---

Originally Posted by MountainMan

I apologize for taking so long to reply. I have had some serious medical issues I had to fight through. I have just released an update to this utility which addresses your problem as well as many others. Please see post #1. ... .. .

---

I just now read, this message of yours. I, for one, very well know about fighting through serious medical issues, because of my own personal experiences in that front. So, my sincerest prayers, from the very bottom of my heart, for the welfare of a great heart like yours, ever.

By the by, I have had a very quick look into your project and I have to say the ToolTips is awesome. Thanks to you and The Trick. And, the resizing of controls' and texts' sizes, as form is resized, is fabulous. I shall explore more as and when time permits and share with you.

My utmost prayers for the very best of healths to you at all times..... I have just now prayed so to the Lord Almighty.

Kind regards.

As you know, I only wrote the utility to go from the OCX version to the StdEXE version. Te reason I did not go the other way was that I figured the number of developers using the StdEXE version is extremely small, especially since for the last couple of years Krool has said in his first post on the StdEXE version that this version is unstable in the IDE and that he recommended using the OCX version for development. So if you use my utility, you can develop with the OCX version and then do a commandline compile with the StdEXE version to produce an EXE file with no dependencies and without the instability of using the StdEXE version in the IDE.

I think your approach to going the other way is fine but I suggest 2 more things need to be done. First, when you use the OCX version you do not need OLEGuids.tlb since it is effectively already compiled into VBCCRxx.OCX so you can remove it from your project references. It doesn't end up nn the compiled EXE anyway but it helps to remove some confusion to remove it.

Second, if you want to remove the OCX dependency in the final EXE file you will need to get and use the side-by-side manifest from Krool's first post for the OCX version.

Quote:

---

Originally Posted by MountainMan

... .. . since for the last couple of years Krool has said in his first post on the StdEXE version that this version is unstable in the IDE and that he recommended using the OCX version for development. So if you use my utility, you can develop with the OCX version and then do a commandline compile with the StdEXE version to produce an EXE file with no dependencies and without the instability of using the StdEXE version in the IDE.

I think your approach to going the other way is fine but I suggest 2 more things need to be done. First, when you use the OCX version you do not need OLEGuids.tlb since it is effectively already compiled into VBCCRxx.OCX so you can remove it from your project references. It doesn't end up in the compiled EXE anyway but it helps to remove some confusion to remove it.

Second, if you want to remove the OCX dependency in the final EXE file you will need to get and use the side-by-side manifest from Krool's first post for the OCX version.

---

Thanks for that tip on 'OLEGuids.tlb', MountainMain.

By the by, my app has been getting deployed as Std-Exe version only in users' systems so far.

But, for development also, I was forced to use the Std-Exe version itself (though quite unstable) so far because of the long-pending (years long) fix in the RichTextBox control. That's why I wrote that with Krool's recent update (on 13th Oct), I have switched over to using his OCX version for development. Before this fix, I needed to effect my own modifications in the RichTextBox.ctl code, every time krool released an update to VBCCR Std-Exe version.

Well, coming to OCX version, suppose I decide to deploy the OCX version's compiled executable itself hereafter in my users' systems, using the side by side approach (i.e. without registering the ocx in the user's system). Then, kindly let me know the following:

1. My project has to include the “VBCCR16SideBySideAndVisualStyles.res” file (since obviously I want the visual styles too along with side by side) and not the “VBCCR16SideBySide.res” file. Right? I have read the relevant portions of your ReadMe.docx file regarding this and it suggests that only. Anyway, just confirming from you again.

2. For large projects where most or almost all of my forms contain many of krool's controls, since I deploy my ocx version's compiled executable in my user's system,
a. Will there be any reduction in load time of my app?
b. Will there be any reduction in memory usage of my app?
c. Will there be increase in speed of execution of my app's various modules?

3. If your answer to questions "a,b,c" above are 'No", then is there any other advantage at all in deploying the ocx version's executable in my user's systems? If there is absolutely no advantage at all (for sure), then finally, I will convert my project from 'ocx version' to 'std-exe' version (I may use your utility of course) so that I shall continue to deploy the std-exe version itself in my users' systems.

Kind regards.

N.B. Thanks for such a detailed documentation (your 'ReadMe.docx')

softv,

I am not sure why you want to use the OCX version for distribution. The main reason I wrote my utility was so that you could develop with the OCX version and then use my utiliity to make an EXE based on the StdEXE version. That way you have only the VBCCR controls you actually use included in the EXE and there is no requirement to use the OCX at all with the EXE file that is made (also means you don't need to do the side-by-side stuff with the EXE.

If you have the side-by-side stuff included in a manifest, it is temporarily removed when the EXE is made so that the SXS is not in the final EXE.

Unless I am missing something, this seems like a much better solution for you. You will always develop with he much more stable OCX version and be able to make the StdEXE version whenever you want and as often as you want (my utility leaves your OCX version alone).

Quote:

---

Originally Posted by MountainMan

softv,

I am not sure why you want to use the OCX version for distribution. The main reason I wrote my utility was so that you could develop with the OCX version and then use my utiliity to make an EXE based on the StdEXE version. That way you have only the VBCCR controls you actually use included in the EXE and there is no requirement to use the OCX at all with the EXE file that is made (also means you don't need to do the side-by-side stuff with the EXE.

If you have the side-by-side stuff included in a manifest, it is temporarily removed when the EXE is made so that the SXS is not in the final EXE.

Unless I am missing something, this seems like a much better solution for you. You will always develop with he much more stable OCX version and be able to make the StdEXE version whenever you want and as often as you want (my utility leaves your OCX version alone).

---

// I am not sure why you want to use the OCX version for distribution. //
Sorry. I did not mean to say that I am going to use the OCX version for distribution. As written already, I just wanted to know that if at all myself/anybody decides to use the ocx version, are there any advantages at all in doing so? I just wished to know the answers to my 3 questions (a, b, c) as below. That's all. Nothing else.

For large projects where most or almost all of my forms contain many of krool's controls, if at all I/anyone decides to deploy the ocx version's compiled executable in user's system,
a. Will there be any reduction in load time of such an app?
b. Will there be any reduction in memory usage of such an app?
c. Will there be increase in speed of execution of such an app's various modules?

Hope I have made myself clear now. Thanks.


Kind regards.

I do not believe that an EXE made with the OCX version will load faster, reduce memory consumption or increase execution speed versus running an EXE that has been made with the StdEXE version. The advantage I see for the OCX version is stability in the IDE.

Load time with the StdEXE version should be a bit less since not all controls will necessarily be in the EXE and on today's PC's the StdEXE version is only loading one file instead of 2. On today's PC's though, I don't think the load times will be very noticeable.

OCX will have a bit higher memory consumption since it has all the code and variables for all of the controls instead of just ones you are using in your EXE. This is likely a few MB which also is not a big deal on modern PC's.

Since the OCX and EXE have the same code for the controls and they are both compiled I would anticipate execution speed to be the same except possibly for a slight difference in initialization.

So I only use the OCX version for development due to its stability and then I use the StdEXE for production code.

Quote:

---

Originally Posted by MountainMan

I do not believe that an EXE made with the OCX version will load faster, reduce memory consumption or increase execution speed versus running an EXE that has been made with the StdEXE version. The advantage I see for the OCX version is stability in the IDE.

Load time with the StdEXE version should be a bit less since not all controls will necessarily be in the EXE and on today's PC's the StdEXE version is only loading one file instead of 2. On today's PC's though, I don't think the load times will be very noticeable.

OCX will have a bit higher memory consumption since it has all the code and variables for all of the controls instead of just ones you are using in your EXE. This is likely a few MB which also is not a big deal on modern PC's.

Since the OCX and EXE have the same code for the controls and they are both compiled I would anticipate execution speed to be the same except possibly for a slight difference in initialization.

So I only use the OCX version for development due to its stability and then I use the StdEXE for production code.

---

Thanks a TON, MountainMain, for your immediate reply with clear-cut answers. Thank you so much.

Kind regards.

hi MountainMan, after researching I found your idea of using the tool is the best, but I have the following problem, please help:
- I copied VBCCR17.OCX to syswow64 (my computer win 10 64bit), I have registered regsvr32 successfully.
- But when I run the project OCX2StdExe the error message "there are no VBCCRxx.OCX or VBFLXGDxx.OCX files on this PC!"
Attachment 182970 Attachment 182971

minhtungph,

I think I have found the problem. Until 25 Oct, there had been only one version of each of Krool's OCX controls (one for 1.7, 1 for 1.6 etc.) and my utility only looked for the one version (1.0) of VBCCR17.OCX. As of Krool's version 1.7.32 the .OCX file is now 1.1 and is registered as such. I will have to modify my code to allow for versions 1.0 and 1.1 of VBCCR17.OCX. I might be able to get to it this weekend.

@MountainMan!
thank you for all you do for the vb6 community, i will wait for your new tool, good luck

Version 3.1 has been released (see post #1). It now handles the changes to the VBCCROCX17 package released on 25 Oct 2021 (and all later versions).

Version 3.2 is available for download at the bottom of post #1 in this thread. It now is able to handle the newest version of VBFLXGRDxx.OCX (v1.5). As before, it handles all of the VBCCRxx.OCX versions up through the present v1.7.

Hello！

Attachment 183371

Attachment 183372

Attachment 183373

Compiler Results:

file not found: '..\ToolRes.RES'
'C:\ActiveXs\Krool\Krool\Zip\ToolBarTest\StdEXE\ToolBarTest.vbp' One or more of the attributes are incorrect. Some or all properties are set incorrectly。

sileyoufu,

I had an error of deleting the .RES file if it didn't contain a manifest. Since one of the main reasons for using Krool's controls is to get theming, it is not normal for the resource file to not contain a manifest. At any rate I really meant to just skip over the manifest-less .RES file but I had a line in there to delete it. That's fixed and I added some additional error handling stuff. See the attachments at the bottom of post #1.

Also, this is similar to a test program from last year where you were referencing one of Krool's controls with a variable in your code (the Load procedure of form frmToolBarTemp.frm). If you remember, the last time you did this I advised that it would be very difficult for me to track variables in your code to figure out which control you were using so I put the Special form that you get to from the Options form for the compiler. In your case, check the Toolbar control so it will be forced to be added.

Let me know how the new version works.

MountainMan:
Thank you very much for your reply and help:
1. In the development of the project, in addition to the two types of controls (source code), VBCCR and VBFLXGRD, other files without source code may be used, such as: RC6.dll, RC6Widgets.dll, gregn6.dll (Grid ++Report 6http://www.rubylong.cn/), Png file, Svg file, manifest file...
2. I want to put all of the above in the Res file. After compilation, it is an independent exe file. When the project is released, only an exe file needs to be released to the user. When the EXE file is running, C6.dll and RC6Widgets.dll are automatically released. gregn6.dll to the local current folder (Using OCX Files with SxS Technologyhttps://www.vbforums.com/showthread....=1#post5212143)
3.At any rate I really meant to just skip over the manifest-less .RES file-------whether it can be used as an option, it is up to the user to decide whether to delete or keep the RES file as it is
4. The Google translation used in the above content, if there is any unclear expression, please forgive me!
thank you for your help!

OK, so now you've got me puzzled. In order to take advantage pf themes and modern-looking forms and controls, you have to specify using Comctl32.dll v6 and as far as I know, with VB6 you either have to have an appropriate external manifest (discouraged in recent years) or essentially have that manifest information included in a resource file. You don't have a manifest file nor does your resource file have the right XML to specify Comctl32.dll v6. Yet you are wanting to use at least some of Krool's controls and although they can sort of be used without activating visual styles (through Comctl32.dll v6) the controls look and behave better if they do. Since you already have a resource file why not use LaVolpe's Manifest Cr5eatr II on this site to embed a simple manifest into your resource file so you can get the benefits of the newer controls?

I would use Google translate to put this into your language but I don't know what that is...:)