Re: question about frame and bounds (mostly FIXED with a little problem)
Re: question about frame and bounds (mostly FIXED with a little problem)
- Subject: Re: question about frame and bounds (mostly FIXED with a little problem)
- From: j o a r <email@hidden>
- Date: Tue, 21 Oct 2003 07:29:05 +0200
On 2003-10-21, at 06.39, Ivan Kourtev wrote:
In order to quickly calculate the required window resizing using IB I
put the groups of interface objects that need to show or go away
[please see (a), (b) below] in an invisible box. Notably, as the
program runs, the progress indicator and the values of a bunch of text
fields (both with the invisible box) must be constantly updated. In
order for this to happen, however, I needed to do two things:
1 - send a [hiddenDisclosableBox displayIfNeeded] message to the NSBox
after every value update or progress bar update (I am not familiar
with the drawing system in detail but can justify the necessity for
this).
Always try to just flagging views for display, rather than actually
forcing them to draw, if possible. If you're in a lengthy synchronous
operation you need to trigger a display once in a while - as the built
in display machinery is triggered only at the end of the event loop
(which isn't allowed to run to competion until you're code has
completed to run) - but at least try to pool this as much as you can.
First flag all views that needs display:
[someView setNeedsDisplay: YES];
[someOtherView setNeedsDisplay: YES];
...and then once in a while:
[someSuperview displayIfNeeded];
2 - resize the main window (in order to expose the
hiddenDisclosableBox) with a [main_window setFrame:w_frame display:YES
animate:NO]; message.
Now this is puzzling. If I resize with animate:YES, then the updates
to the progress bar do NOT propagate until the entire process bar
fill-up is finished, which is when the progress bar is updated to full
state in one single shot.
Is that a known bug? Am I missing something?
This is a known bug, I've filed it under case # 3282161 for example. I
suggest you also file a bug via RadarWeb - to increase the possibility
that it will be fixed.
I think it is being linked to animating the window while being in a
lengthy synchronous operation where you don't allow the run loop to run
to completion. It is quite possible (but not certain) that you could
work around this by not starting your synchronous operation until after
the current run loop has ended, you can do that by starting it on a
delay:
[main_window setFrame:w_frame display:YES animate:YES];
[self performSelector: @selector(theLongSynchronousOperation)
withObject: nil afterDelay: 0.0];
...or perhaps 0.5 instead of 0.0, you can experiment a bit and see if
it makes any difference.
j o a r
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.