MSFlexGrid: The subject is not trusted for the specified action 9

[ettienne]

When I add an MSFlexGrid to a VBA form I get an error message: The subject is not trusted for the specified action.

This has worked perfectly before and now a lot of customers are reporting the same error, so I suspect a Microsoft updated has something to do with it.

 

[ettienne]

I have VB6, my clients do not.
Heck I cannot believe MS ****ed something so simple. This is VBA we are talking about, used in MS Office and other applications.

 

[FossilFool]

What should be the version of VB6? I downloaded and installed the update from the link "

http://support.microsoft.com/kb/957924/en-us"

(thanks Hugh),
but don't see any change in my version # from the Help/About menu. I have SP6 (expected SP6B?), the version is 9782, is this the most updated version? Thanks.

 

[ettienne]

It is not a VB6 update per se...

 

[HughLerwill]

>I have VB6, my clients do not.

So you can help them! Your app has been running for ages, they have been happy for ages, the MS update is to blame (they gave no warning to VBAers using (maybe unlicensed) VB6 Controls). Think positively, albiet it was your fault to use (maybe unlicenced in design environment) VB6 Controls on an Excel UserForm in the first place and/ or to assume the control was installed on the target system when that was not guaranteed.

Create a dummy vb6 project consisting of a single form containing one of all the updated controls you want your clients to have. Make an install package. Test it. Test it. Zip it. Put it in a new folder on your website. Test it. Email all your users with a link to the download address and install instructions. That should install all the new .ocxs as required for the client. It's work but it's work.

 

[HughLerwill]

Fossil - if you want to check that 'kb957924' has taken Explore Windows\System32 and search for ms*.ocx; the files of interest should have version numbers like 6.1.98.13 or 6.1.98.12

 

[ettienne]

Uninstall Microsoft KB960715 solves the problem for clients for now. This is simpler than getting them to download and copy a new OCX and unregsiter and register and all that kind of stuff.

 

[FossilFool]

Hugh, my msflxgrd.ocx is 6.1.98.12. I unregistered it and reregistered it with regsvr32.exe. Then my VBA app failed to run, even though it ran earlier today.

I found that KB906715 was back on my PC again, so I uninstalled it. The app still didn't run! So I deleted all of the EXD files per ettienne's suggestion (del c:\*.exd /s), and the VBA app finally ran.

So I wonder if passing this OCX to my users, properly registered, will allow my VBA app to work if they don't remove KB960715 and delete the exd files?

Is it unethical or even illegal to use msflxgrd.ocx in an application that uses VBA, and that I sell to others? It's certainly not in a VB program, of course. You seemed to imply this, and if true I may need to make adjustments!

Thanks for your help, Hugh and ettienne!

 

[HughLerwill]

Fossil - Now that you have msflxgrd.ocx v6.1.98.12 installed/ registered and have deleted the EXD files I would expect your app to run (for you) with the KB906715 update.
My comments re licencing are just CMA. If you have a licence to use VB6 you have a licence to redistribute/ use the controls in your software. Non VB6ers may like to assume that the controls are in the public domain but I suspect that is probably not the case.

>So I wonder...?
Yes. I suspect (re)registering the control is unecessary, as long as the new version is installed over the old registered version. Consider that copying the file, typically to Windows\System32 is going to require admin rights.

 

[HughLerwill]

If you have no friends using vb6 thread707-1531389

 

[FossilFool]

Hugh, you're right! I installed KB960715 (note that we called it KB906715 a few times above...), and my VBA app runs now.

I suppose it will be cumbersome getting my users set up right, but new installations should be trouble free...

thanks much!

 

[FossilFool]

Not out of the woods yet. Updating MSFlxGrd.ocx on my development computers works in XP & Vista, but not on my end users' machines.

I've created an installation of a VB app that uses MSFlxGrd.ocx and installed it on the destination PC. Then I run my application (AutoCAD) that uses MSFlxGrd.ocx in a VBA module. The user gets warnings that he doesn't have the licensing requirements, and the VBA part of the program will not run.

Exact message: Microsoft Visual Basic - License information for this component not found. you do ont have an appropriate license to use this functionalitiy in the design environment.

Any thoughts on how to get around this? Do I have to buy a VBA license for my users to use MSFlexGrid?

Thanks in advance for any suggestions.

 

[Devuser2]

@ FossilFool
I've had the same problem with my installation. There is a bug with these controls (e.g. see

http://support.microsoft.com/kb/318597/en-us).

