Question for non English OS users?
in [Visual Basic]
|
Prev: AAC/M4A VB Tag Decoder Source Code ??
Next: re label
From: Helmut Meukel on 28 Jun 2010 14:14 "Kevin Provance" <k(a)p.c> schrieb im Newsbeitrag news:i0a9e1$k52$1(a)news.eternal-september.org... > "Henning" <computer_hero(a)coldmail.com> wrote in message > news:i09vm7$lml$1(a)news.eternal-september.org... > : > : Anyone surprized? M$ supports country specific locales, but their own > : programmers say: oohhh, are there other countries than US. ;) > : > > In all fairness, when installing common support files in a companies own > folder, does the language of the directory really matter? Part of the ideal > of system folders and using their CSIDL is to avoid the problem of > multi-lingual installs, references and the like (and other obvious reasons). > But when dealing with installing my own support files, I would stick them > under %COMMON FILES%\<company name> even if it translates to something else > in another language. That would be a nightmare to support! > Kevin, you missed the point. It doesn't matter if the directory name is localized or in English. However the install routines should behave consistently, at least for the same program. They should never ever put some files into the directory with the localized name and the next time - when updating the program - intall some new files into another directory with the english name which didn't exist until then and had to be created! Example1: \Programme\Gemeinsame Dateien\System\msadc \Programme\Common Files\System\Msadc For the latter they had to create 3 directories, because they didn't use the existing %COMMON FILES% which is "Gemeinsame Dateien" where the subdirectories already existed. Example 2: ....\Gemeinsame Dateien\Designer ....\Common Files\Designer in this case I don't know which was first. I bet if the program needs some of those files it will not find all, because they are in different directories. Helmut.
From: Kevin Provance on 28 Jun 2010 16:20 Okay, I see your point. You're absolutely right. What a PITA. <g> -- Customer Hatred Knows No Bounds at MSFT Free usenet access at http://www.eternal-september.org ClassicVB Users Regroup! comp.lang.basic.visual.misc Bawwk! Paulie want a dingleball, bawwk! "Helmut Meukel" <Helmut_Meukel(a)NoProvider.de> wrote in message news:i0aor6$jai$1(a)news.eternal-september.org... : "Kevin Provance" <k(a)p.c> schrieb im Newsbeitrag : news:i0a9e1$k52$1(a)news.eternal-september.org... : > "Henning" <computer_hero(a)coldmail.com> wrote in message : > news:i09vm7$lml$1(a)news.eternal-september.org... : > : : > : Anyone surprized? M$ supports country specific locales, but their own : > : programmers say: oohhh, are there other countries than US. ;) : > : : > : > In all fairness, when installing common support files in a companies own : > folder, does the language of the directory really matter? Part of the ideal : > of system folders and using their CSIDL is to avoid the problem of : > multi-lingual installs, references and the like (and other obvious reasons). : > But when dealing with installing my own support files, I would stick them : > under %COMMON FILES%\<company name> even if it translates to something else : > in another language. That would be a nightmare to support! : > : : : Kevin, you missed the point. : It doesn't matter if the directory name is localized or in English. : However the install routines should behave consistently, at least for the : same program. They should never ever put some files into the directory : with the localized name and the next time - when updating the program - : intall some new files into another directory with the english name which : didn't exist until then and had to be created! : Example1: : \Programme\Gemeinsame Dateien\System\msadc : \Programme\Common Files\System\Msadc : For the latter they had to create 3 directories, because they didn't use : the existing %COMMON FILES% which is "Gemeinsame Dateien" : where the subdirectories already existed. : Example 2: : ...\Gemeinsame Dateien\Designer : ...\Common Files\Designer : in this case I don't know which was first. : : I bet if the program needs some of those files it will not find all, because : they are in different directories. : : Helmut. :
From: Tony Toews on 28 Jun 2010 17:37 On Mon, 28 Jun 2010 09:47:07 -0400, "Kevin Provance" <k(a)p.c> wrote: >: Gotta love that word probably. <smile> But a few more responses >: should confirm that it hasn't been mucked with. The problem from my >: perspective is that it's Access DAO and ACE DLLS I want to check. >: And Office is definitely a multilingual app so who knows for sure what >: they've all done. > >Question: Besides the Access DLL, are the others DLL's AX DLL's or standard >(for lack of a better term) DLLs? The four DLLs I care about are all AFAIK ordinary DLLs. That said they're distributed by MS as part of Access or the OS so who really knows. <smile> Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Granite Fleet Manager http://www.granitefleet.com/
From: Tony Toews on 28 Jun 2010 17:38 On Mon, 28 Jun 2010 13:05:43 +0200, "Henning" <computer_hero(a)coldmail.com> wrote: >Anyone surprized? M$ supports country specific locales, but their own >programmers say: oohhh, are there other countries than US. ;) Well hold on a sec. That's not just a MS thing. That's an American thing. <smile> Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Granite Fleet Manager http://www.granitefleet.com/
From: Kevin Provance on 28 Jun 2010 17:50
"Tony Toews" <ttoews(a)telusplanet.net> wrote in message news:lf5i261er9mnmbg7999174js5lm884d66m(a)4ax.com... : : The four DLLs I care about are all AFAIK ordinary DLLs. That said : they're distributed by MS as part of Access or the OS so who really : knows. <smile> : Once, long ago, I had a popular VB app that used DAO, and the runtime DLL Hell used to keep me in support hell. This was back in the 9x days when system folders were in their infancy. I used to keep the DAO runtime in my apps folder with a .local file to force load that version, instead of looking elsewhere on the system. That was DAO350.DLL which was an AX DLL, or a hybrid DLL which had both AX and stdcalls. |