> On 21 May 2016, at 3:48 PM, Roland King <r...@rols.org> wrote: > > 1) putting the normal runloop mode back to test if your updates now do get > shown animated, that will assure you it’s the runloop mode causing it not > something else.
Running in normal, event-tracking or modal panel mode updates the window. > 2) with the code you have, override a drawRect: somewhere and see if > displayIfNeeded() is causing the drawRect:s to be called but the display > isn’t getting flushed or if displayIfNeeded() isn’t actually calling the > drawRect and other update methods. > 3) explicitly invalidate the view(s) to see if you can get displayIfNeeded() > to definitely do something. The view is definitely being marked dirty, and I’m explicitly calling -displayIfNeeded, and -drawRect: is getting called as a result. But the screen is not updated. I tried making an explicit call to flush the graphics context but that had no effect either. > On 21 May 2016, at 4:15 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > The problem, it seems to me, is that Graham is trying to *block* the main > event loop (except for … what?), and that’s bound to be a bad idea. I think > if I was trying to do something like this, I’d look into putting a modal > sheet over the window where the replay is happening, which will automatically > disable most user actions. (If there are multiple windows affected, it’s fine > to put a sheet over each of them. I’ve used this technique to display a > progress bar on all windows of a multi-window document. It has the advantage > of leaving the uninvolved windows fully functional.) > > The sheet doesn’t have to be big. It could be more like a badge, and there is > API to position it in a non-standard place, if obscuring the activity in the > window would be a problem. > > I guess it all comes down to what (other than menu items, if anything) Graham > really wants to lock out. Network activity? Performed selectors? This is some code that is retrofitted into an existing app that already implements Undo for pretty much anything the user can do, whether that’s in response to a menu command, changing a property through various interaces, or clicking and dragging in the main view. During this undo replay, I just want to make sure that the user can’t initiate any of these things in the middle of the replay, because that would surely be Bad™ (without really defining what Bad would mean in every case). That’s why I figured a custom mode would be the right solution - it allows this code to be bolted on without any part of the existing app to have to be revved to be aware of it. It turns out that what you’re proposing - a kind of dummy modal panel - can apparently be achieved by running the loop in NSModalPanelRunLoopMode. That convinces the rest of the app that a modal panel is there, even though it’s actually not. Clicks in menus or any other parts of my UI are ignored, and in this mode, windows are updated. So unless I’m mistaken, that’s the solution. The only thing that worries me is that because it’s not a fully custom mode, I don’t have complete control over its meaning or its effects. It may also be a total kludge that will be fragile in future. I’d still rather use a custom mode of my own, if the right magic can be found that allows screen updates in that mode. —Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
