AppleScript throws an error when creating a new status object

[mtimmsj]

When trying to create a new status in Adium 1.2 with the following AppleScript, an error is thrown:

tell application "Adium" to set myStat to (make new status with properties {status type:away, title:"I'm not here", message:"I'm not here", autoreply:"Your message will be read when I return"})

The error is: Adium got an error: Can’t make application "Adium" into type specifier.

The status is actually created and available to be used. However, this error would cause a script to crash

[jas8522]

Matt: is this by design since the command changed?

[applmak]

I can't seem to duplicate this bug. Can you provide instructions for doing so?

[mtimmsj]

I'm not doing anything beyond what I've described. Once Adium is up and running I simply try to run this in Script Editor:

tell application "Adium" to set myStat to (make new status with properties {status type:away, title:"I'm not here", message:"I'm not here", autoreply:"Your message will be read when I return"})

I've tried it on an updated build based on the latest svn and have the same results.

[applmak]

I can't seem to make this bug happen from SVN. Can anyone else?

[jas8522]

I can reproduce it - running exactly that command (copy/paste) into Script Editor results in the exact error described in the initial report. Like the report says, the status does get created. applmak are you using Tiger? Perhaps it only occurs on Leopard..

[applmak]

Yes, I'm running Tiger. Several things changed Applescript-wise in 10.5, so I'll need to check the release notes.

[evands]

[AIApplication makeStatusWithProperties:] does return an AIStatus and it does get added to the status controller's array, but I get the same error (10.5).

[applmak]

In order to debug this, I need someone running 10.5 to follow the directions here:  http://developer.apple.com/documentation/Cocoa/Conceptual/ScriptableCocoaApplications/SApps_debugging/chapter_9_section_4.html#//apple_ref/doc/uid/TP40001981-1081764

Try to make a new status and when it fails, send me the resulting Console.app output. Or, just put it here.

[evands]

tell application "Adium"
	set myStat to (make new status with properties {status type:away, title:"I'm not here", message:"I'm not here", autoreply:"Your message will be read when I return"})
end tell

results in:

1/14/08 1:24:06 AM Adium[9925] Command: Adium Suite.make
 Direct Parameter: (null)
 Receivers: (null)
 Arguments:     {
        KeyDictionary =         {
            scriptingAutoreply = "Your message will be read when I return";
            scriptingMessage = "I'm not here";
            scriptingTitle = "I'm not here";
            statusTypeApplescript = 1398896505;
        };
        ObjectClass = 1131639923;
    }
 Container Specifier For Created Object: <top level object>
 
1/14/08 1:24:06 AM Adium[9925] Returning <AIStatus: 9165dc0 [I'm not here]> (10); {(
    <AIStatus: 8802b10 [I'm not here]>,
    <AIStatus: 9165dc0 [I'm not here]>,
    <AIStatus: 750d70 [/intaway]>,
    <AIStatus: 72347a0 [Available]>,
    <AIStatus: 88031a0 [I'm not here]>,
    <AIStatus: 723c980 [Offline]>,
    <AIStatus: 72a14a0 [I'm not here]>,
    <AIStatus: 8803d20 [I'm not here]>,
    <AIStatus: 72345a0 [♫ iTunes]>,
    <AIStatus: 8802820 [I'm not here]>,
    <AIStatus: 723c810 [Invisible]>,
    <AIStatus: 8803520 [I'm not here]>,
    <AIStatus: 88039a0 [I'm not here]>,
    <AIStatus: 723c830 [Away]>
)} 
1/14/08 1:24:06 AM Adium[9925] Result: <NSUniqueIDSpecifier: statuses with an ID of "10"> 
1/14/08 1:24:06 AM Adium[9925] Error: -1700 "(null)" 

(The returning line is debug logging I added earlier).

[mtimmsj]

Here's an example of the same output from Tiger where this bug is not seen.

2008-01-14 02:06:19.169 Adium[20923] Command: Adium Suite.make
	Direct Parameter: (null)
	Receivers: (null)
	Arguments: {
        KeyDictionary = {
            scriptingAutoreply = "Your message will be read when I return"; 
            scriptingMessage = "I'm not here"; 
            scriptingTitle = "I'm not here"; 
            statusTypeApplescript = 1398896505; 
        }; 
        ObjectClass = 1131639923; 
    }
	Container Specifier For Created Object: <top level object>
2008-01-14 02:06:19.286 Adium[20923] Result: <NSUniqueIDSpecifier: statuses with an ID of "40">

[applmak]

Thanks for the output, but I still can't track down the bug. This is what I know so far:

* The status is definitely being created correctly, and added correctly.
* - [AIStatus objectSpecifier] is returning the correct uniqueID for the status.
* - [AIApplication statuses] is definitely returning the correct array of statuses, 
  which should allows cocoa scripting to find the status given the ID.

However, only the first two points are confirmed valid on Leopard given the above input. I don't have a Leopard computer to test this, yet, so someone else needs to find this bug: Set a breakpoint at those places specified and run Evan's simple script from above. Does everything look okay? Esp. in -[AIApplication statuses].

[mtimmsj]

I am not familiar enough with objective-c or xcode to do the debugging that is requested.

In the latest 1.3svn on MacOSX 10.5.2, I have tried to run this same test script to create a status and now I get "Adium got an error: AppleEvent handler failed." I've tried restarting both Adium and script editor. With global AppleScript debugging enabled I get the following in the log:

Feb 11 16:25:09 Adium[1401]: Command: Adium Suite.make
	Direct Parameter: (null)
	Receivers: (null)
	Arguments:     {
        KeyDictionary =         {
            scriptingAutoreply = "Your message will be read when I return";
            scriptingMessage = "I'm not here";
            scriptingTitle = "I'm not here";
            statusTypeApplescript = 1398896505;
        };
        ObjectClass = 1131639923;
    }
	Container Specifier For Created Object: <top level object>
Feb 11 16:25:09 Adium[1401]: *** -[AIStatus setutoReplyString:]: unrecognized selector sent to instance 0x927c950
Feb 11 16:25:09 Adium[1401]: An exception was thrown during execution of an NSScriptCommand...
Feb 11 16:25:09 Adium[1401]: *** -[AIStatus setutoReplyString:]: unrecognized selector sent to instance 0x927c950
Feb 11 16:25:09 Adium[1401]: Result: (null)
Feb 11 16:25:09 Adium[1401]: Error: -10000 "(null)"

[evands]

In the 1.3svn output above, a typo was present in the code -- see setutoReplyString? That's not present in my current source and I can't find any evidence of this being a problem at some point in the past. Do a find on setutoReplyString in your source... where is that? is it a change you made?

[mtimmsj]

Thanks evands, looks like I somehow deleted a character while I was trying to figure out how to debug this issue. Fixed it in my local copy. Sorry for the noise.

[evands]

No problem. So what's your status (pardon the pun) in pristine 1.3svn? In particular, how does it differ from your 10.4 output wherein the applescript command worked properly?

[mtimmsj]

It is the same as on Tiger except it still returns an error:

2/18/08 12:25:14 PM Adium[29598] Command: Adium Suite.make
 Direct Parameter: (null)
 Receivers: (null)
 Arguments:     {
        KeyDictionary =         {
            scriptingAutoreply = "Your message will be read when I return";
            scriptingMessage = "I'm not here";
            scriptingTitle = "I'm not here";
            statusTypeApplescript = 1398896505;
        };
        ObjectClass = 1131639923;
    }
 Container Specifier For Created Object: <top level object>
 
2/18/08 12:25:14 PM Adium[29598] Result: <NSUniqueIDSpecifier: statuses with an ID of "72"> 
2/18/08 12:25:14 PM Adium[29598] Error: -1700 "(null)" 

[applmak]

(In [25251]) YES! This fixes #8863, which has been on my plate forever. Woot!

As it turns out, using a private API here worked in 10.4, but in 10.5, it set the error condition on the apple event. In the future, a rewriting of the applescript stuff to take advantage of the new 10.5 features is definitely in order.

[Robby]

I set 1.3.2 expecting you'd merge, Matt. :)

[applmak]

Well... since this only affected 10.5, it shouldn't be backported, and should be included in 1.4