Re: [gef-dev] AbstractEditPart.refresh()

[Randy Hudson <hudsonr@xxxxxxxxxx>]

You should use the newsgroup for these
types of questions
news://news.eclipse.org/eclipse.tools.gef

What is the dependency on the other
existing children? The dependency should be expressed as a constraint (if
needed), and the placement of the child figure should be done in the layout
manager, not the editpart.  Layout will occur after all updates have
been processed.

Richard Clark <rdclark@xxxxxxxxxxxxxxxx> Sent by: gef-dev-admin@xxxxxxxxxxx 05/01/2003 01:06 PM Please respond to gef-dev

To:        <gef-dev@xxxxxxxxxxx>         cc:                 Subject:        [gef-dev] AbstractEditPart.refresh()

One of the editors I'm building needs to calculate
a position for each new child based on the existing children, but the current
implementation of AbstractEditPart.refresh() makes that difficult. 

Ideally (or so I think), adding/removing a child would happen in two stages
-- the child gets added or removed (from refreshChildren()) then the display
is updated to match (refreshVisuals()). But the implementation calls refreshVisuals()
before refreshChildren(), with changes made in refreshChildren() not triggering
a subsequent call to refresh(). I'm curious about this design decision
and wonder if these two calls should be reversed in 2.2.

Until then, I'm overriding refresh(), calling super.refresh(), and then
adjusting the new child visuals. (Sugegstions for doing this "the
right way" gratefully accepted).

..Richard

_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/gef-dev