Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Problem deploying MSHFLXGD in MSAccess 2003 runtime

Posted on 2009-04-16
47
Medium Priority
?
1,139 Views
Last Modified: 2012-06-22
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.
0
Comment
Question by:trentham
  • 27
  • 20
47 Comments
 

Author Comment

by:trentham
ID: 24156143
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24170678
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
 

Author Comment

by:trentham
ID: 24178510
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
NEW Veeam Backup for Microsoft Office 365 1.5

With Office 365, it’s your data and your responsibility to protect it. NEW Veeam Backup for Microsoft Office 365 eliminates the risk of losing access to your Office 365 data.

 

Author Comment

by:trentham
ID: 24183667
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24183754
Se if this link helps:
          http://support.microsoft.com/kb/932349
0
 

Author Comment

by:trentham
ID: 24185448
That's the same link!;-)
0
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24185873
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
 

Author Comment

by:trentham
ID: 24185996
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24186093
Try unregistering, then re-registering.

see this link:
         http://cuinl.tripod.com/Tips/ocxtip.htm
0
 

Author Comment

by:trentham
ID: 24187132
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24187257
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
 

Author Comment

by:trentham
ID: 24189087
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24189169
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
 

Author Comment

by:trentham
ID: 24191756
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
 

Author Comment

by:trentham
ID: 24191952
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24193113
Try leaving out the security update completely...it seems to be incompatible with runtime.
0
 

Author Comment

by:trentham
ID: 24194807
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24195520
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
 

Author Comment

by:trentham
ID: 24196257
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
 

Author Comment

by:trentham
ID: 24203627
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24203714
Maybe you just need to change the macro security level on the problem pc to low or medium.  
0
 

Author Comment

by:trentham
ID: 24204802
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24205151
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
 

Author Comment

by:trentham
ID: 24209944
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24210594
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
 

Author Comment

by:trentham
ID: 24212460
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24214722
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
 

Author Comment

by:trentham
ID: 24217952
> 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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24218283
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
 

Author Comment

by:trentham
ID: 24224442
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24225738
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
 

Author Comment

by:trentham
ID: 24226704
Yes.  (How else could I have reported that I set the security level to low?)
0
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24226748
OK.  Just wanted to be sure! For the moment, I am out of ideas.
0
 

Author Comment

by:trentham
ID: 24245792
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24246479
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
 

Author Comment

by:trentham
ID: 24248445
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
 

Author Comment

by:trentham
ID: 24250100
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24250436
Sounds like something is wrong wiih the registry on the fail machine.  Maybe all you need is an old fashioned registry cleaner.
0
 

Author Comment

by:trentham
ID: 24251621
I can try that but it seems less likely given that it failed the same way on a second machine at the site.
0
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24251811
you have nothing to lose by trying a registry cleaner.  DLL errors happen frequently.
0
 

Author Comment

by:trentham
ID: 24252207
I've done that to no effect.  :-(
0
 

Author Comment

by:trentham
ID: 24267772
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
 

Accepted Solution

by:
trentham earned 0 total points
ID: 24268084
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
 

Author Comment

by:trentham
ID: 24268304
and extracting the replacement control from the VB6 rollup pack allows the system to work even with the patch applied! :-)

Sorted.
0
 
LVL 38

Assisted Solution

by:puppydogbuddy
puppydogbuddy earned 500 total points
ID: 24268783
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
 

Author Comment

by:trentham
ID: 24269074
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
 
LVL 38

Expert Comment

by:puppydogbuddy
ID: 24269793
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

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Access custom database properties are useful for storing miscellaneous bits of information in a format that persists through database closing and reopening.  This article shows how to create and use them.
Access developers frequently have requirements to interact with Excel (import from or output to) in their applications.  You might be able to accomplish this with the TransferSpreadsheet and OutputTo methods, but in this series of articles I will di…
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …
Look below the covers at a subform control , and the form that is inside it. Explore properties and see how easy it is to aggregate, get statistics, and synchronize results for your data. A Microsoft Access subform is used to show relevant calcul…
Suggested Courses

810 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question