• 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: NSWindow class that allocs its own controller?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSWindow class that allocs its own controller?


  • Subject: Re: NSWindow class that allocs its own controller?
  • From: daniel <email@hidden>
  • Date: Fri, 8 Apr 2005 17:53:13 -0700

Oops - I had missed Fritz's response - so I'm especially glad for matt's follow up!

Fritz: I understand the advice in general that the model should be scripted instead of the UI. Some things are inextricably UI-oriented, though. Matt's examples are good. In my case, it's a "progress" window that I'll be providing to AppleScript clients. It's not something I can convey well in a model, nor do I think I should.

In this particular example, I'm basically exposing UI features to an AppleScript client. To dance around the fact that we're dealing with a window would be counter-productive, I think.

I can cause the window to be created and returned by way of a custom command, which I will probably do. I see the custom command as more of a convenience method, though. My thinking is that if I have a custom command that returns a custom class, I should also provide a mechanism for instaniating that class with the make command.

Right now the idea is that a client might issue a script like this:

tell application "FastScripts
set myWin to display progress message "Please Wait" at screen position top center minimum value 1 maximum value 100
set current value of myWin to 1
repeat with counter from 2 to 100
set current value of myWin to counter
delay 1
end
close myWin
end
end tell


I'd like to allow the user to also create this progress window with the make command.

Anyway, regardless of how you feel about whether I should be exposing UI control through AppleScript, the question remains as a general question for any kind of Cocoa class that is generated via a "factory" mechanism of some kind. How does one reconcile that kind of instantiation with a scripting model that expects everything to be able to "make itself" ???

Daniel


On Apr 7, 2005, at 9:37 AM, Matt Neuburg wrote:

On Wed, 6 Apr 2005 22:12:20 -0500, Fritz Anderson <email@hidden>
said:
I don't know of any application whose scripting interface
includes "make new window."

tell application "Finder" activate make new Finder window end tell

tell application "BBEdit"
    activate
    make new text window
end tell

m.
-- matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide
<http://www.amazon.com/exec/obidos/ASIN/0596005571/somethingsbymatt>




_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
sweater.com


This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Re: NSWindow class that allocs its own controller? (From: Matt Neuburg <email@hidden>)

  • Prev by Date: Re: Subclassing a "shared" class object.
  • Next by Date: Re: Best approach: Hotkey and Pasteboard application
  • Previous by thread: Re: NSWindow class that allocs its own controller?
  • Next by thread: event/notification for focus?
  • Index(es):
    • Date
    • Thread