ok, not on refresh . it would happen much too often. Simply when a view
is resized.
jostM
jostM wrote:
if View could have a user definable (does it already?) onRefresh
method, then this could be solved with something like the followig.
(might even work just using the resizeToFit adn reflow all methods).
Every flowview has a reflow flag which defaults to true.
1. on refresh set all flags to false. (using a class method)
2. if a view has flowview children do not resize/reflow .
3. if a view has no flowview, resize and reflow,
set its flag to true, and send a resize/reflow message to parent.
4. if a parent recieves a reflow message from a child, only reflow
if all child flag are true.
this would cause the resize/reflow to trickle up from the furthest
branches of the tree.
best,
jost
jostM wrote:
I'm convinced at this point that this has to do with the unpredicatable
order in which things get resized during a refresh. I have been able to
cure all of these things in my own gui by explicitly timed refresh
statements.
jost
felix wrote:
yeah but ironically enough it exhibits some of the same
bugs that it was designed to diagnose. and still hasn't cured :
disapearing buttons.
something to do with overlaps
this is non-obvious: when you click on a button it
highlights/changes-the-background-of the element on the
window-being-debugged. doesn't work for buttons though.
-fx
On Sat, Dec 13, 2008 at 8:45 PM, James
Harkins <jamshark70@xxxxxxxxx>
wrote:
Crucial.initLibraryItems;
Crucial.menu;
Click "Gui debugger," then click on the name of your
window.
hjh
On Dec 13, 2008, at 2:34 PM, LFSaw wrote:
Woa the f.!
have. to. know.
how. its. called. *gasp*
: H. James Harkins
.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
|