[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-core-dev] Change events
|
>
> This is a multipart message in MIME format.
> --=_alternative 005CF05485256EB3_=
> Content-Type: text/plain; charset="US-ASCII"
>
> Hello,
>
> I have a question about what information I should expect to be conveyed
> through the IElementChangedListener#elementChanged callback.
>
> The events seem to be very detailed for working copies but I haven't
> (recently) seen such detail for other elements.
>
> For example if you change the name of a field in the editor, a
> POST_RECONCILE event occurs: This refers to the working copy in the
> editor.
>
> org.eclipse.cdt.core.model.ElementChangedEvent[source=Class1.h
> TRANSLATION_UNIT [*]: {CHILDREN | FINE GRAINED}
> Class1 C_CLASS [*]: {CHILDREN}
> new_name C_FIELD [+]: {}
> old_name C_FIELD [-]: {}]
>
> When the editor buffer is saved, a POST_CHANGE event occurs with respect
> to the real translation unit (as stored in the file system).
>
> org.eclipse.cdt.core.model.ElementChangedEvent[source= CMODEL [*]:
> {CHILDREN | FINE GRAINED}
> cpp CPROJECT [*]: {CHILDREN | FINE GRAINED}
> cpp CCONTAINER [*]: {CHILDREN | FINE GRAINED}
> Class1.h TRANSLATION_UNIT [*]: {CONTENT}]
>
> An application could accumulate all the working copy events and consider
> them to be applied when the event signalling the change to the real
> translation unit arrives. I would have expected that behavior directly
> from the CDT rather than delegating this work to clients.
>
> Is this behavior design intent or is this a bug?
>
The resource delta is not under our control so we can not rely on it.
For example, some clients, a previewer, ClassBrowser, open Type, refactoring etc ..
may need the "live" info(i.e. not necessarly save on disk) they want to be notify right away
on changes of the Working Copy. So the POST_RECONCILE are not nessarily piggyback
of the a resource Event(POST_CHANGE).
The C/C++ Outliner is an obvious example.
