| RE: [cdt-core-dev] ICElementDelta Shortage |
Answer: The JDT compares the ElementInfo before and after a parse by asking WorkingCopy.makeConsistent. This is done by the reconciler and on a save (from what I've seen so far). The reconciler also fires off the element change event (save doesn't...)
This appears to be a much different strategy than the CDT has taken. Should we be aligning our strategies with the JDT here or did the CDT dev team run into problems with it?
Cheers,
Doug Schaefer
Senior Staff Software Engineer
Rational - the software development company
Ottawa (Kanata), Ontario, Canada
-----Original Message-----
From: Alain Magloire [mailto:alain@xxxxxxx]
Sent: Tuesday, December 03, 2002 9:59 AM
To: cdt-core-dev@xxxxxxxxxxx
Subject: Re: [cdt-core-dev] ICElementDelta Shortage
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C29A74.3EABDE50
> Content-Type: text/plain
>
> Hey gang,
>
>
>
> In our mucking around, we noticed that the ElementDelta you get on an
> element changed event doesn't go into anymore detail than the file level.
> This was surprising since the JDT goes right down to the individual Elements
> that changed in the file. Is this intentional or there an item on the To Do
> list to make the delta more complete.
>
On the todo list,
Question, how JDT do it?
The only thing, I could see is that you do the modification via a WorkingCopy
handle. The model can not keep track of every single IFile contents.
_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-core-dev