On 2008-12-14, at 21:09:08, Chris Page wrote:
Do you have any radar numbers for those? Or a quick summary of the problems?
It's exactly as above. I believe I only wrote to the "other" Chris but there was no reply for that specific item.
I will have to prepare a special package for you because the affected area has been somewhat dismantled in order to try to pinpoint the problem. I think the earliest I could do this is by next weekend and I will forward you the bug id. Meantime, if you have a minute, one long-standing bug for third party OSA components is: < radr://5584810> "Script Editor: can't open double-clicked scripts not in the default language". This is marked as a duplicate of < radr://4911673>. I believe this problem affects all third party components.
By “OSA components” do you mean scripting additions (OSAX) that install event handlers in the Apple Event handler table, or do you mean Component Manager scripting components, for which there is an API for intercepting calls to other components?
OSAExecuteEvent() et. al. are in OSA.h
I'm sorry if I'm repeating myself, but what do you mean by “component”? Are you aware of something called the Component Manager, which is used to implement OSA and AppleScript? Are you referring to those sorts of “components”? Are you referring to scripting additions (OSAX)? Are you using the term to loosely refer to software you've written that installs event handlers? Coercion handlers? I don't understand what you're referring to with enough detail to answer your question.
I mentioned "OSA components" in my previous post: < http://lists.apple.com/archives/applescript-users/2008/Dec/msg00207.html> ("OSAExecuteEvent() and it's immediate companions to be specific. Leopard messed up the cursor handling for my OSA components…").
OSA.h is the header file for OSA components and OSAExecuteEvent() can be regarded as the principal call for OSA components to deal with AppleEvents (depending on how one structures their interface). So I'm definitely aware of the component manager and I'm talking about OSA components. Sorry for any confusion.
In any case, the issue is one of where we send scripting addition command Apple Events. If a script has a scripting addition command within an application tell block, that command goes to the target application. What if we change it so that addition commands are handled within the process running the script even when inside a tell block? Does that affect your software?
Like I said before, I'm not sure because the AppleScript component is involved and my components both delegate and override events.
As an AppleScript user, my opinion about the general case is that I agree with the other folks who think it's _not_ a good plan to whack modal capability. Modal dialogs are a fundamental UI requirement (i.e. password before proceeding). Just a wild guess, but if you're in a pinch for a modal box which might serve in a chain of asynchronous facilities in a larger context which doesn't want to be disturbed, I'm wondering if CFUserNotificationDisplayAlert() and CFUserNotificationDisplayNotice() would be viable alternatives.
Well, the way I understand it right now, I would actually need both behaviors. For instance, if I implement a Mail rule, it's really weird to call 'display dialog' (from the component in the rule handler) because Mail is running its AppleEvents on a thread. But if 'display dialog' is in a droplet, then I can use my override or not according to the situation.
“from the component in the rule handler”? I don't understand your use of the word “component” in that context. Are you referring to the script?
No. I'm referring to invoking a 'display dialog' via AppleEvents directly from an OSA component when a Mail rule is being acted on. I use them to report errors to the user.
What is the nature of your “override”? How does it accomplish “overriding”? What, exactly, does it override? What is it's relationship to ‘display dialog’ and Mail rule scripts?
I handle emal/cmpa and if there is an error running the script, I notify the user by invoking a display dialog if any portion returns an error.
I'm sorry if I sound dense. I really don't understand what you're trying to say.
Frankly, it's difficult to put succinctly without the reader having some a priori knowledge. Here's a brief outline.
Goal: implement an arbitrary language (not AppleScript) in an OSA component such that:
1. It handles all the currently valid selectors in OSA.h 2. It handles all requests from Script Editor, osacompile, osascript, and Script Debugger and runs correctly when deployed as a script, applet, droplet or .applescript. 3. When in applet/droplet form, handle the required AppleEvents, the extra ones like 'pref', any from the various pre-installed osaxen (syso/dlog e.g.) as your component capabilities permit. 4. As a bonus, implement a few useful things like native folder actions and mail rules. 5. As a bonus, implement some UI capabilities -- document windows, dialogs, menus, custom drawing views, open and save, etc. -- so that users can control them and run actions in their native language.
Perhaps what I'm trying to say is that in the particular case of a mail rule, I could probably chat with Hamish about them and not have to mention OSAExecuteEvent(), or emal/cmpa because in an OSA component, there's only one route to get to the point of handling them and he would know about them before I wrote.
So, I think it best if I follow your bug report suggestion and hope that at least the manifested high level behaviors might give you some insights.
I think I could say on behalf of folks making components that we'd really appreciate it if you or another member of the AppleScript team could look into OSA issues and consider modernization. Of course it's some amount of speculation on my part, but if the suggestion about keeping things close to the CoreServices level in the framework hierarchy is possible, then at least some form of scripting through OSA components could be available the iPhoneSDK as well.
Philip Aker
Democracy: Two wolves and a sheep voting on lunch. |