Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Live content questions

On Nov 28, 2003, at 2:07 AM, Erik Dahlstrom wrote:

Is it possible to get a Carbon RAEL app to continue in the main event loop while menus are open?

Not currently. The Menu Manager runs its own nested event loop during menu tracking.

On Nov 28, 2003, at 8:27 AM, Erik Dahlstrom wrote:

I'll take an example instead: I have a networking thread that posts events to the main event queue and those events are picked up by an eventhandler that only handles that kind of event. When a menu is down I get no events in that eventhandler even though the network thread still posts events. (For debugging I set a global flag when menutracking begins and I clear it when menutracking ends. When the flag is set I get no events in my eventhandler.)

The nested event loop run by the Menu Manager only removes a select number of events from the event queue - mouse events and key events, mostly. The Menu Manager doesn't know about your custom events, so it doesn't remove them from the queue; they stay in the queue until menu tracking has finished.

As noted, Carbon event loop timers do fire during menu tracking, so one possibility would be to install a timer instead of posting an event, and handle your incoming network data in the timer.

On Nov 28, 2003, at 9:42 AM, Dario Accornero wrote:

That is indeed strange, and it would seem to imply that standard menu tracking does not use one of the TrackMouseLocation APIs -- I guess only Eric or someone from HIToolbox could confirm this -- or that non-system events are not dispatched during menu tracking...

The menu tracking loop does not use TrackMouseLocation (it just calls ReceiveNextEvent directly), but even if it did use TML, you still wouldn't get custom Carbon events dispatched, because TML doesn't dispatch custom carbon events either - like the Menu Manager's nested event loop, it only pulls a small set of events from the event queue.

On Nov 28, 2003, at 2:07 AM, Erik Dahlstrom wrote:

Also, if I'm dragging a carbon window (Standard window event handlers, document window type, non-compositing) is it possible to have live updating of the window contents? (For that I'd also need the main event loop to continue as normal). I see that for example Camino is able to continue loading a page and display the progress while I'm dragging the window around. Is that a feature that can be done only in Cocoa apps?

You can achieve redraw during window drag and menu tracking in Carbon apps also.

Live resizing is no problem, that's been working a long time (with kWindowLiveResizeAttribute as you mentioned).
It's live updating when a menu is open, and live updating when dragging a window around that are issues.

The easiest way to achieve this is to use compositing mode.

If you can't use compositing mode, then assuming you're using Carbon events (kEventWindowUpdate or kEventWindowDrawContent) to draw your window, the next easiest way is to install a timer when you do something that invalidates your window content, and in your timer, simply create a kEventWindowUpdate event, add the appropriate parameters, and send it to the window that requires updating.

If you're WaitNextEvent-based and you don't use Carbon events to draw your window content, then you could again use the timer, but you could simply call BeginUpdate, draw, and EndUpdate. That's really all that happens when you send the kEventWindowUpdate event anyways.

On Nov 28, 2003, at 9:21 AM, David Duncan wrote:

I think you are right Dario, AsyncDrag should only affect drag events. I think my confusion was coming from the fact that you also get bounds changing events during drag - with async drag you will get fewer of these kinds of bounds changing (or at least are supposed to from what I understand).

Correct, the AsyncDrag attribute only causes window dragging to occur asynchronously. Window resizing _always_ occurs synchronously inside the window's creating process. With async drag enabled, you'll only get bounds-changed events when the user stops moving the mouse; when the mouse idles, the WindowServer sends a bounds-changed event to the client process containing the window's current position.

If you are expecting Update events, you won't get many of them (if any at all) during menu tracking on Mac OS X.

Correct, update events are not sent to windows during menu tracking. (Although I do have a bug requesting that this be changed.) However, if you have a compositing window, since compositing windows are updated automatically whenever the event loop runs, composited windows _will_ redraw during menu tracking. That's why the easiest solution that I suggested above is just to use compositing mode - do that, and updates will occur automatically.

-eric
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Live content questions (From: Erik Dahlstrom <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.