I’m working on rewriting an Applescript app in Objective-C but I’d like to keep the interface as close as possible to the Applescript version. Is there a Cocoa class that will allow me to create a menu identical to “choose from list”?
Applescript “Choose from list” menu dialog:
set chosenItem to (choose from list {"a", "b", "c"})
How would I create the same thing in Obj-C? Which class would I use?
note: I’d like to do it programmatically if possible.
choose from list uses an NSTableView.
Good luck with that – setting up a table view in code is a lot of work. Use a .xib/.nib and save your sanity.
It’s not even difficult at all. You just have to create NSTableColumns, NSTableView and NSScrollView. Then add these objects to your view. Set delegate to self and use NSTableView delegate methods to fill the table view. Since the TS asked for Objective-C here’s an example on how to create an NSTableView (copied from SO)
You really don’t use ARC ??
Like the post I copied it from, I don’t use ARC either. But I forgot that most of the Objective-C developers do. Thanks for the heads-up I have improved my post above.
The post is 5 years old before ARC was introduced.
5 years ago there was GC, but I didn’t use that either for the same reasons.
Ah, I missed that. But there’s still a lot more work to be done to get a working table, especially view-based.
I guess I fail to see what’s wrong with using a .xib. In fact, the table I’m working on at the moment uses four of them…
Me too, even if it’s needed to be shown on-the-fly there is nothing wrong with using an xib file. Maybe he thinks it’s needed because the ScriptingAddition.osax doesn’t use xib files either, but that’s not a solid argument because choose from list is a dirty “hack”.
Well choose from list is part of a scripting addition, so it’s a dirty hack by definition 
But StandardAdditions.osax does use nibs, including one called ChooseFromList.nib. In fact, using that from a third-party app might be an interesting challenge for the OP. (I believe choose from list is even using autolayout and a view-based table these days.)
I know you think they are 
Thanks, I always thought they were created by code (explains the missing symbols I was looking for in the Mach-O executable to know what kind of code each command is using).
And I know Apple thinks they are, too
That may have been the case once, but I suspect a lot of the standard additions stuff has been rewritten in recent years. Just from a localization POV, these days nibs make a lot more sense.
Anyway, for anyone following along, the reason I’ve been spending a lot of time with tables lately is that I’m writing a script library to show table dialogs. So using this library:
display table with data {"One", "Two", "Three", "Four", "Five"}
will give you something like choose from list, while this:
display table with data {{true, "One"}, {false, "Two"}, {true, "Three"}, {false, "Four"}, {true, "Five"}} editable columns {1} with empty selection allowed
will give you editable checkboxes next to each entry. And there are about a zillion other optional parameters.
So if anyone wants to do some testing, please email me. And if anyone can help out with localization – say, any Dutch or German speakers :), for example – I’d love to hear from them too.
I see I’ve sparked a rather lively discussion that I won’t pretend I completely understand. I only asked the question because I was interested in learning how to do things programmatically (and I was under the impression that it was the better way to go). Also I wanted to be able to scale the window size based on the column height of the table which is something determined at run time. I wasn’t sure if that could be done in interface builder (but I wouldn’t be surprised it it could be done).
I was able to piece together a table with the code provided by DJ Bazzie Wazzie (translated into Swift) but I haven’t tried populating the list yet. What more would I need. It seems to look functional to me.
I’m only a dabbler, but i’ve seen the issue come up several times on the Cocoa mailing list. Each time, the advice from experienced programmers has been near-unanimous: don’t do it.
Have a look at the inspectors in Xcode for a scroll view, table view, and associated bits and pieces. When you use a .nib, all the properties they represent get set. Unless you do the same in code, or you particular defaults are documented, you’re writing fragile code that can break at any time.
It’s a personal preference, as Shane mentioned most will advice you not to use it. The person who asks this questions is assumed not an experienced programmer, otherwise you wouldn’t ask the question in the first place. However there are good reasons not to use nib files. FireFox for example creates most of it’s GUI on the fly, try to click a sub menu of the main menu using AppleScript and System Events. You can’t because there is no menu when it’s not visible.
Another reason why people will advice you to use nibs is because Apple does it as well, which is kind of stupid argument. Keep that in mind when downloading example code from Apple, they will always create a simple example code in the least time as possible and often broken or unstable (They have fooled me again in short time when listing processes in AppleScript Toolbox.osax). Also using a nib hides code and fewer lines of code will be interpreted as easier by many. But the fact that Apple almost never create GUI by code doesn’t mean it’s bad.
Creating GUI in code will increase development time so why would you still use it? Well for one very clear reason, it will decrease debugging time because code becomes better readable and handing projects over to others will clearly indicate how everything works. The example code above will explain how the interface looks like without being bothered with an nib file you have to look in. When projects from others are handed over I find it myself quite difficult to understand how everything works especially with serialized objects/archives (like nib files). Most important for me would be that you can set break points when creating the interface which is impossible when using nib files.
So there is no better or worse in this.
You are right, I am not experienced. In fact, this is my first attempt at build an app written entirely in Swift (or obj-c). However I’ve found that attempting to do it programmatically has taught me a lot more about object oriented programming than using nibs would have. I’m coming from working mostly with Applescript Script Editor so I appreciate being able to see everything in the code. Will I do it programmatically every time? No. I probably won’t do it at all once I learn how to use interface builder. But I already feel like I understand a lot more about what’s going on under the hood - the difference between a NSView and NSWindow, how NSButton/NSTextView/NSTable objects become subviews, how classes inherit from other classes, etc. Seeing it all in code solidifies my understanding of what’s really going on.
That argument is completely in line why some people don’t use nibs at all. It makes code better readable with less pre-knowledge than using nibs. So I guess you continue without nibs then 
From AppleScript to another more professional programming language can be quite difficult. Programming languages like AppleScript kind of mutilate your brain and can be very difficult to learn other programming languages afterwards. So writing it in a verbose way as you prefer is highly recommendable.
Good luck with your project!
Oddly enough, in most cases I’ve seen on the Cocoa mailing list it’s been experienced programmers, new to Cocoa. It seems their comfort with coding everything drives the assumption.
Maybe the term “experienced programmer” was too general, because of the context I meant of course an (Mac) desktop programmer and not an experienced PHP/MySQL programmer.
FYI, the project I referred to earlier in this thread is Myriad Tables Lib, which is now freely available.