On Oct 19, 2013, at 9:27 AM, Jerry Krinock wrote:
>> I don't know if this is a common technique but I use it regularly to track
>> binding changes.
>>
>> - (void)setValue:(id)value forKeyPath:(NSString *)keyPath
>> {
>> // all bindings that reference self (such as self.representedObject.xxx)
>
On Oct 20, 2013, at 6:37 PM, Kyle Sluder wrote:
>> 2. However, shortcuts that are not connected to any menu item, like ⌘-E
>> or ⌘-R,
>
> In the default non-document template, ⌘E maps to Edit > Find > Use
> Selection for Find.
Ah, hadn't seen that. How about ⌘R?
>> only cause menuNeedsUpdate:
On Sun, Oct 20, 2013, at 01:14 PM, Charles Srstka wrote:
> I've played around with this a bit more, using the standard Xcode
> non-document app template, and its behavior is actually quite weird.
>
> 1. Typing a keyboard shortcut that's connected to one of the items
> currently in the menu works
> On Oct 20, 2013, at 7:21 AM, Martin Hewitson
> wrote:
>
>
>> On 20 Oct 2013, at 01:15 am, Kyle Sluder wrote:
>>
>> Rather than rely on intercepting responder chain-based validation, wouldn't
>> it be much easier and more reliable to make some object the delegate of all
>> of your NSMenus
On Oct 20, 2013, at 3:14 PM, Charles Srstka wrote:
> 5. Validation definitely does *not* fire for unmapped keyboard shortcuts. It
> only fires if the keyboard shortcut in question is already mapped to an item
> that performs an action on the object which called validateMenuItem:, so I
> stand
On Oct 20, 2013, at 2:50 PM, Charles Srstka wrote:
> On Oct 20, 2013, at 2:37 PM, Ken Thomases wrote:
>
>> On Oct 20, 2013, at 2:29 PM, Charles Srstka wrote:
>>
>>> -menuNeedsUpdate: has the same problem that -validateMenuItem: has. It
>>> doesn't get called until the menu is about to be actua
On Oct 20, 2013, at 2:46 PM, "Mills, Steve" wrote:
>> On Oct 20, 2013, at 14:38, "Ken Thomases" wrote:
>>
>> This isn't correct. Menus are updated/validated when resolving keyboard
>> shortcuts. What makes you think otherwise? Lots of things wouldn't work if
>> that weren't so.
>
> For wh
On Oct 20, 2013, at 2:37 PM, Ken Thomases wrote:
> On Oct 20, 2013, at 2:29 PM, Charles Srstka wrote:
>
>> -menuNeedsUpdate: has the same problem that -validateMenuItem: has. It
>> doesn't get called until the menu is about to be actually drawn, which
>> doesn't happen until the user clicks on
> On Oct 20, 2013, at 14:38, "Ken Thomases" wrote:
>
> This isn't correct. Menus are updated/validated when resolving keyboard
> shortcuts. What makes you think otherwise? Lots of things wouldn't work if
> that weren't so.
For what it's worth, Cocoa's key equiv updating doesn't always work
> On Oct 20, 2013, at 12:37 PM, Ken Thomases wrote:
>
>> On Oct 20, 2013, at 2:29 PM, Charles Srstka wrote:
>>
>> -menuNeedsUpdate: has the same problem that -validateMenuItem: has. It
>> doesn't get called until the menu is about to be actually drawn, which
>> doesn't happen until the user c
On Oct 20, 2013, at 2:29 PM, Charles Srstka wrote:
> -menuNeedsUpdate: has the same problem that -validateMenuItem: has. It
> doesn't get called until the menu is about to be actually drawn, which
> doesn't happen until the user clicks on your menu.
This isn't correct. Menus are updated/valida
On Oct 20, 2013, at 2:02 PM, Kyle Sluder wrote:
>> On Oct 20, 2013, at 4:21 AM, Martin Hewitson
>> wrote:
>>
>>
>>> On 20 Oct 2013, at 01:15 am, Kyle Sluder wrote:
>>>
>>> Rather than rely on intercepting responder chain-based validation, wouldn't
>>> it be much easier and more reliable to
On Oct 19, 2013, at 9:44 PM, Trygve Inda wrote:
> How can I look at myPredicate and determine that it uses dynamicPropertyA?
>
> Is it enough and safe to use [myPredicate predicateFormat] and then search
> the resulting string for dynamicPropertyA?
Once you have an NSPredicate, you can use the
> On Oct 20, 2013, at 4:21 AM, Martin Hewitson
> wrote:
>
>
>> On 20 Oct 2013, at 01:15 am, Kyle Sluder wrote:
>>
>> Rather than rely on intercepting responder chain-based validation, wouldn't
>> it be much easier and more reliable to make some object the delegate of all
>> of your NSMenus
OK, I tried the suggestion to do the update in windowDidBecomeKey and this
works nicely with the following (perhaps a little ugly) code:
- (void) specialiseCloseMenu:(BOOL)state {
NSMenu *mainMenu = [[NSApplication sharedApplication] mainMenu];
NSMenu *fileMenu = [[mainMenu itemAtIndex:1] su
On 20 Oct 2013, at 01:15 am, Kyle Sluder wrote:
> Rather than rely on intercepting responder chain-based validation, wouldn't
> it be much easier and more reliable to make some object the delegate of all
> of your NSMenus and implement -menuNeedsUpdate:?
>
But wouldn’t this object then need
16 matches
Mail list logo
