[Eventprocedure] Windows language? (1 Viewer)

I have a Accessclient/SQLserver setup running at a company where all users work on a RDP-server. Some users have their Windowslanguage set to English, some have Dutch (as have I).
Every users gets their own client in their windowsprofile through a batchfile, ensuring everybody always has a fresh uptodate client

Last week I released an update (while working in dutch windows). Several users reported problems with using a new form when using certain buttons:

DB xxxx cannot find the object 'Gebeurtenisprocedure'. If 'Gebeurtenisprocedure' is a new macro of macrogroup, make sure you have saved it and that you have typed its name correctly

Click to expand...

"Gebeurtenisprocedure" is the Dutch translation for "eventprocedure"

When I checked with a user that reported this problem, I noticed that when I open the form in editmode and check the properties of the failing controls (buttons), that while the users has their Windows set to english, SOME of the buttons still have "gebeurtenisprocedure" set as the eventhandler instead of "eventprocedure". Other buttons - that do work for the user - have "eventprocedure" set as the eventhandler.

So, on the SAME form, some buttons keep to the dutch eventhandler, which doesn't work obviously, some buttons are set to the english eventhandler....

Of course, Access cannot handle this. It seems that Office should translate/handle the eventhandler between different languages and that for some reason this does not happen for some buttons on some forms

Strangly, when I created a new AD testaccount, set its language to english, the exact same client DOES work for that testaccount, so it seems all eventhandlers are "translated" correctly. So no errors...

When I set the user that reported to problem to dutch language, the client worked without problems (however, the user does not speak dutch, so this is not a solution)

I tried compiling/decompiling/compressing the client, no difference. I also tried importing all objects into a new database, but this also did not fix the problem.

Anyone that has some advice what to do?

edit: I just check some more users, some users have English set as Windowslanguage and have the problem, some users have English set but DON't have the problem. Users that have the problem and set Windows to dutch dont have the problem either... When they go back to English the problem reoccurs.

Hi,

I've had similar problems in the past.
They went away when i started developing in the english office versions.
When my client has a dutch office version installed there are no problems when they run my Access application.
I have customers all over the world and even the Chinese language doesn't give me an error when i develop in the English version of office.

I have had the same problem with the US date notation (mm/dd/yyyy) compared to the dutch notation (dd/mm/yyyy). Some dates are obvious but some are not. So i stored them in the US format, which seems native to Access.

Not to mention the decimal point. Which is a comma in the dutch version...

Back to the problem.
"Gebeurtenisprocedure" is a typical MACRO statement. Try to use less macro's and use more VBA code.
There are two macro's i use sometimes:"AutoExec" and "AutoKeys".
AutoExec runs when you open an Access application, but when you open a form on startup, you don't even need AutoExec.
With AutoKeys you can reprogram certain keystrokes.

HTH

One thing to be aware of when formatting dates for SQL commands in other regions is that the forward slash is a placeholder for the Regional Date Separator.

Don't use: as the format string. In regions where the forward slash is not the date separator, this can render as mm-dd-yyyy or mm.dd.yyyy.

Use
The backslash character is the literal escape, ensuring that the subsequent character is rendered literally as a forward slash in all regions.

If you cannot find a long term fix, you could write the code to update these properties explicitly. You could on the onopen event of the form specifically update control properties (assuming the form's on open is not failing)


I often do this when trapping other objects events from a class module.

Guus2005 said:

Back to the problem.
"Gebeurtenisprocedure" is a typical MACRO statement. Try to use less macro's and use more VBA code.
There are two macro's i use sometimes:"AutoExec" and "AutoKeys".
AutoExec runs when you open an Access application, but when you open a form on startup, you don't even need AutoExec.
With AutoKeys you can reprogram certain keystrokes.

Click to expand...

No that's not true. 'Gebeurtenisprocedure' is what Access puts in the eventhandler when you a setup/assign VBA code to a event (button/form etc) in a dutch environment.

Next to that, I do not use any macros, not even autoexec.


The longterm fix was to set my Windows to English, open the database, search for all leftover "gebeurtenisprocedure" and re-open the eventhandler for the specific events. This sets the eventhandler to the correct term "eventprocedure".
After that, the entire database was translated properly between NL and EN, and no eventhandler got stuck to "dutch".

BTw, I noticed a pattern, since all forms that had this problem for one of a few buttons/events all seemed copies of a specific form that also had the problem.
I suspect it was some kind of "corruption"

Name Auto Correct may be the culprit. I don't develop in or even use non-English versions of Access so I can't confirm. However, I would start by turning off this "feature". It is complex and its effects are not well understood hence its nickname of Name Auto Corrupt.

Some dates are obvious but some are not. So i stored them in the US format

Click to expand...

Dates are not stored as strings so you should NEVER, EVER use formatting on the table itself. All that does is to obfuscate the actual value. Only format dates on forms and reports. IMPORTANT- using Format() turns a date or a number into a string at which point they will stop acting like dates or numbers and act like strings. This is the biggest programmer caused problem when working with dates. The biggest technical problem when working with dates is that SQL assumes US date format of mm/dd/yyyy so if you pass a date as a string, it MUST be in US format or the unambiguous yyyy/mm/dd. However, when you reference a date data type field, there is no problem because the date is stored internally as a double precision number and is not ever formatted when performing calculations or sorting.

Thanks a lot for info

You may want to install a tool like Rick Fisher's Find and Replace tool and/or MZTools.
The F&R tool can find what you are looking for in your application. MZTools gives you handy tools when you are working your code. And decompile once in a while. It will show you many more glitches in your code. Especially in legacy applications.

HTH

I already used a tool like that to search for 'gebeurtenisprocedure' while working on an English environment/office setting, that helped a lot to quickly find all problempoints