On Thu, May 30, 2013, at 08:30 PM, Steve Mills wrote:
> Just tried it. Didn't work. I also used NSEventTrackingRunLoopMode, since
> that's the current run loop when tracking a menu. I wish Apple had more
> people on these lists that can give definitive answers to our questions.
> It sure would help
On May 30, 2013, at 18:44:46, Shane Stanley wrote:
> Have you looked at -nextEventMatchingMask:untilDate:inMode:dequeue:? As in:
>
> NSEvent *event;
> while ((event = [NSApp nextEventMatchingMask:NSAnyEventMask
> untilDate:nil inMode:NSDefaultRunLoopMode dequeue:YES]))
> {
>
On Thu, May 30, 2013, at 06:49 AM, Steve Mills wrote:
> I assume drawing can't get flushed to the screen until control is
> returned to the tracking event loop? What I came up with works, but seems
> ridiculously inelegant. Is there some better way to give the current
> event loop time so I can hav
On 30/05/2013, at 11:49 PM, Steve Mills wrote:
> Is there some better way to give the current event loop time so I can have
> the drawing and canceling done right in my mouseUp handler?
Have you looked at -nextEventMatchingMask:untilDate:inMode:dequeue:? As in:
NSEvent *event;
I previously assumed I could simply draw my view a couple times with a delay
between, to simulate the quick flash that a menu item does when you choose it.
Of course, so many things have to be difficult in the world of Cocoa. I assume
drawing can't get flushed to the screen until control is retu
On May 29, 2013, at 18:46:18, Lee Ann Rucker
wrote:
> Don't delay the action/target part, write a wrapper function and delay that:
Heh, so simple. Thanks!
--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157
___
Cocoa-dev mai
On 30/05/2013, at 9:37 AM, Steve Mills wrote:
> On May 29, 2013, at 17:59:58, Graham Cox
> wrote:
>
>> This is normal. I think the idea is that the user gets a cue that whatever
>> action is being executed "came from" a menu choice, so the menu remains
>> visible while the action is carried
Don't delay the action/target part, write a wrapper function and delay that:
- (void)mouseUp:(NSEvent*)event
{
UNUSED_VAR(event);
NSMenuItem* item = [self enclosingMenuItem];
NSMenu* menu = [item menu];
// On mouseUp, we want to
On May 29, 2013, at 17:59:58, Graham Cox
wrote:
> This is normal. I think the idea is that the user gets a cue that whatever
> action is being executed "came from" a menu choice, so the menu remains
> visible while the action is carried out.
That's totally untrue. When an item is chosen, the
On May 29, 2013, at 18:06:45, Lee Ann Rucker
wrote:
> Use performSelector:withObject:afterDelay:0 to push your response to the end
> of the run loop, giving the UI a chance to update first. It's what I do when
> a button (etc) is going to trigger something that won't be instantaneous,
> where
Use performSelector:withObject:afterDelay:0 to push your response to the end of
the run loop, giving the UI a chance to update first. It's what I do when a
button (etc) is going to trigger something that won't be instantaneous, where
the button shouldn't keep showing in the pressed state while i
On 30/05/2013, at 8:41 AM, Steve Mills wrote:
> but the menu is not closing before the action executes
This is normal. I think the idea is that the user gets a cue that whatever
action is being executed "came from" a menu choice, so the menu remains visible
while the action is carried out.
I have an NSView subclass that's used to draw contents of a menu item. When I
get a mouseUp in my view, I need to flash the hilite (I'm guessing just draw it
a couple times with a short delay between draws), dismiss the menu and perform
the action associated with the item. These seem like the ri
13 matches
Mail list logo
