Not sure if this is possible or not.
I'd like to setup a window that has an editable text field along with a drop-down of options. If the user selects an item from the drop- down, that items value should populate the text field. When the user is done with the window I want whatever is in the text field, whether manually typed or pre-populated from the drop-down to be returned by tm_dialog.
This is similar to what Allan shows in his screencast, except that instead of an TSTableView I'm using an NSPopUpButton. Also, I want the NSTextField to be editable, but I don't want anything the user types there to update the NSAraryController/NSPopUpButton.
I've almost got this working. I've setup an NSArrayController that I'm populating via tm_dialog. I've bound the NSPopUpButtons's contentValues to the NSArray Controller. However, whenever I edit the text field it ends up updating the drop-down. Doh.
Also, I want to give this window working Cancel/Okay buttons.
Is this doable? Do I need to use IB Connections instead of bindings to tie the pop-up to the text field?
Hints/Tips appreciated,
j.
On 15. Nov 2006, at 00:10, Jay Soffian wrote:
[...] I've almost got this working. I've setup an NSArrayController that I'm populating via tm_dialog. I've bound the NSPopUpButtons's contentValues to the NSArray Controller. However, whenever I edit the text field it ends up updating the drop-down. Doh.
I don’t think there is any solution to that.
Also, I want to give this window working Cancel/Okay buttons.
Is this doable? Do I need to use IB Connections instead of bindings to tie the pop-up to the text field?
The cancel button, you can connect to the window’s performClose: or similar, i.e. hold control down, click the cancel button and hold left mouse button down, drag the connection line to the window object in the instances window, now release the mouse button and select performClose: in the target / action tab of the inspector window.
For the Okay button, you can either do what is described here [1] or, if you have a recent version of the plug-in, for the Okay button bind the target to the NSController object with model key being ‘controller’, then set selector to returnArgument: (the colon is important!).
You would then bind the argument also to the NSController, with the model key being that of the text being edited (or perhaps bind it to the array controller, and key being selected object or similar).
Note you can actually give it more than one argument, but you need to edit the selector name if you bind multiple arguments so that there is a «name»: for each argument in the name. Try open the New Project nib in the Xcode bundle to inspect the bindings there.
A nice thing about this approach is that one can bind many controls to the shared user defaults controller, then the value is stored in user defaults, and thus are sticky, and then bind these defaults values as arguments, so they will be available in the result of tm_dialog -- this is why the latest version of tm_dialog has an argument to set initial user defaults values.
[1] http://lists.macromates.com/pipermail/textmate/2006-October/ 014364.html
On Nov 14, 2006, at 6:22 PM, Allan Odgaard wrote:
I've almost got this working. I've setup an NSArrayController that I'm populating via tm_dialog. I've bound the NSPopUpButtons's contentValues to the NSArray Controller. However, whenever I edit the text field it ends up updating the drop-down. Doh.
I don’t think there is any solution to that.
That's too bad. I think you can see where I'm going with this from the attached pic. :-)
Got the Cancel/Process buttons working fine though.
I guess there's only so much that can be done w/o writing actual code. Any thoughts as to possibly having tm_dialog hook up a script to the NIB so that the script could be a controller for the NIB? Something along those lines...
j.
On 15. Nov 2006, at 02:05, Jay Soffian wrote:
[...] I guess there's only so much that can be done w/o writing actual code. Any thoughts as to possibly having tm_dialog hook up a script to the NIB so that the script could be a controller for the NIB? Something along those lines...
At that point, you got to ask yourself why use tm_dialog at all, i.e. why not write it in Objective-C or use one of the Python/Ruby Cocoa wrappers.
On Nov 15, 2006, at 8:57 AM, Allan Odgaard wrote:
At that point, you got to ask yourself why use tm_dialog at all, i.e. why not write it in Objective-C or use one of the Python/Ruby Cocoa wrappers.
True but then its windows wouldn't be owned by TextMate ... wasn't that part of the point of tm_dialog?
j.
On 15. Nov 2006, at 15:16, Jay Soffian wrote:
On Nov 15, 2006, at 8:57 AM, Allan Odgaard wrote:
At that point, you got to ask yourself why use tm_dialog at all, i.e. why not write it in Objective-C or use one of the Python/Ruby Cocoa wrappers.
True but then its windows wouldn't be owned by TextMate ... wasn't that part of the point of tm_dialog?
It was one of the advantages with the current implementation, yes. But the point with tm_dialog is to provide a simple way to bring up dialogs slightly more complex than what CocoaDialog offers -- while I do see a few possible evolutions of tm_dialog, like the ability to have it return and receive a new data model while the dialog is still up (using the stdin/out pipe), I don’t plan to extend it much further, as far better results can be obtained by simply writing “real” code instead of relying on what tm_dialog offers.
If your reason for wanting to pursue tm_dialog with callback hooks is to have windows owned by TM, then I think a better approach would be to look into extending the TM dialog server protocol with a method more suitable for callers who want to have code running while the dialog is up -- or perhaps more appropriately, introduce an API for dynamically loadable (and unloadable) plug-ins.
-
Allan Odgaard -
Jay Soffian