UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
3 Pages V < 1 2 3  (Go to first unread post)
   Reply to this topicStart new topic
> Foreign Currencies In Runtime Apps, Any Version    
 
   
ztatzau
post Feb 28 2020, 10:08 PM
Post#41



Posts: 374
Joined: 4-April 07



FOLLOW UP REPORT:

I am happy to report that Wayne Phillips' Everything Access article and methods on "Using the Currency Field Data Type - Without the Hassle", that FrankRuperto suggested above, seem to be working great for me.

I modified my ACCDB BE tables and a few forms and reports in my ACCDB FE exactly as described in Wayne's article on my regular development Win 7 machine with Access 2007.
I then tested the FE & BE ACCDB files with Office 365 CTR on a Win 10 machine with Regional Location and Language settings set to South Africa and English (South Africa).

The few forms and reports that I modified, as per Wane's instructions, all worked perfectly and displayed all the money amounts in the desired SA Rand and currency format.

BUT! I am even more pleased to report that, after compiling my FE ACCDB > ACCDE and renaming ACCDR, still all on my Win7/A2K7 machine with US Regional settings, I performed the same testing with the new ACCDR FE as I did before with the ACCDB FE on the windows 10 machine, and the results were the same as the first test. All the financial forms and reports that I modified displayed the correct SA Rand and currency format.

So it seems to be, so far anyway, that it won't be necessary to compile my ACCDB > ACCDE > ACCDR on a machine with the same regional settings as the target machine!

My client in SA isn't at all concerned with SA vs. US date formats, so I will probably will leave dates formatted as such in table fields and text boxes as they are. However my hunch is that Wayne's methods would work just as well for formatting regional date formats, on the fly at start up using the machine's regional settings, just as well as it seems to be working for currency symbols and formats.

Go to the top of the page
 
PhilS
post Feb 29 2020, 05:07 AM
Post#42



Posts: 690
Joined: 26-May 15
From: The middle of Germany


QUOTE
My client in SA isn't at all concerned with SA vs. US date formats, so I will probably will leave dates formatted as such in table fields and text boxes as they are. However my hunch is that Wayne's methods would work just as well for formatting regional date formats, on the fly at start up using the machine's regional settings, just as well as it seems to be working for currency symbols and formats.

The weird behavior of Access regarding embedded currency formats discussed in this thread does not apply to Date/Time formats.
If you use generic Date/Time formats (e.g. "Long Date") for your controls, Access will always use the Date/Time formats from Windows Regional settings of the current user of your application.

If you want to use Date/Time formats other than those from the regional settings you can use the Windows API to do the formatting. I wrote the text Formatting Date/Time for a specific language and country in Access and VBA about that topic.

If you want your application to handle multiple currencies at the same time, I would strongly advise not to use any currency formatting at all, but format all currency values as generic numbers and add the currency identifier (symbol or iso-code) in a separate control.

--------------------
A professional Access developer tool: Find and Replace for Access and VBA
Go to the top of the page
 
ztatzau
post Feb 29 2020, 01:59 PM
Post#43



Posts: 374
Joined: 4-April 07



Thanks PhilS! I appreciate your reply and the info you provided.
QUOTE
The weird behavior of Access regarding embedded currency formats discussed in this thread does not apply to Date/Time formats.
If you use generic Date/Time formats (e.g. "Long Date") for your controls, Access will always use the Date/Time formats from Windows Regional settings of the current user of your application.

I did notice, during my ACCDR testing, that some of my date controls on forms and reports appeared with the regional formats of the target machine (SA) while other controls retained their original (US) date formats.
I haven't dug into this issue yet, but from what you say, I'm guessing that the controls that adopted the SA date formats were formatted "Short Date, Long Date, etc.", whereas the controls that retained their US date formats are likely formatted as "mm/dd/yyyy", etc. Would you agree?

ZT
Go to the top of the page
 
PhilS
post Mar 1 2020, 09:45 AM
Post#44



Posts: 690
Joined: 26-May 15
From: The middle of Germany


QUOTE
I haven't dug into this issue yet, but from what you say, I'm guessing that the controls that adopted the SA date formats were formatted "Short Date, Long Date, etc.", whereas the controls that retained their US date formats are likely formatted as "mm/dd/yyyy", etc. Would you agree?

Yes, I agree; that is a very common problem.

If you are interested, I've got some more info on Date/Time in international scenarios in my article The Date Data Type in VBA and Access; but the already mentioned rule of using named format instead of explicit format strings is the most important.

--------------------
A professional Access developer tool: Find and Replace for Access and VBA
Go to the top of the page
 
ztatzau
post Mar 1 2020, 01:19 PM
Post#45



Posts: 374
Joined: 4-April 07



Thanks again PhilS!

I've saved both of the articles you mentioned and look forward to learning more about Date/Time formatting for international use.

ZT
Go to the top of the page
 
3 Pages V < 1 2 3


Custom Search


RSSSearch   Top   Lo-Fi    31st March 2020 - 07:49 AM