Missing library in Object Browser

[Guest]

I am looking at an issue with an Excel spreadsheet. The spreadsheet contains
4 forms, two of which are throwing up errors.

The code that is causing the issues is as follows:

Private Sub UserForm_Initialize()
Me.questdate.Value = Date
End Sub

Private Sub UserForm_Initialize()
Me.Startdate.Value = Date
Me.Enddate.Value = Date
End Sub

The problem is intermittent. We work in a published Citrix Environment,
with Windows 2000 servers hosting a published desktop. We are running Excel
2000 on all servers.

On some servers, the spreadsheet works as expected. On others it fails.

On the servers that work, it is possible to open Object Browser, search for
questdate, startdate or enddate, and it returns:
Library: f3dynamic
Class: Userform
Member: <searchstring>

On the servers that the code doesn't work on, no results are returned.
I have search on a working server for files called f3dynamic, but no results
are returned.

All access to our servers by users is via ICA connections. Tests have shown
the following results:
Launch ICA connection with standard user account - Spreadsheet errors
Launch ICA connection with a high priv (domain admin) account - Spreadsheet
errors
Launch RDP connection with a high priv (domain admin) account - Spreadsheet
works as expected, f3dynamic library can be viewed, and spreadsheet is then
OK for all other users.

I have tried filemon and regmon monitoring, without much success.

Can anyone suggest any further next steps to resolve this issue?

 

[Norman Jones]

Hi Jo,

With the workbook in question active, run the problematic code

When the code errors, go to the VBE and select the project in the Project
Explorer Window

Hit the reset button and look at the Tools | References list

Look for any references marked as "MISSING".

Either uncheck the reference or, if the reference is needed, try the browse
button to locate the library,

 

[Guest]

Norman,

Thanks for your reply. I have checked what you have suggested, and there
are not any references marked as "missing".

Any other thoughts or suggestions much appreciated!

Jo

 

[mcc99]

It's part of mscal.ocx

There is an "AboutBox" method associated with the calendar control that is part of the f3dynamic library. I called this method in code on a machine that has no problems with this issue and it read "Microsoft Office Access Calendar Control version 11.0". The machines I don't have this problem on of course have Access on them and the ones I have this problem on don't.

In short, it's an Access library and that is why you can't find it on your machines that don't have Access. It also explains why it isn't coming up in the References listing in Excel; it isn't marked to be available in Excel since it's an Access library. Nonetheless, it is a COM-compliant object and so it still works in Excel.

Viva Microsoft!

I did some sleuthing and found that the culprit (if you can call it that) is the mscal.ocx control found both in c:\windows\system32 and in C:\Program Files\Microsoft Office\Office10. That is what gets installed with Access and then allows access to that mysterious "F3Dynamic" library, which I still can't get a good look into via the Object Browser. [I suspect it was marked private when it was developed with the intention of access to its functions only via the MSCal object, but somehow, its name got exposed. Maybe also it was meant to be marked private but only got marked protected. Dunno enough about that kind of thing though to make a real educated guess.]

One other thing: A way to get this control, as well as most any others, onto a machine that doesn't have Access is to create a VB project (assuming you have VB and know how to use it well enough) that has all the control references your Excel solution needs pasted onto a form and then use the Pkg and Deploy Wizard to package the "empty" app. Then all you need do is run the VB program installer on the target machine and then copy your Excel solution over to it. This strategy will help you test ahead of time better to predict general installation scenario success as well as keep you from having to use the "Nuclear Option" quite so much (ie, installing the VB dev environment onto the target machine, then all the srvc pack stuff, then uninstall VB, leaving the updated controls in hopes your controls refs in your Excel solution will now be good).

One thing though re the mscal control and the VB installer: apparently there's a problem with the setup.lst file that gets created by the Vb Pkg and Deploy Wizard when you use this strategy. You need to do a small edit to it for the install to work. More on that here.