Events in subforms don't work with Japanese Access - Can't find missing DLL

[Rainer]

Hi,

We have an MS Access application that works fine on US and European
Access installations but not on Japanese installations. Simple forms
work fine, but forms that contain subforms with event programming give
errors for each event. Our Japanese customer translated one of the
error message as follows:

When Event, the formula that I appointed in a property, at the time of
resize, an error occurred:
When SafetyCaseDB communicated with an OLE server or ActiveX control,
an error occurred.

We can reproduce it on multiple japanese installations. We checked all
references on a Japanese installation and they are fine. We can
recompile the program without compile time error. We gave every
subroutine / function an explicit reference like VBA.Left. Still the
help text to the error message leads to the MS Knowledgebase, entry
283806, which says that a DLL is missing.

To compile successfully the application requires references to the
following DLLs / OCXs:

MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
MSCOMCTL.OCX
FM20.DLL
vbscript.dll\3

Thank you all for the help,

Rainer

 

[Douglas J. Steele]

Do you really need all those references?

Consider removing the references to Word, Excel and the VBScript library,
and using Late Binding instead.

Consider removing the reference to MSCOMCTL.OCX and using API calls instead
(see http://www.mvps.org/access/api/api0001.htm at "The Access Web" if
you've only got that reference for the standard Windows File Open/File Save
dialog)

Access doesn't usually work correctly with FM20.DLL anyhow: why have you got
that reference?

The general rule is to "starve" your references: only have the bare minimum
as much as possible.

 

[Rainer]

Doug,

thank you for your suggestions.

My major concern is FM20.DLL. We have no clue why we have it. The
application developed over years. Access doesn't allow us to remove the
reference ('in use'). Any hint how to get rid of it?

Concerning MSCOMCTL.OCX: We need it, as we make extensive use of
TreeViews all over the program.

The other references, we can replace by late binding. But wouldn't we
miss the syntax check by the VBA p-code compiler?

Thanks, Rainer

 

[Douglas J. Steele]

I'm very surprised that you can't remove the FM20.DLL. You might try
creating a new database and importing all of the objects from your existing
database into the new one (the references won't be imported: if you don't
have a required reference, you'll know when you try to compile the
application)

MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or ListViews, you
have no choice but to include the control (sorry, I misread, and thought you
were using MSCOMDLG.OCX)

Once your application is working, you really don't need the syntax checking
that early binding provides. It's typical to add the reference, develop the
application, then remove the reference before distributing the application.
If your code uses any of the intrinsic constants that come from the
reference (xlRight, wdPromptToSaveChanges and so on), you either have to
define the constants as Public in a module in your application, or replace
them with the actual value (my vote is the former).

 

[david epsom dot com dot au]

MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or ListViews,

you have no choice but to include the control

??? you don't need the type library to use the control, any
more than you do for Word (or calendar) ???, it just makes
it easier ??? Adding the object to a form adds the type library,
but you can remove the type library and use late binding
techniques if you want to??? Removing the type library
doesn't make the object work if the object is not right, but
lets other code work correctly?

Does the subform or form have one of these objects? The
error sounds more like an Access error than a VBA error,
so it could be the link between the form and an active
X control that has failed, rather than a failure while
searching the type libraries.

(david)

 

[Douglas J Steele]

??? you don't need the type library to use the control, any
more than you do for Word (or calendar) ???, it just makes
it easier ??? Adding the object to a form adds the type library,
but you can remove the type library and use late binding
techniques if you want to??? Removing the type library
doesn't make the object work if the object is not right, but
lets other code work correctly?

David: If you know of some way to have TreeViews or ListViews without having
to have a reference to MSCOMCTL.OCX, I'd love to know of it!

 

[Rainer]

Doug,

I'm following your advise and did copy all objects into an empty
database. So far I got rid of FM20.DLL. Thanks. I had no chance yet to
test it on a Japanese installation.

However, I don't get our menus and popup menus over. How can I do that?

Rainer

 

[Rainer]

David,

No, the failing subforms don't have treeviews. They only use standard
ACCESS objects.

We kept the treeviews in separate forms. We wanted to encapsulate the
use of additional DLLs as we did fear to run into problems with non
standard DLLs. Funny enough, they work on the Japanese installation.

Kind regards

Rainer

 

[Douglas J Steele]

They're stored in one of the system tables, but off the top of my head, I'm
afraid I don't remember which one.

You might try posting this as a new question: many people avoid responding
to posts that have been going back and forth for this long.

 

[Douglas J Steele]

Actually, I just remembered that when you're importing from one database to
another, you can click on the Options button, and you'll be presented with
an option to import the Menus and Toolbars.

 

[david epsom dot com dot au]

When you add a mscomctl.ocx to a form, Access adds
mscomctl.ocx as a 'reference' in the VBA project.

If you view the object browser, you will see mscomctlLib.

You can remove the 'reference' to mscomctl.ocx, which will
remove mscomctlLib from the object browser, but will not
remove the mscomctl.ocx object from your form.

If you remove the 'reference' to mscomctl.ocx, you loose
msconctlLib from the object browser, and you will have to
use late binding techniques with the mscomctl object on
your form.

If you remove the reference, you will not get the 'broken
reference' behaviour in VBA, where VBA fails while searching
through the type libraries to see if there are any function
or method declarations that over-ride the VBA function and
method definitions.

If the object on the form is not declared and registered
as expected, the object on the form will not work, but if
you are not using the type library, that won't kill the
whole project.

I always use this technique with other Active X objects.
(david)

 

[david epsom dot com dot au]

What is the error number?

Does the error occur on an actual line of code?
(or is it a 'form' error?)

(david)

 

[Douglas J Steele]

I'd never tried doing that. Thanks!

 

[david epsom dot com dot au]

http://support.microsoft.com/kb/907337/en-us

....

"The expression On Click you entered as the event property setting produced
the following error: A problem occurred while Microsoft Access was
communicating with the OLE Server or ActiveX Control."

....
this issue may occur if the following conditions are true:

....

You run the VBA code on a computer that uses different non-Unicode language
settings than the computer on which you created the event handler, the
function, or the subroutine.

....


(david)

 

[Rainer]

David,

Thank you for the hint. Isn't that the normal situation when we develop
on German and English machines, and then let the ACCESS application run
on a Japanese machine?

Can you explain what such non-Unicode language settings are and how to
avoid them or set them correctly?

Remark: (1) All text/memo fields in the tables have UniCode Compression
ON. (2) The first time we encountered the problem with Japanese Access,
we changed all controls from standard MS Sans Serif to Tahoma font, as
there was another thread saying other fonts may result in unicode
language problems.

BTW, your hint on the import option made me import the menus.

Kind regards

Rainer

 

[Rainer]

David,

my previous message didn't answer your question. There is no VBA error
number indicated. The error occurs before I can set any breakpoint in
the form's event code. It may be what you call "form error".

Rainer

 

[Rainer]

David,

I did overlook your link to the Microsoft knowledge space. I will
follow what they advice.

Thanks, Rainer

 

[david epsom dot com dot au]

This tends to indicate that you don't have an error
in 'VBA', you have an error in 'Access', that is,
you don't have a 'references' error. But I think
the KB article clears up that question anyway.

Access uses com based communications internally,
and you've got trouble reading a property or raising
an event, because the source and the sink are
speaking different languages.

I'd be looking at setting up a Japanese machine
to do the build, or pushing MS to get a hotfix.

(david)