Upcoming changes to Palm Desktop scripting (2 of 2)
Upcoming changes to Palm Desktop scripting (2 of 2)
- Subject: Upcoming changes to Palm Desktop scripting (2 of 2)
- From: Chris Page <email@hidden>
- Date: Sat, 19 Apr 2003 15:19:12 -0700
[This is part 2 of a two-part message.]
An object can also be displayed using a previously obtained object
number. These numbers do not appear to change:
set n to 1
show address (object {object class:+class CONT;, object number:n,
object instance:-1})
Use the above with caution and only specify object numbers previously
obtained from PD.
Exactly. As I mentioned earlier, be very careful about poking directly
into the object properties record. In the next version, this isn't a
possibility. Instead, you'd just use:
show address 1 -- or address id 725
Also note that the 'object number' is an id not an index, and some ids
may be invalid. That is, there may be objects with numbers 1, 2, 5, and
7, but 3, 4, and 6 may be invalid, deleted items.
This opens the Date Book window to a daily view:
show day (current date) in window "Date Book"
There are a couple of changes here:
'day' conflicted with the date 'day' property, so I changed it to
'calendar day'.
The use of 'window "Date Book"' was a bit of a kludge in the code and
depended on the window titles for the three different Date Book views
being different (which is no longer true), and it was a little odd to
refer to them as separate windows when they appear to the user as a
single window (in fact, they are implemented as three separate windows,
but this is an internal detail that should not be relied upon). So,
I've replaced the 'in' parameter with a more-to-the-point 'date book'
parameter whose value can be 'daily', 'weekly', or 'monthly'.
The above example would be changed to:
show calendar day (current date) date book daily
[Unfortunately, as I write this I've discovered a bug: if the date book
view is set to weekly, the above doesn't change the view to daily. It
will only switch to daily if the view is monthly. Arg. Well, at least
all the other combinations seem to work.]
Getting data
This can be done one field at a time, which sends an AppleEvent for
each, or by getting records, such as all fields.
I've replaced 'all fields' with the standard 'properties' property and
improved the behavior. For example, if you set the 'properties'
property and it contains some read-only properties, you won't get an
error as long as the new values are the same as the old.
The most reliable way to get properties from the name info rec is to
call them directly.
'name info' was never really implemented correctly (IIRC). Although it
appears in the dictionary, there isn't really any code to handle it as
an object. It's just in the dictionary to visually group those
properties of address together when browsing the dictionary. You have
to use them directly as properties of address.
I've fixed this by eliminating 'name info' altogether. The various name
properties are now listed directly in list of address properties.
I've also gone to great lengths to make other objects like postal
addresses, phone numbers, and custom fields behave correctly.
mailing label of (primary address of address 0)
'mailing label' was somewhat ambiguous, so I changed it to 'formatted
address', which is also more consistent with the overall naming scheme.
As with other renamings like this, where the meaning of the term didn't
change, I've put the old term in an "Earlier Terms" suite so that old
term will compile, but it will decompile to the new term. Dictionaries
are nifty that way, no?
There really is no difference between the 'primary address' and the
'secondary address', so I renamed them to 'address one' and 'address
two', which also makes them consistent with the overall naming scheme
for address fields. In fact, if I'd had time I would have just changed
them into elements so you could use indexes to look them up, and you
could count them so we could add more addresses in the future without
breaking scripts. Same goes for the phone numbers and custom fields.
Ah, well.
primary category of address 0 as string -- returns a PD object without
the string coercion
Coercion of categories to strings is not supported. This will now
return an error instead of silently ignoring the request to coerce.
[I just noticed an interesting bug here: if there is no primary
category, it returns 'missing value'. If you leave the 'as string' in
place, it returns the string "msng", which is the four-character code
for 'missing value'. Odd.]
Note that supporting index 0 to mean "the item currently displayed in
the address detail window" is a bit of a kludge (this works for memos,
too). I left in support for this so as to not break existing scripts,
but I've added support for getting the selection and you should use
this when possible instead:
primary category of item 1 of (get selection)
What I really wanted to do was to add a property to the windows for
accessing the object they're currently displaying, but I didn't have
time.
Attaching 2 objects
...
attach (object myContact) to (object myTask) -- works, but errors
anyway on some systems
If you can reproduce the errors, please send me mail off-list with the
details. I haven't seen any unexpected errors here. It may be that I
fixed them without realizing it.
I've extended 'attach' so that you can attach a list of items, e.g.:
attach anItem to {thisItem, thatItem, theOtherItem}
Bugs & Workarounds
...
phone label of (phone 1 of address 0)
I've fixed this. IIRC, there didn't used to be code for correctly
handling references with "intermediate stopping points" like the above.
You had to remove the parenthesis from the above to get it to work.
BTW, I've replaced 'phone label' and 'address label' properties with
'label'. There was no reason for them to be different.
export to do into file "Disk:Folder:File"
I've removed support for 'export'. I didn't have time to get it working
with the new code, and since it didn't give you control over which
items and which properties were exported, nor the export format, I
figure you're probably better off just getting the items and properties
and generating whatever output you require.
The main issue for me with V2.6 and V4.0 is getting info from the
record returned by all fields, which is a property of most PD objects.
I used to get this record and then extract what I wanted out of it
without any further AppleEvents, which are relatively slow:
set addressRec to all fields of address 0 -- the displayed address,
can be used with most objects
set fullName to full informal name of name info of addressRec --
errors in V2.6.x and V4.0
I don't know what the problem was in 4.0, which should have fixed the
dictionary problems that were inadvertently introduced in 2.6.x, but
these work fine in the upcoming version, with some terminology changes:
set addressRec to properties of address 0
set fullName to full informal name of addressRec
Also note that index 0 only works for addresses and memos, to get the
item displayed in the corresponding detail window, although I don't
recall whether it worked for other classes in 4.0.
In closing, I'll note that compiled scripts should be easier to
transition than text scripts. When you decompile scripts with the new
version of Palm Desktop, most things that need changing will decompile
to "foo OBSOLETE" to highlight places in your script that need to be
updated.
Also, I've made many more changes in the terminology and in the
scripting implementation than I've noted here. Overall, it should be
much more sane, consistent, and in keeping with the spirit of
AppleScript. (Famous last words. :)
--
Chris Page - Software Wrangler - Palm, Inc.
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.