I wish I could say the same for the idiots who wrote the "fix". How can M$
release an update that bombs one of its own activeX components? Sheesh!
Thanks again.
Close the database program that uses the FlexGrid.
Open the Control Panel and then the Add or Remove Programs form.
Tick the Show Updates box at the top of the form.
Locate the Security Update for Windows XP (KB960715).
Click the Remove button and follow the prompts.
This should fix it.
Peter Hibbs.
Just need to make sure now that future automatic updates don't
re-install it.
Peter Hibbs.
http://support.erol.co.uk/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=223
We will have to wait and see what happens I think.
Peter Hibbs.
I have posted the .reg file on our webserver here
http://www.kenworld.se/filer.aspx
Thanks for that information. If anyone else has problems with the
FlexGrid control we can point them at your Web site.
Peter Hibbs.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{6262d3a0-531b-11cf-91f6-c2863c385e30}]
"Compatibility Flags"=-
http://www.kenworld.se/filer.aspx
Peter Hibbs.
I've been battling the same problem myself since Friday (it's now 1am
Monday) and have finally figured out the "kosher" solution.
The KB960715 "security update" sets a "kill bit" in the registry entry for
several ActiveX controls, including several of MS's own VB6 controls.
MSFlexGrid is one of those affected.
More info here:
http://www.microsoft.com/technet/security/advisory/960715.mspx
It turns out that there is another KB (957924) which updates those VB6
ActiveX controls to a later version which does not have the vulnerability
and are therefore not kill-bitted. The "OK" version for msflxgrd.ocx is
6.1.98.12.
You can download this VB6 update from here:
http://support.microsoft.com/kb/957924
Unfortunately, the KB957924 update will not run unless you have VB6
installed, so you probably can't run it on the end-user machine. However,
you can run it on a machine with VB6 and then redistribute the new
version(s) of the OCX file(s) from that machine to the end users.
I hope this helps. I agree with you that this is a monumental cock-up. I
don't understand how MS can shoot themselves in the foot like this.
--
Good Luck :-)
Graham Mandeno [Access MVP]
Auckland, New Zealand
"R Fourt" <RFo...@discussions.microsoft.com> wrote in message
news:89D83804-6374-4EC1...@microsoft.com...
I have created a download for this ocx control and a registry edit for our
clients that you are welcome to use.
http://www.solutionsplus.co.nz/downloads/MSFlexGrid.htm
if you have any problems with this please let me know.
jonathan AT solutionsplus.co.nz
Luck
Jonathan
Thanks very much for that. A couple of minor points:
1. The updated control has a different CLSID
{74DD2713-BA98-4D10-A16E-270BBEB9B555}, so you shouldn't mess with the
Compatibility Flags of the insecure one at
{6262D3A0-531B-11CF-91F6-C2863C385E30}.
2. The new OCX will DEFINITELY need re-registering with regsvr32, not just
maybe.
3. Have you checked with MS or the VB6 EULA on the legality of distributing
a control in this way? I suspect they might not like it.
--
Cheers :-)
Graham Mandeno [Access MVP]
Auckland, New Zealand
"Jonathan" <Jona...@discussions.microsoft.com> wrote in message
news:4CFD49BE-1B28-4ADD...@microsoft.com...
"Graham Mandeno" wrote:
> Hi Jonathan
>
> Thanks very much for that. A couple of minor points:
>
> 1. The updated control has a different CLSID
> {74DD2713-BA98-4D10-A16E-270BBEB9B555}, so you shouldn't mess with the
> Compatibility Flags of the insecure one at
> {6262D3A0-531B-11CF-91F6-C2863C385E30}.
Just passing on Microsoft's support's recommendation. Thanks for noticing
this.
> 2. The new OCX will DEFINITELY need re-registering with regsvr32, not just
> maybe.
Yes.
> 3. Have you checked with MS or the VB6 EULA on the legality of distributing
> a control in this way? I suspect they might not like it.
You maybe right. However as this is a show stopper (our users can't run core
business processes) I needed to get this out using a method that is easy for
users to follow. If Microsoft requests for this page to be removed, I will
comply.
"Paul Wong" wrote:
> Guys,
>
> I have downloaded the new msflxgrd.cab from
> http://support.microsoft.com/kb/957924.
>
> After placing the new cab on my web application directory and changing the
> clsid to 74DD2713-BA98-4D10-A16E-270BBEB9B555 on the object tag, the red X
> still shows on some computers.
>
> I know the new cab downloads, because I had removed the old msflxgrd from
> the computers, and I can watch the new activex downloads and installs though
> IE. But, after it installs, I still see a red x.
>
> I thought it may have something to do with licensing or missing dependency
> files. So, I created a simple VB6 app that uses msflxgrd.ocx, and made a
> distribution setup to distribute the grid to all computers. This still does
> not work. IE just refuses to load the grid.
>
> Any more ideas?
Sorry Paul, we do not seem to be having any more problems with this and so I
have not had this experience. I do suggest getting in touch with Microsoft
support. They may have found a better way to resolve this issue as it has
been a while since this problem first occured.
Luck,
Jonathan
>
Is this control being used in an Access form or a web page? It sounds like
the problem is that the new ActiveX control is not properly downloading and
installing on some computers. Maybe it's something to do with the security
settings on those computers. Perhaps you'd be better off posting this
question to an IE newsgroup.
--
Good Luck :-)
Graham Mandeno [Access MVP]
Auckland, New Zealand
"Paul Wong" <Paul...@discussions.microsoft.com> wrote in message
news:FD8B6CEE-2AC9-49A4...@microsoft.com...
You have to call Microsoft Support. They will provide you with the .lpk
file that goes with the new msflxgrd.cab/ocx so that it can be used on web
pages. The existing lpk tool program is not capable of picking up the new
license of the new cab.