Problem with the DBGrid32.ocx from 2010 2

[CP60]

I have been using and installing on customer machines the DBGrid32.ocx from 1999 v. 5.1.81.4

There was a security update in 2012 for several VB6 components, which could be downloaded and installed.

I found out that there seems to be a bug in this DBGrid32.ocx from 2010 v. 5.1.98.13, which causes an error 3265 when referencing the column by it's field name rather than an index:

DBGrid1.Columns.Item("SomeField").Value​

I always reference the column by the field name, so that if the query/table field order changes, all the references do not need to be changed.

The program has worked fine fpr years on hundreds of customers machines, because I always install the older version.

One of our newer customers uses GeoMedia, and this application also uses the DBGrid32.ocx. But the developers of GeoMedia have obviously downloaded the security package and distribute the newer Ocx - then my program stops working properly.

When the customer manually removes the newer ocx (de-register) and replaces it with the older one, all programs work fine again.
And, the customer should be required to do this, and is complaing about it.

GeoMedia confirmed their program will work with the older ocx, but rightfully says that they are using the newest version of the ocx.
However, that would be the case, if there was a further update of the ocx coming, which isn't the case. MS will evidently not be fixing this.
(There were similar problems with other ocxs, like the mscomctl.ocx, which MS did give a correction for.)

So, does anyone have an idea how to best handle a situation like this?
Maybe the older ocx could just be installed isolated?

Thank you for any help!


So, does anyone maybe have an idea how

 

[dilettante]

No compile-time fiddling is going to do anything about this situation because class ID values did not change between the older and newer versions of the library.

However, when he copies the Application exe, manifest, and DEP folder containig the older OCX into a different, from non-protected folder such as C:\MyApp\, it works.

Any ideas what could be causing this?

From the description "from non-protected folder such as C:\MyApp\, it works" you almost certainly have a filesystem virtualization issue caused by copying files around. Or else...

There is also the issue of "Activation Context" caching. Once you run a program things can "stick" and just altering an external manifest or slipping one in there Won't take effect. If your program was previously installed on that machine this might be the culprit. Rebooting should corect that.

See Windows Vista Sxs Activation Context Cache, noting that all supported versions of Windows are "Vista" (Longhorn) in very meaningful ways. That includes Win7, Win8, Win8.1.


What you need is a manifest that isolates this particular library (DBGrid32.ocx) into a subfolder ("DEP" or "BIN" etc.) under the application's folder. This manifest should be embedded in the EXE. Though a separate .manifest file can work it is a strongly nonpreferred alternative.

Your installer should deploy the library to this subfolder. If you insist on an external .manifest file it must be deployed alongside the EXE. And the installer must not register the library as part of installation.

But it sounds like you are doing this already.

 

[CP60]

The manifest wasn't embedded, but everything else was done correctly.

I wasn't going to deploy this with the installation, as the problem with the newer Grid is only happening with a few workstations.
I also had already understood and warned not to register the ocx in the \DEP folder, manually (or with the installer, if used).

I checked the Virtual store, but except for an old log file under the application folder, it was clean of any other files.
We rebooted the system, but it didn't help.
We also tried with the application started with admin rights.

I guess about the only thing left is to try embedding the manifest, but I don't see how that will make any difference.

Just to mention it again: All works when the \DEP folder, manifest and exe are copied straight from \program files (x86)\ to C:\MyApp\. So, it cannot have anything to do with mispelling or missing files.
There is a second exe with a different name there also, and a manifest was created for that one too. But this exe also has the same DGBrid errors.

Am now stuck.

 

[dilettante]

No, running the application elevated should not make any difference. I'm not sure embedding will help either. I'm at a loss to explain what you are seeing.

For globally registered libraries "servicing" is basically the process of installing updates, and most of the time to a VB6 programmer this means Microsoft library updates serviced through Windows Update, etc. When you have isolated a library such updating processes know nothing about it and so cannot replace it with a new version. This means that as the vendor you have to be responsible for all updating.

Once you figure out where things are going wrong there isn't much reason to avoid deploying this with your installer. Clearly the "new" version is too broken for your programs to use it anyway, making it unlikely that servicing the library will ever be an issue because when Microsoft breaks something this way they almost never fix it.

 

[HughLerwill]

Something which occasionally helps a manifest file to 'take' (overcome the cache presumably) is to make sure the exe files last modified date is later than the manifest files last modified date, i.e. the exe is newer.

 

[dilettante]

I'm not so sure about that, perhaps you have it backwards?

At the blog post I linked a few posts back it says:

To make a compromise, Sxs chooses the path of the entry manifest of CreateActCtx and its last modified time as the key. This means, if one of its dependent assemblies has changed, it is necessary to "touch" (i.e. change the last modified time of) the entry manifest for Sxs to see the change.

The blog post is discussing explicit calls to the CreateActCtx function, which also applies to usage of the Microsoft.Windows.ActCtx scripting helper object. But I would expect the cache to work the very same way when a manifest is auto-loaded through program runs and DLL loads.

 

[CP60]

Yes, I read that and remember already trying it.

But, just to make sure, I will test it again tomorrow (both ways).

As it is, it is already way past business hours here.

 

[HughLerwill]

>I'm not so sure about that...
Hmmm that's interesting because I have a personal use app with the option of applying the manifest to itself at run time(to make use of Common Controls 6) ; i.e. you click an option in the app, the manifest file is generated on the fly, and then the app restarts itself to apply the manifest (all happening in a non protected folder of course). This does not always work reliably and the app or the computer may have to be restarted several times before the app appears in its themed Common Controls 6 loveliness, however if I recompile the app with the manifest already in place the manifest always seems to be 'eaten' immediately. It could be nothing to do with file dates of course if Windows is keeping an eye out for other stuff like changes to minor version number of the exe which is set to auto-increment in my app.

 

[CP60]

HughLerwill, you were right.

I compiled a new exe and it works now.

It wasn't the date of the manifest, because it's date was newer than the exe on the system.
I tested this newer exe eith the older manifest already on the system, and also with a newer manifest, and it still worked in both cases.

Maybe, (but I not going to take the additional time to test it), if the manifest date was older than the older exe's date, something would have gotten jarred, though I doubt it.

I'd give you another Star if possible.

Thank you!

Thank you too, dilettante. You have also been a great help and I learned new things!!! I downloaded the MMM - great tool woth a thousand stars!

@Everyone: Have a nice day!