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
On 30/05/2013, at 11:49 PM, Steve Mills smi...@makemusic.com 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:
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 have
On May 30, 2013, at 18:44:46, Shane Stanley sstan...@myriad-com.com.au wrote:
Have you looked at -nextEventMatchingMask:untilDate:inMode:dequeue:? As in:
NSEvent *event;
while ((event = [NSApp nextEventMatchingMask:NSAnyEventMask
untilDate:nil inMode:NSDefaultRunLoopMode
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 to
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
On 30/05/2013, at 8:41 AM, Steve Mills smi...@makemusic.com 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
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
On May 29, 2013, at 18:06:45, Lee Ann Rucker lruc...@vmware.com
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
On May 29, 2013, at 17:59:58, Graham Cox graham@bigpond.com
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
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 30/05/2013, at 9:37 AM, Steve Mills smi...@makemusic.com wrote:
On May 29, 2013, at 17:59:58, Graham Cox graham@bigpond.com
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
On May 29, 2013, at 18:46:18, Lee Ann Rucker lruc...@vmware.com
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
13 matches
Mail list logo