In fact, it is not sufficient to copy the new control to System32 and register it; IMHO this provokes the license issue.

You must unregister the *old* control first (regsvr32 /u ), then copy the new one and register it.

I haven't finished my tests with the new installer in a Virtual Machine, but I hope this will fix it.

Regards
DevUser

 

[FossilFool]

DevUser,

Thanks for your help. I had already copied & registered the newer version of MSFlxGrd.ocx onto my destination computer. I unregistered it, put back the old version, registered it, then unregistered it, copied the new version, registered it, but still get the licensing error. Perhaps unregistering the old grid in the very beginning would have prevented this problem, but too late now.

I'm in a real pickle here, have a customer who paid good money for my app but is dead in the water now. I've got to do whatever it takes to get this problem solved. Any thoughts?

Thanks again.

 

[Devuser2]

Update on my post.

I've tried the installation as Fossilfool proposed it:
- Unregister the old MSHFLXGD.OCX using regsvr32 /u <Path>
- copy the new control from the VB6 update msi to system32
- re-register it using regsvre32 <path>

Result: My Word/VBA solution shows "compilation error" on the production machine. On my development machine with VB6 SP6 installed, all works well.
If I try in the VBa editor window on the production machine to put the MSHFLXGD.OCX to the form, I get the message that the control is not correctly licensed.

Tried the following approaches:
- Unregister, reinstall and register other controls from the update package. No progress.
- Execute VB6CONTROLS.REG with the license keys provided on the Visual Studio 2003 CD (see link to support.microsoft.com in my post above). No progress.

Solution
- Looked into VB6Controls.reg: it contains the hive [HKEY_CLASSES_ROOT\Licenses] with a lot of GUIDs.
The comments in the Reg file show, that the license keys map to the standard controls, as Common Dialog etc. However, the MSHFLXGD.OCX is not referenced.

No way to map these GUIDs to the GUIDs of the VB6 controls.

- Exported the hive on my developer machine and on the production machine. Compared them. Found a set of entries which were missing in the production machine. Copied these entries into a reg file, imported it on the production machine.

Problem solved.
However: quel merde!

 

[Devuser2]

Update 2
Please understand that I cannot post the VB6Controls.reg here, or the reg file I've created.
I may offence the license restrictions of MS. May be this file is downloadable directly by Microsoft.

Regards
DevUser

 

[PHV]

The proper syntax is: quel[!]le[/!] merde <grin>

 

[FossilFool]

DevUser, you said:

"- Exported the hive on my developer machine and on the production machine. Compared them. Found a set of entries which were missing in the production machine. Copied these entries into a reg file, imported it on the production machine."

Can you elaborate on how to do this? I'm unfamiliar with a "hive", and exporting it. I think there is little chance that I could get my end users to do this. Surely there must be a simpler solution?

I'm facing the possibility of removing MSFlxGrd from my app and using a 3rd party control, but licensing in VBA may still be an issue. Jeez, this really sucks.

thanks again.

 

[Devuser2]

To export a registry branch do the following.

(1) It is important that you are logged in with administrative rights.
(2) On the command prompt, start REGEDT32.
(3) Select HKEY_CLASSES_ROOT\Licenses, and right-click.
(4) Choose "Export" (pay attention that the option "Selected branch" is checked) and enter an appropriate filename.

Do this on both machines. To compare the files, you can use any file comparison tool. I'm using the built-in file compare of Total Commander (Shareware).
Of course you may also just import the DEVELOPER export reg file as it is to the production machine; I've preferred to import only the differences. It suffice to double-click the file (with adminstrative rights) to import it; or you may use regedit with a silent switch.
If you deliver the new files with an installer, you can add the reg file; depending on the tool you're using.

Regards

 

[FossilFool]

I'm concerned that messing with the registry is beyond my confidence level, especially when the customers' registry files are affected.

Does anybody know of a grid control that works in VBA that won't have these licensing issues?

Thanks for you help, DevUser!

 

[FossilFool]

I looked pretty hard for a replacement for FlexGrid, and nothing worked satisfactorily in VBA until I ran across TList8, by Bennet-Tec. This is a multi-talented list/grid control that is very rich in features, perhaps more than you need if you were happy enough with FlexGrid, but it works great in VB standalone apps and VBA. I've distributed it to several computers now with no issues. Compared to the free FlexGrid, it's pricy, but it is powerful and the support is unbeatable.

Find them at

http://www.bennet-tec.com/

and see their other packages. They've been around for many years and are trustworthy. I am not affiliated with this company, just a happy customer.