Re: Excel 2004 issue
Re: Excel 2004 issue
- Subject: Re: Excel 2004 issue
- From: Paul Berkowitz <email@hidden>
- Date: Sat, 19 Dec 2009 15:36:22 -0800
- Thread-topic: Excel 2004 issue
Title: Re: Excel 2004 issue
So, if I understand you correctly from your previous email, you are now lambasting Apple for the poor way they've implemented the scripting of Numbers and other apps in iWork, in particular the very bad or ignorant way they deal with multiple language versions. If I understand correctly, they insist on using different terms for different language versions, and do the non-English versions very badly. In addition, you're forced to create elaborate workarounds to accommodate multiple languages, though you've found a good solution below ("12.34 as text") for the specific issue of the decimal point.
But this thread started out with Excel, not Numbers, not Apple. From what I can see, Excel has taken the opposite route, and maintains one single vocabulary for all AppleScript versions, even where the UI maintains different versions for different languages, yes? In the issue you first asked about, it turned out that you need to use the comma (,) as parameter delimiter in formulas in AppleScript, even though the French version of Excel uses the semicolon (;) as parameter delimiter in the French UI. That's actually similar to what the AppleScript language does with real numbers - the period (.) is always the decimal point in AppleScript, even if your localized system uses the comma (,) throughout as per System Preference/International/Format. This actually works better since scripts will work the same everywhere. When you need to know the exact representation, you do your 'as text' conversion to get the comma. Similarly you don't need complicated translations for the names of formulas: it's always "COUNTIF", even in French.
OK. Now, what I actually asked you a while back was: in Excel (not Numbers), how do you represent a real number contained in a formula in AppleScript? The formula is text, in double quotes. Usually, in text in French, you'd use a comma "4,5". But if you do that, you'll have a confusion with the parameter delimiter, which we have established remains a comma, even in French Excel . For example, if there were some sort of formula that had "=COUNTIF(C8:C600,4,2)" that would be confusing. You might be able to find reverse workaround of "=COUNTIF(C8:C600,x)" where you previously set x to 4.2 as text. Or that might still error. But if Excel AppleScript is actually smart enough to let you write "=COUNTIF(C8:C600,4.2)", using the period (.) decimal even within quotes, even in French, then it would be very simple.
I'm very curious to know whether that "=COUNTIF(C8:C600,4.2)" works in Excel or whether there is a workaround that works.
--
Paul Berkowitz
From: Yvan KOENIG <email@hidden>
Date: Sat, 19 Dec 2009 20:35:52 +0100
To: AppleScript-Users <email@hidden>
Subject: Re: Excel 2004 issue
Le 19 déc. 2009 à 18:41, Paul Berkowitz a écrit :
But that's the issue: if you can think of some example that uses a literal number as a formula parameter, do you use a period or a comma for it within the quoted formula in AppleScript?
I forgot to respond to this question.
If I must pass a number in a formula I don't insert it directly.
Example:
If I need to build a formula like this one :
= 12.34 * 56.78
On a French system it must be
=12,34 * 56,78
To build a script behaving correctly on every setting
I build the formula:
"="& (12.34 as text)&"*"&(56.78 as text)
So, Numbers will receive the correct formula.
It works flawlessly, even with the setting used by Carlos Ysunza :
a Spanish system (with decimal comma) and Numbers used in English.
You may be surprised but in such a setting, Numbers use the English vocabulary but it use the decimal comma.
It's the same when I use Numbers in English on my French system.
>From my point of view, we have here a perfect design.
What is wrong is:
(1) the localization of several functions name
(2) the treatment of dates
(3) the treatment of the localized GUI items.
I built a script able to return the localized iWork's components menu item names.
It's an awful task because, as far as I know, there is no tool able to extract correctly these localized strings.
I was forced to build what I ask Apple to do: a set of resources containing these localized strings.
Chris Page wrote here about that:
A workaround might be to use the available command-line tools to harvest localized strings from the nibs and place them in *.strings files in your script bundle. This ties the script to a particular version of the target application, but could be updated automatically if you wrote a script to do it.
I always wait for infos about the way to "update automatically".
I know that I am not the only one which tried to do that but we got no result.
So, if Chris Page is able to post a sample code I will be glad to study it.
Yvan KOENIG (VALLAURIS, France) samedi 19 décembre 2009 20:35:47
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden