Writing an Arduino/Barometer App in Cocoa-AppleScript after taking a year or two off Xcode.
Had trouble connecting a menu item to a function in the AppDelegate.
It seems to be a general issue that: AppDelegate will not reveal a function* for targeting as sent/received action through the xib’s Connections Inspector UNLESS the function’s code is inset by at least one tab in the source file. Non-indented functions don’t even show up when I right-click on the AppDelegate object itself. Leftmost alignment seems reserved for words like script and end script.
Is this a known Cocoa-AppleScript parsing oddity, that everyone else already knows to avoid, or do I have a flaky 5.0.2 installation that’s going to cause me further headaches?
Seems to me that if Xcode’s going to be picky about tab depth it should at least throw a warning about ‘sloppy coding style.’
*Function, Method, handler, whatever they call the things these days:
beep {}
return
----
----
on beep {} -- <-- Function, method, handler
say "beep"
end beep
----
----
Second, here’s an actual, simple AppDelegate that shows the problem behavior:
Note that the starting tab depth of “on test2_(sender)” and “on showcentigrade_(sender)” is zero.
When I attempt to hook a .xib button up to the AppDelegate via right-click and drag, neither “test2:” or “showcentigrade:” show up in the AppDelegate popup of potential Received Actions.
Tabbing in the functions by one in the source fixes that absence.
Removing those added tabs causes them to disappear from the AppDelegate’s popup again.
Odd, no?
Yes, that _ vs : is a new annoyance, but not half as bad as AppleScript’s refusal to accept // or /* */ for commenting purposes.
Both functions are indented on the source page, and then show up in AppDelegate’s popup.
Things act like the leftmost part of the source page is reserved for the likes of “script AppDelegate” and “end script”.
I’ve no problem with that, but a little yellow triangle with an exclamation mark, or at least a comment in the documentation would’ve been nice.
Sure, but it looks to me that the cleaned up appearance isn’t just for neatness/readability, it’s also a requirement for proper IDE behavior. I’ll be more attentive to it henceforth.
Using an external editor avoids these sorts of problems, as well as things like trying to call a handler beep(). Without it, it’s easy to do things like have variables using different case in different places, resulting in all sorts of difficult-to-trace bugs.
And with the underscore syntax in Mavericks, it’s a bigger issue, given the increased risk of terminology clashes.