[RESOLVED] Identifying unwanted Control References to remove/delete from Component References…

[swambast]

Hi Everyone,

Shaking off the dust and getting back into some coding…but ran into an issue I need some help with, please!

Somehow I have duplicate controls added to my toolbar. The issue is somehow I added in the Microsoft Windows Common Controls 5.0 (SP2). I only wanted to use the Microsoft Windows Common Controls 6.0 (SP6). Of course, when I go to remove the Microsoft Windows Common Controls 5.0 (SP2) from the components list, I get the expected “Can't remove control or reference, in use”

So the question is – how can I determine WHERE in the project I am using a Microsoft Windows Common Controls 5.0 (SP2)? So that I can remove all those 5.0 controls, and ultimately remove the entire component reference.

Thanks for your insight!


Re:

[Tech99]

Look and compare GUID's in form (.frm) files to .VBP project file references.

[swambast]

Tech, thank you for your reply. Here is what I've come up with, the issue is I don't understand how to interpret the results! For example, how does one decipher the version translations (e.g., the #1.2#0, #2.0#0, #2.2#0, etc. to Common Controls version x.x)? Also in this case, they the controls on the form GUID and Object references appear to match based on my understanding. Any other insight or suggestions welcomed and appreciated!

From one example FORM:
Object = "{3B7C8863-D78F-101B-B9B5-04021C009402}#1.2#0"; "RICHTX32.OCX"
Object = "{0D452EE1-E08F-101A-852E-02608C4D0BB4}#2.0#0"; "FM20.DLL"
Object = "{F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0"; "COMDLG32.OCX"
Object = "{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.2#0"; "MSCOMCTL.OCX"

From actual .VBP:
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\..\Windows\SysWOW64\stdole2.tlb#OLE Automation
Reference=*\G{420B2830-E718-11CF-893D-00A0C9054228}#1.0#0#..\..\..\..\Windows\SysWOW64\scrrun.dll#Microsoft Scripting Runtime
Object={3B7C8863-D78F-101B-B9B5-04021C009402}#1.2#0; RICHTX32.OCX
Object={0D452EE1-E08F-101A-852E-02608C4D0BB4}#2.0#0; FM20.DLL
Object={F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0; COMDLG32.OCX
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.2#0; MSCOMCTL.OCX
Object={6B7E6392-850A-101B-AFC0-4210102A8DA7}#1.4#0; comctl32.ocx

[Arnoutdv]

All the duplicate standard controls come from the Microsoft Forms 2.0 Controls, FM20.dll

But you are not allowed to redistribute this file:

The Fm20.dll is NOT redistributable. You must have an application such as Microsoft Office 97 on the target system that installs Fm20.dll as part of its setup. (Fm20.dll is included with the OSR2 and OSR2.5 releases of Windows 95.) You can also find this file on the Visual Basic 5.0 CD under the \TOOLS\DataTool\Datatool\Msdesign folder. This will be installed only if you run the setup for the Visual Database Tools. In any case, you may not distribute the Fm20.dll as part of your setup, even if you purchase the Microsoft Office Developer Edition product.

As an alternative to having your end users install Microsoft Office, you can have them freely download and install the Microsoft ActiveX Control Pad, which also installs the Fm20.dll. For more information, see the following Microsoft Developer Network (MSDN) Web site:
http://msdn.microsoft.com/en-us/library/ms968493.aspx

NOTE: The use of these Microsoft Forms components in your own compiled applications, such as those written with Microsoft Visual C++ and Microsoft Visual Basic, is not recommended or supported. These controls were designed and tested to work exclusively within Microsoft Office and its Visual Basic for Applications environment.

https://support.microsoft.com/en-us/kb/224305

[swambast]

Ugh, that sucks...MS Forms 2.0...Wow! I can't even recall how the heck I ended up using that, and certainly not what I want to use going forward. Thanks for the insight Arnoutdv. Now the next logical question is: how can I simply, and hopefully easily, replace all the FM20 controls with the more appropriate Microsoft Windows Common Controls 6.0 (SP6)? Is there a way to simply "find and replace" the text reference in the form/vbp files with something else (not sure what that would be!)? Thoughts?

[gibra]

Look and compare GUID's in form (.frm) files to .VBP project file references.

Doesn't need.

The FRM file contains only then Objects (not References) which is use in the form.
This is because when you add the form to a different project, then the Objects used by the form will loaded in the project, is missing.

[gibra]

Ugh, that sucks...MS Forms 2.0...Wow! I can't even recall how the heck I ended up using that, and certainly not what I want to use going forward. Thanks for the insight Arnoutdv. Now the next logical question is: how can I simply, and hopefully easily, replace all the FM20 controls with the more appropriate Microsoft Windows Common Controls 6.0 (SP6)? Is there a way to simply "find and replace" the text reference in the form/vbp files with something else (not sure what that would be!)? Thoughts?

Before to remove/replace any control in form, be sure that the control is really used.

in Components window:
1) chek the Seleted items only checkbox
2) try to uncheck the Component
--- A) If the component isn't used, then no problem (the component will unchecked)
--- B) If the component is used, then you need to search what FORM use it.

