Home » Eclipse Projects » GEF » GEF Editor freezes when ContextMenu is to be displayed (solved)
| GEF Editor freezes when ContextMenu is to be displayed (solved) [message #157591] |
Wed, 10 November 2004 21:10  |
Eclipse User |
|
|
|
Originally posted by: usenet.jevopi.de
Hi,
I added ContectMenu support to my GEF based editor. I simply copied the
code from the logic example, folliwing Back/Gamma hint "monkey sees,
monkey does". When running the editor and performing a right click, the
CintextMenu was shown and the editor freezed.
I found another thread here in June "GEF Editor pop-ups freeze
workbench (3.0RC2, GEF3 build I20040615)" with the same problem. I've
found the bug in my case. But I recognized that I dodn't understand the
paint/repaint mechsnism of Draw2D.
First my bug (it was my bug I assume): I have a comment figure just
like the StickyNote figure in the logic example.
It paints a rectangle with a dogear and contains some text (in a
TextFlow) - the body of the comment. This is the buggy code:
private TextFlow textflow;
private Comment comment; // this is the model
protected void paintFigure(Graphics graphics) {
textflow.setText(comment.getBody());
...
// paint rectangle with dogear
...
}
This caused an infinite repaint loop - but only if a context menu pops
up. Before adding the ContextMenu, the editor worked fine, and I have a
lot of stuff flying around there...
After moving the text update to the repaint function, the editor worked:
public void repaint() {
textFlow.setText(comment.getBody)
super.repaint();
}
protected void paintFigure(Graphics graphics) {
...
// paint rectangle with dogear
...
}
I know I know... the "setText" invalidates the TextFlow, the
UpdateManager adds an invalid figure and, I don't know which instance,
repaints again...
I'm wondering why the code worked without a context menu. I could
resize the comment, move it
I'm still not sure if the repaint() method is the right place for
updating the text...
The JavaDoc isn't very helpful here, can you tell me what all these
repaint and paint methods are doing and where to put what?
I don't understand the (Abstract) EditPart methods refesh,
refreshChildren and refreshVisuals as well... The monkey in me says
"Don't worry about it, your editor is running", but I'm a little bit
afraid of the next ContextMenu freezing my editor...
Jens
|
|
|
| Re: GEF Editor freezes when ContextMenu is to be displayed (solved) [message #157608 is a reply to message #157591] |
Wed, 10 November 2004 21:57  |
| Eclipse User |
|
|
|
Originally posted by: boris.bokowski.de
Hi Jens,
don't let your figures (the view part of model-view-controller) depend on
your model. View objects should not reference any model objects or
controller objects (EditParts).
It is the EditPart that updates its figure. This is what refreshVisuals() is
for. But who calls refreshVisuals() and when? Indirectly, your model objects
call it, but without making your model classes dependent on the EditParts:
To decouple your model classes and the EditParts, you need some kind of
notification mechanism. It is your choice which notification mechanism you
use. If in doubt, make your EditPart class implement
java.beans.PropertyChangeListener. Each model class defines
addPropertyChangeListener(PropertyChangeListener l) and
removePropertyChangeListener(PropertyChangeListener l). You can use a
java.beans.PropertyChangeSupport object as a helper for each model object,
the model object just delegates the two calls to the helper. Make sure to
call helper.firePropertyChange() for every change - usually, each setter
calls helper.firePropertyChange.
Your EditPart would then implement java.beans.PropertyChangeListener.
Implement propertyChange() to call refreshVisuals(), activate() to register
your EditPart as a property change listener and deactivate() to deregister
it like this:
public void activate() {
super.activate();
((MyModelClass)getModel()).addPropertyChangeListener(this);
}
public void propertyChange(PropertyChangeEvent evt) {
refreshVisuals();
}
public void deactivate() {
((MyModelClass)getModel()).removePropertyChangeListener(this );
super.deactivate();
}
In refreshVisuals() then, use the text obtained from your model to update
the figure.
Hope this helps.
Boris Bokowski.
"Jens v. P." <usenet@jevopi.de> wrote:
> ...
> TextFlow) - the body of the comment. This is the buggy code:
>
> private TextFlow textflow;
> private Comment comment; // this is the model
>
> ...
>
> I'm still not sure if the repaint() method is the right place for updating
> the text...
>
> The JavaDoc isn't very helpful here, can you tell me what all these
> repaint and paint methods are doing and where to put what?
> I don't understand the (Abstract) EditPart methods refesh, refreshChildren
> and refreshVisuals as well... The monkey in me says "Don't worry about it,
> your editor is running", but I'm a little bit afraid of the next
> ContextMenu freezing my editor...
|
|
|
| Re: GEF Editor freezes when ContextMenu is to be displayed (solved) [message #157657 is a reply to message #157608] |
Thu, 11 November 2004 12:19 |
| Eclipse User |
|
|
|
Originally posted by: usenet.jevopi.de
Hi Boris,
On 2004-11-10 22:57:15 +0100, "Boris Bokowski" <boris@bokowski.de> said:
> don't let your figures (the view part of model-view-controller) depend
> on your model. View objects should not reference any model objects or
> controller objects (EditParts).
There are several implementation or, better to say, interpretations of
the MVC pattern. Of course it's possible that view objects reference
model objects. In some cases this might not be necessaray, e.g. if only
a few properties are to be displayed. But IMHO it's one of the ideas in
the MVC pattern: Let the controller initialize and change the model,
and let the view display the model. In most MVC model diagrams there's
a dependency from the view to the model.
> It is the EditPart that updates its figure. This is what
> refreshVisuals() is for. But who calls refreshVisuals() and when?
> Indirectly, your model objects call it, but without making your model
> classes dependent on the EditParts:
Yes and no :) IMHO it's the "Controller" that updates the model first.
Using GEF the controller is spread over a lot of classes, usually it
should be a Command or Action updating the model. Then the EditPart is
notfied by the model, and the EditPart calls refreshVisuals(): There's
no constraint what refreshVisuslas() is actually doing. In some cases,
it's delegating changes in the model to the view -- that's what you
suggests -- in other cases it calls the repaint() method of the figure
(that was "included" in my question) so that the view can update
itsself.
> To decouple your model classes and the EditParts, you need some kind of
> notification mechanism.
I'm using UML2 and other EMF based models using the EMF notification
mechanism :) BTW: Too bad that EMF's Adapter and GEF's
ConnectionEditPart both define "getTarget()" :(
> In refreshVisuals() then, use the text obtained from your model to
> update the figure.
If it would be text only... I really don't want to add all attributes
of the model to the figure and delegeate all changes to the figure.
Most of the attributes are displayed and processed using the reflection
mechansim of EMF. That's another effect of letting figures depend on
the model: The interface between controller and view becomes smaller.
This helps me developing the controller and figures more separately
which leads to more agile development.
Back to my origin question:
EditPart.refreshVisuals() calls, directly or indirectly,
Figure.repaint(). That's right? Or is revalidate() a better solution?
Ah.. the JavaDoc says no, revalidate() doesn't guarantee that a repaint
will occur. But why, e.g., does the TextFlow class call revalidate()
and repaint() in its setText() method()? Why not only repaint() (BTW:
The JavaDoc only tells me that a revalidate() occur...). Why
revalidate() a figure, i.e. mark the figure invalid, if it doesn't
repaint the figure necessarily?
And why revalidate() the figure if the fiture is repainted anyway?
The bug teached me not to call repaint() inside the paintFigure()
method... sometime different to know when e.g. figuires children call
this method...
And when call refershChildren()? I can't imagine when this could become
necessary? Maybe there are some use cases different from mine :) Except
from when the editor is initialized (the model loaded).
Jens
|
|
|
| Re: GEF Editor freezes when ContextMenu is to be displayed (solved) [message #157689 is a reply to message #157657] |
Thu, 11 November 2004 15:19 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
I don't understand. Who is calling repaint() on your figure, which causes
the text to get pushed down? If you want the figure to have a reference to
the model, then why doesn't it just observe the model? If the editpart is
observing the model, then it should push the text to the figure, not call
repaint.
You should have a single setText() method, and it needs to call both
repaint() and revalidate(). If you remove the model reference, you can use
this figure with other applications or other models besides Comment.
"Jens v. P." <usenet@jevopi.de> wrote in message
news:cmvlcr$oj9$1@eclipse.org...
> Hi Boris,
>
> On 2004-11-10 22:57:15 +0100, "Boris Bokowski" <boris@bokowski.de> said:
>
> > don't let your figures (the view part of model-view-controller) depend
> > on your model. View objects should not reference any model objects or
> > controller objects (EditParts).
>
> There are several implementation or, better to say, interpretations of
> the MVC pattern. Of course it's possible that view objects reference
> model objects. In some cases this might not be necessaray, e.g. if only
> a few properties are to be displayed. But IMHO it's one of the ideas in
> the MVC pattern: Let the controller initialize and change the model,
> and let the view display the model. In most MVC model diagrams there's
> a dependency from the view to the model.
>
> > It is the EditPart that updates its figure. This is what
> > refreshVisuals() is for. But who calls refreshVisuals() and when?
> > Indirectly, your model objects call it, but without making your model
> > classes dependent on the EditParts:
>
> Yes and no :) IMHO it's the "Controller" that updates the model first.
> Using GEF the controller is spread over a lot of classes, usually it
> should be a Command or Action updating the model. Then the EditPart is
> notfied by the model, and the EditPart calls refreshVisuals(): There's
> no constraint what refreshVisuslas() is actually doing. In some cases,
> it's delegating changes in the model to the view -- that's what you
> suggests -- in other cases it calls the repaint() method of the figure
> (that was "included" in my question) so that the view can update
> itsself.
>
> > To decouple your model classes and the EditParts, you need some kind of
> > notification mechanism.
>
> I'm using UML2 and other EMF based models using the EMF notification
> mechanism :) BTW: Too bad that EMF's Adapter and GEF's
> ConnectionEditPart both define "getTarget()" :(
>
> > In refreshVisuals() then, use the text obtained from your model to
> > update the figure.
>
> If it would be text only... I really don't want to add all attributes
> of the model to the figure and delegeate all changes to the figure.
> Most of the attributes are displayed and processed using the reflection
> mechansim of EMF. That's another effect of letting figures depend on
> the model: The interface between controller and view becomes smaller.
> This helps me developing the controller and figures more separately
> which leads to more agile development.
>
> Back to my origin question:
>
> EditPart.refreshVisuals() calls, directly or indirectly,
> Figure.repaint(). That's right? Or is revalidate() a better solution?
> Ah.. the JavaDoc says no, revalidate() doesn't guarantee that a repaint
> will occur. But why, e.g., does the TextFlow class call revalidate()
> and repaint() in its setText() method()? Why not only repaint() (BTW:
> The JavaDoc only tells me that a revalidate() occur...). Why
> revalidate() a figure, i.e. mark the figure invalid, if it doesn't
> repaint the figure necessarily?
> And why revalidate() the figure if the fiture is repainted anyway?
> The bug teached me not to call repaint() inside the paintFigure()
> method... sometime different to know when e.g. figuires children call
> this method...
>
> And when call refershChildren()? I can't imagine when this could become
> necessary? Maybe there are some use cases different from mine :) Except
> from when the editor is initialized (the model loaded).
>
> Jens
>
|
|
|
| Re: GEF Editor freezes when ContextMenu is to be displayed (solved) [message #158016 is a reply to message #157689] |
Sun, 14 November 2004 17:18 |
| Eclipse User |
|
|
|
Originally posted by: usenet.jevopi.de
Randy, Boris,
thank you for your replies. I've developped web-applications in the
last years, so I have to get back to "rich clients"...
My Editpart- and Figure-structure is not finished yet, I'm testing
different designs, and thus I was looking for an easy and general way
of refreshing the figures.
Your answers helped me rethinking my design and helped me a lot.
Still, I don't know the difference between Figure.revalidate() and
Figure.repaint(). Why are both methods called together?
Jens
On 2004-11-11 16:19:31 +0100, "Randy Hudson" <none@us.ibm.com> said:
> I don't understand. Who is calling repaint() on your figure, which causes
> the text to get pushed down? If you want the figure to have a reference to
> the model, then why doesn't it just observe the model? If the editpart is
> observing the model, then it should push the text to the figure, not call
> repaint.
>
> You should have a single setText() method, and it needs to call both
> repaint() and revalidate(). If you remove the model reference, you can use
> this figure with other applications or other models besides Comment.
>
> "Jens v. P." <usenet@jevopi.de> wrote in message
> news:cmvlcr$oj9$1@eclipse.org...
>> Hi Boris,
>>
>> On 2004-11-10 22:57:15 +0100, "Boris Bokowski" <boris@bokowski.de> said:
>>
>>> don't let your figures (the view part of model-view-controller) depend
>>> on your model. View objects should not reference any model objects or
>>> controller objects (EditParts).
>>
>> There are several implementation or, better to say, interpretations of
>> the MVC pattern. Of course it's possible that view objects reference
>> model objects. In some cases this might not be necessaray, e.g. if only
>> a few properties are to be displayed. But IMHO it's one of the ideas in
>> the MVC pattern: Let the controller initialize and change the model,
>> and let the view display the model. In most MVC model diagrams there's
>> a dependency from the view to the model.
>>
>>> It is the EditPart that updates its figure. This is what
>>> refreshVisuals() is for. But who calls refreshVisuals() and when?
>>> Indirectly, your model objects call it, but without making your model
>>> classes dependent on the EditParts:
>>
>> Yes and no :) IMHO it's the "Controller" that updates the model first.
>> Using GEF the controller is spread over a lot of classes, usually it
>> should be a Command or Action updating the model. Then the EditPart is
>> notfied by the model, and the EditPart calls refreshVisuals(): There's
>> no constraint what refreshVisuslas() is actually doing. In some cases,
>> it's delegating changes in the model to the view -- that's what you
>> suggests -- in other cases it calls the repaint() method of the figure
>> (that was "included" in my question) so that the view can update
>> itsself.
>>
>>> To decouple your model classes and the EditParts, you need some kind of
>>> notification mechanism.
>>
>> I'm using UML2 and other EMF based models using the EMF notification
>> mechanism :) BTW: Too bad that EMF's Adapter and GEF's
>> ConnectionEditPart both define "getTarget()" :(
>>
>>> In refreshVisuals() then, use the text obtained from your model to
>>> update the figure.
>>
>> If it would be text only... I really don't want to add all attributes
>> of the model to the figure and delegeate all changes to the figure.
>> Most of the attributes are displayed and processed using the reflection
>> mechansim of EMF. That's another effect of letting figures depend on
>> the model: The interface between controller and view becomes smaller.
>> This helps me developing the controller and figures more separately
>> which leads to more agile development.
>>
>> Back to my origin question:
>>
>> EditPart.refreshVisuals() calls, directly or indirectly,
>> Figure.repaint(). That's right? Or is revalidate() a better solution?
>> Ah.. the JavaDoc says no, revalidate() doesn't guarantee that a repaint
>> will occur. But why, e.g., does the TextFlow class call revalidate()
>> and repaint() in its setText() method()? Why not only repaint() (BTW:
>> The JavaDoc only tells me that a revalidate() occur...). Why
>> revalidate() a figure, i.e. mark the figure invalid, if it doesn't
>> repaint the figure necessarily?
>> And why revalidate() the figure if the fiture is repainted anyway?
>> The bug teached me not to call repaint() inside the paintFigure()
>> method... sometime different to know when e.g. figuires children call
>> this method...
>>
>> And when call refershChildren()? I can't imagine when this could become
>> necessary? Maybe there are some use cases different from mine :) Except
>> from when the editor is initialized (the model loaded).
>>
>> Jens
|
|
|
| Re: GEF Editor freezes when ContextMenu is to be displayed (solved) [message #158020 is a reply to message #158016] |
Mon, 15 November 2004 00:48 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
in my experience validation has to do with sizing and bounds and layout,
while painting is just painting.
Jens v. P. wrote:
> Randy, Boris,
>
> thank you for your replies. I've developped web-applications in the last
> years, so I have to get back to "rich clients"...
> My Editpart- and Figure-structure is not finished yet, I'm testing
> different designs, and thus I was looking for an easy and general way of
> refreshing the figures.
> Your answers helped me rethinking my design and helped me a lot.
>
> Still, I don't know the difference between Figure.revalidate() and
> Figure.repaint(). Why are both methods called together?
>
> Jens
>
>
> On 2004-11-11 16:19:31 +0100, "Randy Hudson" <none@us.ibm.com> said:
>
>> I don't understand. Who is calling repaint() on your figure, which
>> causes
>> the text to get pushed down? If you want the figure to have a
>> reference to
>> the model, then why doesn't it just observe the model? If the
>> editpart is
>> observing the model, then it should push the text to the figure, not call
>> repaint.
>>
>> You should have a single setText() method, and it needs to call both
>> repaint() and revalidate(). If you remove the model reference, you
>> can use
>> this figure with other applications or other models besides Comment.
>>
>> "Jens v. P." <usenet@jevopi.de> wrote in message
>> news:cmvlcr$oj9$1@eclipse.org...
>>
>>> Hi Boris,
>>>
>>> On 2004-11-10 22:57:15 +0100, "Boris Bokowski" <boris@bokowski.de> said:
>>>
>>>> don't let your figures (the view part of model-view-controller) depend
>>>> on your model. View objects should not reference any model objects or
>>>> controller objects (EditParts).
>>>
>>>
>>> There are several implementation or, better to say, interpretations of
>>> the MVC pattern. Of course it's possible that view objects reference
>>> model objects. In some cases this might not be necessaray, e.g. if only
>>> a few properties are to be displayed. But IMHO it's one of the ideas in
>>> the MVC pattern: Let the controller initialize and change the model,
>>> and let the view display the model. In most MVC model diagrams there's
>>> a dependency from the view to the model.
>>>
>>>> It is the EditPart that updates its figure. This is what
>>>> refreshVisuals() is for. But who calls refreshVisuals() and when?
>>>> Indirectly, your model objects call it, but without making your model
>>>> classes dependent on the EditParts:
>>>
>>>
>>> Yes and no :) IMHO it's the "Controller" that updates the model first.
>>> Using GEF the controller is spread over a lot of classes, usually it
>>> should be a Command or Action updating the model. Then the EditPart is
>>> notfied by the model, and the EditPart calls refreshVisuals(): There's
>>> no constraint what refreshVisuslas() is actually doing. In some cases,
>>> it's delegating changes in the model to the view -- that's what you
>>> suggests -- in other cases it calls the repaint() method of the figure
>>> (that was "included" in my question) so that the view can update
>>> itsself.
>>>
>>>> To decouple your model classes and the EditParts, you need some kind of
>>>> notification mechanism.
>>>
>>>
>>> I'm using UML2 and other EMF based models using the EMF notification
>>> mechanism :) BTW: Too bad that EMF's Adapter and GEF's
>>> ConnectionEditPart both define "getTarget()" :(
>>>
>>>> In refreshVisuals() then, use the text obtained from your model to
>>>> update the figure.
>>>
>>>
>>> If it would be text only... I really don't want to add all attributes
>>> of the model to the figure and delegeate all changes to the figure.
>>> Most of the attributes are displayed and processed using the reflection
>>> mechansim of EMF. That's another effect of letting figures depend on
>>> the model: The interface between controller and view becomes smaller.
>>> This helps me developing the controller and figures more separately
>>> which leads to more agile development.
>>>
>>> Back to my origin question:
>>>
>>> EditPart.refreshVisuals() calls, directly or indirectly,
>>> Figure.repaint(). That's right? Or is revalidate() a better solution?
>>> Ah.. the JavaDoc says no, revalidate() doesn't guarantee that a repaint
>>> will occur. But why, e.g., does the TextFlow class call revalidate()
>>> and repaint() in its setText() method()? Why not only repaint() (BTW:
>>> The JavaDoc only tells me that a revalidate() occur...). Why
>>> revalidate() a figure, i.e. mark the figure invalid, if it doesn't
>>> repaint the figure necessarily?
>>> And why revalidate() the figure if the fiture is repainted anyway?
>>> The bug teached me not to call repaint() inside the paintFigure()
>>> method... sometime different to know when e.g. figuires children call
>>> this method...
>>>
>>> And when call refershChildren()? I can't imagine when this could become
>>> necessary? Maybe there are some use cases different from mine :) Except
>>> from when the editor is initialized (the model loaded).
>>>
>>> Jens
>
>
>
--
Respectfully,
CL Gilbert
"Verily, verily, I say unto you, He that entereth not by the door() into
the sheepfold{}, but climbeth up some other *way, the same is a thief
and a robber." John 10:1
GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD 19AE 55B2 4CD7 80D2 0A2D
For a free Java interface to Freechess.org see
http://www.rigidsoftware.com/Chess/chess.html
|
|
|
| Re: GEF Editor freezes when ContextMenu is to be displayed (solved) [message #158096 is a reply to message #158016] |
Mon, 15 November 2004 16:52 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
A good question would be why doesn't revalidate() include repaint(). I
suppose there are a few rare cases where a figure makes a request for more
space, and if that request is not satisfied, there is no need to repaint.
Most examples I know of require repainting. For example, changing font,
adding a border, changing the icon on a label, etc.
"Jens v. P." <usenet@jevopi.de> wrote in message
news:cn8426$7ic$1@eclipse.org...
> Randy, Boris,
>
> thank you for your replies. I've developped web-applications in the
> last years, so I have to get back to "rich clients"...
> My Editpart- and Figure-structure is not finished yet, I'm testing
> different designs, and thus I was looking for an easy and general way
> of refreshing the figures.
> Your answers helped me rethinking my design and helped me a lot.
>
> Still, I don't know the difference between Figure.revalidate() and
> Figure.repaint(). Why are both methods called together?
>
> Jens
>
>
> On 2004-11-11 16:19:31 +0100, "Randy Hudson" <none@us.ibm.com> said:
>
> > I don't understand. Who is calling repaint() on your figure, which
causes
> > the text to get pushed down? If you want the figure to have a reference
to
> > the model, then why doesn't it just observe the model? If the editpart
is
> > observing the model, then it should push the text to the figure, not
call
> > repaint.
> >
> > You should have a single setText() method, and it needs to call both
> > repaint() and revalidate(). If you remove the model reference, you can
use
> > this figure with other applications or other models besides Comment.
> >
> > "Jens v. P." <usenet@jevopi.de> wrote in message
> > news:cmvlcr$oj9$1@eclipse.org...
> >> Hi Boris,
> >>
> >> On 2004-11-10 22:57:15 +0100, "Boris Bokowski" <boris@bokowski.de>
said:
> >>
> >>> don't let your figures (the view part of model-view-controller) depend
> >>> on your model. View objects should not reference any model objects or
> >>> controller objects (EditParts).
> >>
> >> There are several implementation or, better to say, interpretations of
> >> the MVC pattern. Of course it's possible that view objects reference
> >> model objects. In some cases this might not be necessaray, e.g. if only
> >> a few properties are to be displayed. But IMHO it's one of the ideas in
> >> the MVC pattern: Let the controller initialize and change the model,
> >> and let the view display the model. In most MVC model diagrams there's
> >> a dependency from the view to the model.
> >>
> >>> It is the EditPart that updates its figure. This is what
> >>> refreshVisuals() is for. But who calls refreshVisuals() and when?
> >>> Indirectly, your model objects call it, but without making your model
> >>> classes dependent on the EditParts:
> >>
> >> Yes and no :) IMHO it's the "Controller" that updates the model first.
> >> Using GEF the controller is spread over a lot of classes, usually it
> >> should be a Command or Action updating the model. Then the EditPart is
> >> notfied by the model, and the EditPart calls refreshVisuals(): There's
> >> no constraint what refreshVisuslas() is actually doing. In some cases,
> >> it's delegating changes in the model to the view -- that's what you
> >> suggests -- in other cases it calls the repaint() method of the figure
> >> (that was "included" in my question) so that the view can update
> >> itsself.
> >>
> >>> To decouple your model classes and the EditParts, you need some kind
of
> >>> notification mechanism.
> >>
> >> I'm using UML2 and other EMF based models using the EMF notification
> >> mechanism :) BTW: Too bad that EMF's Adapter and GEF's
> >> ConnectionEditPart both define "getTarget()" :(
> >>
> >>> In refreshVisuals() then, use the text obtained from your model to
> >>> update the figure.
> >>
> >> If it would be text only... I really don't want to add all attributes
> >> of the model to the figure and delegeate all changes to the figure.
> >> Most of the attributes are displayed and processed using the reflection
> >> mechansim of EMF. That's another effect of letting figures depend on
> >> the model: The interface between controller and view becomes smaller.
> >> This helps me developing the controller and figures more separately
> >> which leads to more agile development.
> >>
> >> Back to my origin question:
> >>
> >> EditPart.refreshVisuals() calls, directly or indirectly,
> >> Figure.repaint(). That's right? Or is revalidate() a better solution?
> >> Ah.. the JavaDoc says no, revalidate() doesn't guarantee that a repaint
> >> will occur. But why, e.g., does the TextFlow class call revalidate()
> >> and repaint() in its setText() method()? Why not only repaint() (BTW:
> >> The JavaDoc only tells me that a revalidate() occur...). Why
> >> revalidate() a figure, i.e. mark the figure invalid, if it doesn't
> >> repaint the figure necessarily?
> >> And why revalidate() the figure if the fiture is repainted anyway?
> >> The bug teached me not to call repaint() inside the paintFigure()
> >> method... sometime different to know when e.g. figuires children call
> >> this method...
> >>
> >> And when call refershChildren()? I can't imagine when this could become
> >> necessary? Maybe there are some use cases different from mine :) Except
> >> from when the editor is initialized (the model loaded).
> >>
> >> Jens
>
>
|
|
|
Goto Forum:
Current Time: Wed Feb 05 10:56:00 GMT 2025
Powered by FUDForum. Page generated in 0.04125 seconds |
] 
Search
Help
Register
Login
Home
