Problem deploying MSHFLXGD in MSAccess 2003 runtime

I am developing an Access 2003 application which uses the MSHFLXGD control and is to be run using the MSaccess 2003 runtime.

On my target machine, having installed the runtime and registered the OCX, when the application starts up it gets an error 438 - Object doesn't support this property or method.

It would appear that this is when it's doing a .move of the control.

The application shows no problems in the development environment and I've tried it with the runtime on various test machines and it is NOW running fine on all of them.

At one time it was getting the same problem on a test machine and eventually I discovered that it was because it was trying to use an installed Access2000 development version rather than the 2003 runtime, however this was fixed when I set up the correct shortcut path.

The only thing that's particularly different on the problem machine is that it's got Office 2002 XP Business edition installed (or whatever it's correctly called!) but that contains no Access database and I've got the correct shortcuts set up anyway.

I believe (from my tests) that Access 2000 (and possibly Access 2002) did not support the .move method for this control (or maybe for any control?), though 2003 does which, if I'm correct, suggests that it's trying to run in the wrong environment!

I've tried reinstalling the 2003 runtime but nothing I try makes any difference.

I've pretty well run out of ideas of even what tests I can run now so I'm hoping that someone else has come across this problem and can point me in the right direction.
trenthamAsked:
Who is Participating?
 
trenthamConnect With a Mentor Author Commented:
It certainly seems like I've found the cause!

On a test system without KB960715 installed it worked.  Install KB960715 and it shows the symptoms described.  Remove KB960715 and it's back to working again!

Word has it that installing the VB6 rollup pack KB967924 it would fix it but the target machines don't have VB6 installed and that is a prerequisite.  Why couldn't Microsnot just has provided mended controls with the KB960715 update?  *sigh*
0
 
trenthamAuthor Commented:
I should have mentioned that I'm out of the office now until the weekend so if you ask me questions, it's not because I'm ignoring you or don't care that I'm not replying!
0
 
puppydogbuddyCommented:
Here is one possibility......if you have installed the MS08-070 Security update for Access Runtime, VBA based applications that use ActiveX's to create an instance of the control directly through Office do not get installed to the form.
             http://support.microsoft.com/kb/932349
Excerpted from the above mentioned link:
To resolve this issue, install the cumulative update rollup for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files update. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 957924  (http://support.microsoft.com/kb/957924/ ) Description of the cumulative update rollup for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files
If you are using Office Visual Basic for Applications, you may also need to delete the cached versions of the control type libraries. To do this, search your hard drive for ".exd," and delete all the .exd files. The .exd files will be re-created automatically using the new controls the next time that you use VBA.
0
Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

 
trenthamAuthor Commented:
Thanks for that pointer.  I'll investigate it and see if this is the situation.

I'm also suspicious that the control IS working and it's just that the Access runtime isn't doing what it should do, in other words it's a problem with the Runtime environment rather than the control.  There's nothing suggesting that it can't find or use the control - just that the move method isn't working with it.  I do have a vague memory that AC2000 didn't allow move with controls but I can test that out.
0
 
trenthamAuthor Commented:
I've done some more testing and now have a bit more information although I don't know what it all really means!

I tried installing the VB6 rollup pack mentioned but it wouldn't because the system isn't running VB6 (seems strange that it wanted that when it's a runtime patch!).  The only possible relevant mention was that of Office and that only concerned the MSFLXGRD control, which is not what I'm using anyway.

I looked through installed patches but could see no sign of the mentioned one, although it has SP3 so perhaps it's all bundled in there somewhere.

I also am not getting either of the suggested error messages, "Object library invalid or contains references to object definitions that could not be found." or "Element not found." though see my later tests...

I created a simple test app.  Firstly it had a simple text control on a form and the form load event used .move to resize it.  This worked without a problem.

Next I added an MSHFLXGD control with some simple formatting - set rows and cols and insert some values.  This failed saying "There is no object in this control".  Maybe that's vaguely releated to the above error messages.

to my mind it would suggest that there's something missing that the control wants to use but how do I find out what?  I had a look in the mshflxgd.dep file and see that it uses comcat.dll and msstdfmt.dll, both of which are present.
0
 
puppydogbuddyCommented:
Se if this link helps:
          http://support.microsoft.com/kb/932349
0
 
trenthamAuthor Commented:
That's the same link!;-)
0
 
puppydogbuddyCommented:
You're right...for some reasson, I hought it had additional info.  Sorry.
In re-reading your last post, thee error message sounds like maybe you need to register  your activeX via Windows Regsrvr32.Exe.  If you have not done so, that could be the problem.
0
 
trenthamAuthor Commented:
It has been registered and is showing up using RegDLLView.

Is there any way I can add extra bits to the application to allow me to look at the list of registered stuff (like in the dev. version I can use Tools/ActiveX controls) or to look at the references, normally available from the VBA interface? - or perhaps I'll just need to code my own!

I agree that it's acting much like it doesn't know about the control but it is registered and I don't know what else to ask it!
0
 
puppydogbuddyCommented:
Try unregistering, then re-registering.

see this link:
         http://cuinl.tripod.com/Tips/ocxtip.htm
0
 
trenthamAuthor Commented:
I have registered and unregistered several times and tried moving it into different folders, just in case that mattered.  Currently it's sitting registered in \Win\Sys32 and I've even de- and re-registered it again.

I've also tried including an instance of MSFLXGRD as well and it's behaving in exactly the same way (not terribly surprising, I suppose).

If I de-register the MSHFLXGD control and then run the app I get the "There is no object in the control" and then I get an error message because the "Object or Class does not support the set of events" instead of my trapped and displayed error message (which is thrown the moment I try and do anything with the control) - so things are different depending on whether it's registered or not!
0
 
puppydogbuddyCommented:
Ok, then try deleting MSHFLXGD control from your form, then reinstall it, making sure you have the correct version#.  Also, make sure you install any companion files, and that you register it.
0
 
trenthamAuthor Commented:
but all this has been done in effect when I created a test form from scratch with just a text cntrol and a grid control on it and very little coding behind it.  The test form is failing in the same way as the main application.

WRT "making sure you have the correct version#", to the best of my knowledge I only have one version of this control (though I will have a check around to make sure) and that is the same one that worked on a variety of other machines.

Having just scanned my development machine for all mshflxgd files I notice that there is sometimes an OCA file (Control Typelib Cache) as well as .DEP and .SRG.  Whether these exist on the target machine, I don't know (yet).  Nor do I know if it's relevant!
0
 
puppydogbuddyCommented:
Look at the last link I gave you.   It has a list of the version #'s and companion files for each product (e.g. Visual Studio, Office XP2, etc).
0
 
trenthamAuthor Commented:
It seems to me that the link you specified (assuming it's the MS one and not ocxtip.htm!) covers things other than my case.  It covers Visual Foxpro, Visual Studio .net, MS Office Project (each in different incarnations), VB6 runtime and MS Office XP.

Of all these only VB6 runtime and Office XP even start to hav a bearing on my application, and VB6 only because I'm actually using VBA, so it's not really relevant anyway!

Office XP MIGHT be relevant since that's maybe the version of Office that's installed on the machine (though I'm actually trying to use the Access 2003 Runtime), but even then the only component mentioned in it is msflxgrd, which is not what I'm using.

Maybe I can try installing the VB6 runtime and then maybe it'll allow me to install the VB6 runtime security update.  I'll see if that works on a test machine (though I'm not having a problem on any of my test machines - just the target machine.  

Just for clarification I refer to my main development machine which has the development MSACCESS 2003 plus a number of test machines with a variety of Office 2000 installed, Access 2000 installed, no office installed - all with Access 2003 RT, and then there's the target machine at my client site which seems to have Office XP Business (I think) with no Access but Access 2003 RT that I installed.  This ios now the only machine where I'm having a problem.  Maybe I need to set up a VM with OfficeXP and see if I can recreate the problem here.
0
 
trenthamAuthor Commented:
Installing VB6 runtime and then trying the security update didn't work.  It wants me to have the full VB6 installed in order to apply the patch.  
0
 
puppydogbuddyCommented:
Try leaving out the security update completely...it seems to be incompatible with runtime.
0
 
trenthamAuthor Commented:
But I'm not trying to use the VB6 runtime - remember it's all about the Access 2003 runtime.  I accept that there may be something required from VB6 but I rather doubt it.  I've not had these problems on other machines which have started from scratch with nothing like these loaded.

The target machine which is causing the problem is running XPpro/SP3 while my test machines are running Win2Kpro, XPhome/SP2 and the development machine runs XPpro/SP3.

Having installed VB6 runtime (SP6) on the target m/c made no difference.
0
 
puppydogbuddyCommented:
IThe only thing left to tell you is that is that I would uninstall the securiity update (sp3) so that the problem machine is rolled back to sp2 .    Other than that, you've tried everything else I suggested and they did not work.
0
 
trenthamAuthor Commented:
Perhaps as a first step I'll try installing SP3 on one of my test machines and see if that makes it fail.  Whether it works or not I guess I'll still be left uninstalling SP3 on the target but at least it will give me some confidence that it might well fix the problem (the machine is used for other things!)
0
 
trenthamAuthor Commented:
I've tried it now on a test machine with XP-SP3 and there's no problem there.

It's not realistic to remove SP3 from the target machine without stronger reasons since it's used for all the accounts and payroll stuff.

:-(
0
 
puppydogbuddyCommented:
Maybe you just need to change the macro security level on the problem pc to low or medium.  
0
 
trenthamAuthor Commented:
It already is ... but that wouldn't affect whether the control would display or not.  I've had it set to high on other machines with no problems in that area.
0
 
puppydogbuddyCommented:
if the activeX is not part of a "trusted" application on the pc, the security upgrade would have disabled any vba code driving the activeX.  Check and see if application is trusted app on problem pc vs ok pc.
0
 
trenthamAuthor Commented:
Now that's interesting!  I believe the application is a trusted app since I installed a certidficate and went through all that trusted stuff but I'll check when I can next get at the machine (probably Friday) - though how do I check if it's trusted?  If it weren't trusted would any other controls be working?

Could anything about 'block unsafe expressions' have any bearing on the matter and can whatever it remembers about that, be reset?
0
 
puppydogbuddyCommented:
it is all interrelated....security update blocks unsafe expressions, including those driving the ActiveX. Several ways to get around this....get application listed as a trusted site and/or set macro security level to low or medium.  Note also, that if your application interacts with other members of the Office Suite via vba, you must also set macro security level to low/medium in those programs (e.g. word, excel,etc)

see this link:
              http://office.microsoft.com/en-us/ork2003/HA011403071033.aspx?pid=CH011480831033
0
 
trenthamAuthor Commented:
AIUI I can't make the macro/security option available in a runtime app, so does that mean I need to startt the app using the Application.AutomationSecurity property?  I must admit it's not something I've ever had to do before and wasn't required on any of my test machines, but then they're not running Office XP so maybe there's some interaction there.
0
 
puppydogbuddyCommented:
For runtime, if it were not for the code provided in the link below, you would not be able to change the macro security level and would have to get a digital certificate. The code is worth its weight in gold if it works as stated.  Good luck with it.
                 www.experts-exchange.com/Microsoft/Development/MS_Access/Q_23994747.html
0
 
trenthamAuthor Commented:
> For runtime ... you would not be able to change the macro security level

Is that crazy or what!  Then again, maybe it's changing the security level on the user's machine generally, and not just for this appllication, which could be said not to be a good thing.  I really do think Mr Gates and his Glee Club have a lot to answer for!

I'll see if it helps my case when I next get at the target machine.
0
 
puppydogbuddyCommented:
Just to make sure we are on the same page........what I said is that with the code provided in the link I gave you, you should be able to change the macro security level for your runtime application.  If it were not for the code, you would have to get a digital certificate for each of your runtime applications.
0
 
trenthamAuthor Commented:
I must admit I thought that changing the security level via macros/security changed it for the whole Office suite and not just the application in question.

Anyway, I've now tried it by setting security level to low and allowing unsafe expressions but still no joy.  Exactly the same behaviour as before.

*sigh*
0
 
puppydogbuddyCommented:
You can't change the macro security level for computers using Runtime without using the code I gave you.  Did you use the code?
0
 
trenthamAuthor Commented:
Yes.  (How else could I have reported that I set the security level to low?)
0
 
puppydogbuddyCommented:
OK.  Just wanted to be sure! For the moment, I am out of ideas.
0
 
trenthamAuthor Commented:
Just an update of further investigations on this subject (though still without any real ideas!)...

I tried setting things up on a second target machine.  This one also had Office XP Business edition (2002).  I installed the Access2003 RT and registered the OCX and tried running the application and got exactly the same problem as before.

Just to get some sort of test system running, I set up a Virtual Machine on the first target machine, installed XPhome/SP2 then installed the Access2003 RT and registered the OCX and tried running the application and this time it worked without problem.

It would appear that there's something in the target machine setup which is preventing the OCX work properly though it's by no means apparent what it is.

My next line of experimentation is to try setting up a machine with Office XP and see if that's the cause of the problem.
0
 
puppydogbuddyCommented:
Just to double check........see the following link.  http://support.microsoft.com/default.aspx?scid=kb;en-us;319844#top
It addresses ActiveX problems, not Runtime......the following should be checked even though the error message is slightly different.....                    
1. DAO is not properly registered.
2. Make sure that users have "read" permissions for all files in the following folders.
Windows XP \Windows\System32
0
 
trenthamAuthor Commented:
I had investigated that link previously and everything seemed OK, however I'll check again.  Maybw FileMon will give me some clue as to what it's trying to do.
0
 
trenthamAuthor Commented:
I've done a comprehensive scan with FileMon to see what happens in the file system to see if I can get any clues and the following are the results.

The first Test machine (which I'll refer to as 'WORK1') is XPhome/SP2 and has Office2000 installed (only Word and Excel).

The second test machine (which also works = WORK2) is XPhome/SP3 and has Access2000 installed, thought it's obviously not being used in these tests.

The Target machine (which I'll call 'FAIL') is XPpro/SP3 with Office XP installed (no Access)

All machines have the Access2003RT installed and are running the database as an MDE file (mdb produces the same results).

I monitored the file activity for MSACCESS.EXE and looked aound the time when MSHFLXGD.OCX reared its head.

It was interesting to note that the access before the first grid access varied between machines... for WORK1 it was ole32.dll, for WORK2 it was SYSTEM.MDW and on FAIL it was the database file itself.

WORK1 did a bundle of grid access and then OLEPRO32.DLL, oleaut32.dll and ole32.dll.
WORK2 did a bundle of grid access and then OLEPRO32.DLL

The they carried on with a bundle more grid access.

FAIL, on the other hand, did a bundle of grid accesses and then tried and failed to open ...\My Documents\ACCOCX.TLB and then closed the grid.

This looks a lot like a clue but I've no idea what it means.  Neither of the WORK machines have this file and nor does my development machine.  What is it and why is it trying to find it in My Documents?  Indeed, what old it to look for it?

I can provide the Filemon logs if they're likely to be of any value to anyone.
0
 
puppydogbuddyCommented:
Sounds like something is wrong wiih the registry on the fail machine.  Maybe all you need is an old fashioned registry cleaner.
0
 
trenthamAuthor Commented:
I can try that but it seems less likely given that it failed the same way on a second machine at the site.
0
 
puppydogbuddyCommented:
you have nothing to lose by trying a registry cleaner.  DLL errors happen frequently.
0
 
trenthamAuthor Commented:
I've done that to no effect.  :-(
0
 
trenthamAuthor Commented:
It's just possible that the problem has been caused by a Microsnot update (why would I not be surprised?!)

I've not yet tested this on a target machine but I've found a number of reports blaming and mentioning KB960715 and KB967924.

I'll do some testing when I can next get on the target machines and report back.
0
 
trenthamAuthor Commented:
and extracting the replacement control from the VB6 rollup pack allows the system to work even with the patch applied! :-)

Sorted.
0
 
puppydogbuddyConnect With a Mentor Commented:
Objection on 2 fronts:
1. Trenthams final solution involved a fix to the security update, which I had previously advised him to uninstall...see  my post 04/21/09 11:27 AM, ID: 24195520.
2. Secondly, for the past 2 weeks, I have given him different ideas of what to test.  While they did not solve the problem, they eliminated numerous possible causes as being a factor in his case.  I did not expect to be awarded full points, but I did expect some acknowledgement that my assistance at least helped alert him to numerous potential causes/resolutions for his problem.  
0
 
trenthamAuthor Commented:
I hear what you say and would point out that your post 24195520 only suggested removing SP3, which I did and it didn't help.  It made no mention of the patch,KB960715, which was causing the problem and has nothing to do with SP3.

I also accept that you came up with lots of things to try, most of which I'd already tried and didn't work.

Having said that, I don't want to be churlish and I do appreciate that you spent time on this and it was useful having someone to bounce ideas off and I would be happy to award you half the points, if you find that acceptable - and I can discover how to do it!
0
 
puppydogbuddyCommented:
I am agreeable to the resolution you proposed, but keep in mind that I did not protest in order to get points. I protested because you did not acknowledge any part of the assistance you received, which was all pro bono.  

And just for the record, you are technically correct that the Kill Bit Patch was installed separately from the sp3 update.  Nonetheless, the patch was an attempted fix for deficiencies in sp3.   The  reason the uninstall of sp3 did not fix your problem was because the Kill Bit patch corrupted the ActiveX control, requiring that the ActiveX also be uninstalled/reinstalled after sp3 was removed.  
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.