B) make a search fro file which contains the component , i.e. for FM20.DLL search for:

Object = "{0D452EE1-E08F-101A-852E-02608C4D0BB4}#2.0#0"; "FM20.DLL"

To replace with standard control:
1) delete e recreate the control in Form (easy way)
or
2) open FRM file using Notepad and replace all the entries (complicated way)

[Tech99]

Doesn't need.

I think, it indeed does. Without looking .frm file, one does not know in which form has which component objects used.

[gibra]

I think, it indeed does. Without looking .frm file, one does not know in which form has which component objects used.

Yes. I know.
But doesn't need to compare FRM with VBP, because the references are the same.
- VBP contains ALL Objects/References of each forms.


Instead needs to search in FRM for used Objects/References.

[swambast]

Thanks for all the feedback. I found the two problem forms that reference Object = "{0D452EE1-E08F-101A-852E-02608C4D0BB4}#2.0#0"; "FM20.DLL" . However, those forms naturally are the absolute most complex - they have a LOT of controls on them. So on that note, don't think it's practical to delete and re-create the controls. Besides, how would you even know which ones to look for...? Perhaps someone knows an easy way to do that which would be interesting in itself.

But if not, then I'd like to simply replace the entries in the .frm itself. Question is, replace with what? Would it be Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.2#0; MSCOMCTL.OCX that equates to the Microsoft Windows Common Controls 6.0 (SP6)?

[Tech99]

Yes. I know.
But doesn't need to compare FRM with VBP, because the references are the same.
- VBP contains ALL Objects/References of each forms.


Instead needs to search in FRM for used Objects/References.

I should have been more specific. What i meant and mean by looking project .vbp file is, that is it most convenient place to look what GUID value actually is fex. in 5.0 version and 6.0 respectively. You do not 'know' that, without looking project file.

6.0 SP6 -> MSCOMCTL.OCX
5.0 SP2 -> COMCTL32.OCX
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.2#0; MSCOMCTL.OCX
Object={6B7E6392-850A-101B-AFC0-4210102A8DA7}#1.4#0; comctl32.ocx

[Elroy]

Hi swambast,

I'm on a consulting gig so I don't have time to explore on my end much, but I've had similar problems/issues several times in the past. And I thought I'd share some of my knowledge.

First, the GUID/UUID references in the .FRM files aren't needed. They should all be duplicated in the .VBP file. In other words, you should be able to open each/all of your .FRM files and simply delete the reference lines with no harm done.

Now, you've still got the problem of controls in your .FRM files that you wish were other controls. Of course, you can just delete-and-re-add them while developing in the IDE. However, I'm assuming you'd rather not do that.

The only other approach is to open these .FRM files with notepad (or some other ASCII-type editor, such as NP++) and edit them directly. You'll see lines that look something like the following...

   Begin MSComctlLib.Slider Slider1

That "MSComctlLib.Slider" is what you're after. That identifies the control as well as an identifier associated with the .OCX it came out of. (The "Slider1" is just your name for the control and probably shouldn't be changed.) If you know this information about both the old control (you wish to get rid of) and the new control (you wish to replace it with), you can just do these replacements in Notepad.

Where I've typically done this is with user-defined-controls where I want to replace a standard control with one I developed. However, it can also be done with any controls.

The main thing you need to watch out for is to make sure your new control has (at least) all the properties of the old control. If there are properties on the old control that don't exist on the new control, you'll want to delete any reference of them while editing the .FRM file. This'll make sense when you're looking at the .FRM file in Notepad.

As always, make a backup of your source code before starting this.

Just as an FYI, that "MSComctlLib.Slider" type statement is the only thing that tells VB6 what control you wish to be using (other than that linking back to a GUID/UUID reference found either in the top of the .FRM file or in the .VBP file).

Best Of Luck,
Elroy

EDIT1: Also, once you've removed all use of a particular .OCX (and its associated controls), you should be able to un-check the .OCX reference under Project/Components. And you should absolutely un-check all references not being used. If it won't uncheck, you're still using it somewhere.

EDIT2: I'd recommend not deleting any UUID/GUID lines from the actual .VBP file with Notepad. It's much better to fire up the project in the IDE and remove these by unchecking the references under Project/Components. (However, as stated above, it's fine to delete these UUID/GUID references from the .FRM files with Notepad.)

EDIT3: Be sure to close down the IDE with your project before editing with Notepad (and vice-versa), or you'll lose track of which copy of .FRM files you have loaded.

[swambast]

Thanks to everyone who replied, but especially to Elroy for taking time out to pop in and share your experience. It was extremely valuable and helped me solve my issue! After I found the two forms that were using FM20.DLL components, I checked the .frm files (via a text editor) that were using this. I was having trouble figuring out what to look for within the .frm files that would translate into the FRM20.dll. And then it hit me as I started thinking through this; I made a logical search and behold the offending entry was “MSFORMS”. Once I had that info, it was easy enough to find the problems (such as MSFORMS.FRAME framStatus). I then played it the safe way, and deleted those controls off the forms and replaced. This allowed me to finally remove the component and solved the problem!