• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Weird behavior - Script saved as application...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Weird behavior - Script saved as application...


  • Subject: Re: Weird behavior - Script saved as application...
  • From: kai <email@hidden>
  • Date: Sun, 9 Apr 2006 23:42:21 +0100


On 7 Apr 2006, at 21:36, Paul Berkowitz wrote:


The result is an integer (like 23), not text. So

    (count of characters of _day)

should error, since an integer does not have any characters. But in a script editor, at least, the result is 0, not an error. The script editor (Script Debugger does the same thing) is doing some sort of coercion here. 'count of' is actually itself an alternative form of the command 'count' - it's not a property. So I guess it's counting the symbol 7 or something like that - the result is always 0. I suspect that the command 'count' is being directed to the application running the script - Script Editor - which is scriptable. so instead of getting an error you're getting whatever Script Editor has been programmed to do for counting an integer - 0. When saved as an application, you get the error, as you should. In either case you ought to realize you're not getting the answer you want. In Script Editor, where the result is 0, the bad parentheses you're using then gets you this:

    (count of characters of _day) as text
   --> 0 as text
    --> "0"

which is, of course less than 2. But you're going to get the exact same result ("0") if _day = 23.

This behaviour is quite interesting. I agree with Paul's reasoning that 'count characters of [some number]' should really error. After all, it's not quite the same as something like:


--------------
count integers of {"text", 1.2, current date, {value:12}, path to desktop} --> 0
--------------


Composite values, such as lists, records and text, contain elements. Simple values, such as integers, real numbers and Booleans, don't. (In the above case, it just so happens that the list contains no items of class integer - so the result is correct.) Composite values can respond to certain commands (such as 'count'), while simple values can't (or at least, as I understand it, *shouldn't*).

If the target of the count command is evaluated first, the expression results in an error number -1728 [errAENoSuchObject]:

--------------
characters of 7 --> "Can't get every character of 7."
--------------
count (get characters of 7) --> "Can't get every character of 7."
--------------

So it seems curious that the following statements produce the results they do:

--------------
count characters of 7 --> 0
--------------
count (characters of 7) --> 0
--------------
count 7 --> 0
--------------

(Incidentally, the same result is returned for any simple value - such as: 'count true', 'count (path to desktop)', etc.)

As we know, the count command functions both as an AppleScript command or an application command. The AppleScript command counts the number of elements of a particular class in a composite value (list, record, or string) - while the application command counts the number of elements of a particular class in an object or objects.

Where no class is specified for the result, the default value is 'item' (for lists, records, and application objects) or 'character' (for strings). Where an expression evaluates to a composite value, the 'count' command is performed internally - otherwise an event is passed to the current application for evaluation. This is evident from Script Editor's Event Log:

-----

count {1, 2, 3}
--> 3 [items]

(* Event Log:
[empty] *)

-----

count {firstName:"Bart", lastName:"Simpson"}
--> 2 [items]

(* Event Log:
[empty] *)

-----

count firstName of {firstName:"Bart", lastName:"Simpson"}
--> 4 [characters]

(* Event Log:
[empty] *)

-----

Anything else is passed to the current application - whether or not a class and/or object parameter is specified:

-----

count windows
--> n

(* Event Log:
tell current application
count every window of current application
n
end tell

[where n = the number of open windows in the current app] *)

-----

count name
--> 1

(* Event Log:
tell current application
count every name of current application
1
end tell
 *)

-----

count (get name)
--> 13 [when run from Script Editor]

(* Event Log:
tell current application
get name
"Script Editor"
end tell
*)

-----

count
--> 0

(* Event Log:
tell current application
count current application
0
end tell
*)

-----

The last example is significant. Quite a few applications respond similarly (and incorrectly, IMO) to an unspecified object parameter. However, since its default target is the desktop, Finder is one exception (even though it may also return a zero value if the desktop contains no items):

-----
tell application "System Events" to count --> 0
tell application "TextEdit" to count --> 0
tell application "Mail" to count --> 0
tell application "Safari" to count --> 0
tell application "Dictionary" to count --> 0
tell application "Finder" to count --> [number of desktop items]
-----

In most cases, the response to a 'nonsense' statement is similar - almost as if the object parameter is ignored:

-----
tell application "System Events" to {count characters of 7, count 7} --> {0, 0}
tell application "TextEdit" to {count characters of 7, count 7} --> {0, 0}
tell application "Mail" to {count characters of 7, count 7} --> {0, 0}
tell application "Safari" to {count characters of 7, count 7} --> {0, 0}
tell application "Dictionary" to {count characters of 7, count 7} --> {0, 0}
-----


Finder, perhaps more sensibly, responds with an error number -1727 [errAENotAnObjSpec], indicating that it does not recognise the object parameter as a valid object:

-----
tell application "Finder" to count characters of 7 --> "Finder got an error: Expected a reference."
tell application "Finder" to count 7 --> "Finder got an error: Expected a reference."
-----


All this serves to remind us of the constant need to be aware of what we're doing with parentheses and coercions in our statements. Nevertheless, a timely error message would certainly help to keep us on track - and it's perhaps worth comparing the current behaviour with that of pre-Mac OS X systems. In AppleScript 1.8.3 / Script Editor 1.8.3 / Mac OS 9.1, for example, every permutation results in an error number -1708 [errAEEventNotHandled]:

-----
count characters of 7
--> "every character of 7 doesn't understand the count message."
-----
count 7
--> "7 doesn't understand the count message."
-----
count
--> "«script» doesn't understand the count message."
-----

I've filed a bug in relation to the current behaviour.

Coming back briefly to Bernardo's script I'll just add this to the suggestions already made:

-----
tell (current date) to tell (10000 + day * 100 + (its month) as string) & year to ¬
set dataDeHoje to text 2 thru 3 & "." & text 4 thru 5 & "." & text 6 thru -1
-----


---
kai


_______________________________________________ Do not post admin requests to the list. They will be ignored. Applescript-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Re: Weird behavior - Script saved as application... (From: Paul Berkowitz <email@hidden>)

  • Prev by Date: Re: Dynamic Handler Call
  • Next by Date: Re: Dynamic Handler Call
  • Previous by thread: Re: Weird behavior - Script saved as application...
  • Next by thread: Re: Weird behavior - Script saved as application...
  • Index(es):
    • Date
    • Thread