Home » Eclipse Projects » Nebula » cell events
| cell events [message #11881] |
Thu, 21 September 2006 20:20  |
Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
is there a recommended way for the cell contents to fire events that
will get processed at the level of the viewer (actually the view that
contains the viewer)?
TIA,
al
|
|
|
| Re: cell events [message #11906 is a reply to message #11881] |
Thu, 21 September 2006 20:22  |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
let me clarify. i'm looking for the best way how to gain access to the
viewer from the cell or vice versa. and the appropriate lifecycle
methods to register and unregister the listeners.
Al Major wrote:
> is there a recommended way for the cell contents to fire events that
> will get processed at the level of the viewer (actually the view that
> contains the viewer)?
>
> TIA,
>
> al
|
|
| |
| Re: cell events [message #12519 is a reply to message #12497] |
Fri, 22 September 2006 16:26 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
here's my use case for the listener:
a) the user interacts with the GEF viewer in a column. this resets the
view properties (VP) for that particular viewer. an event is fired when
this happens.
b) the new VP have to be applied to all GEF viewers in the same column
(with lazy propagation, maybe only the visible ones).
in practice, the user can only interact with the visible cells. so the
"minimal" listener registration would register/unregister the listener
as the cell becomes visible/invisible. but doing register/unregister
when the GEF viewer (and/or cell composite) is initialized/disposed
might also be a reasonable option (and may be required in some other
usage scenario).
Jeremy Dowdall wrote:
> one way to get a cell from the viewer:
> viewer.getCTableTree().getItem(int).getCell(int)
> there are other access methods, but I'm not sure which would be best in
> your case.
>
> going the other way:
> cell.getItem().getContainer()
>
> Adding Listeners to cells is being reworked, especially now with the
> changes to the Title area's life cycle.
> What type of listeners are you needing and to which contents are you
> adding them?
>
>
> Al Major wrote:
>> let me clarify. i'm looking for the best way how to gain access to the
>> viewer from the cell or vice versa. and the appropriate lifecycle
>> methods to register and unregister the listeners.
>>
>> Al Major wrote:
>>> is there a recommended way for the cell contents to fire events that
>>> will get processed at the level of the viewer (actually the view that
>>> contains the viewer)?
>>>
>>> TIA,
>>>
>>> al
|
|
| |
| Re: cell events [message #12558 is a reply to message #12538] |
Tue, 26 September 2006 18:03 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
tom, my use case seems to require quite a bit more than the feature that
you mention. although i guess the listener registration architecture
would be along similar lines. thx, al.
Tom Schindl wrote:
> Hi,
>
> At some point in time (in between 3.3M3) where we have a generic
> JFace-Viewer for all Grid/Table like widgets you can vote for this
> feature request:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=151377
>
> Tom
>
> Al Major schrieb:
>> here's my use case for the listener:
>>
>> a) the user interacts with the GEF viewer in a column. this resets the
>> view properties (VP) for that particular viewer. an event is fired when
>> this happens.
>> b) the new VP have to be applied to all GEF viewers in the same column
>> (with lazy propagation, maybe only the visible ones).
>>
>> in practice, the user can only interact with the visible cells. so the
>> "minimal" listener registration would register/unregister the listener
>> as the cell becomes visible/invisible. but doing register/unregister
>> when the GEF viewer (and/or cell composite) is initialized/disposed
>> might also be a reasonable option (and may be required in some other
>> usage scenario).
>>
>>
>> Jeremy Dowdall wrote:
>>> one way to get a cell from the viewer:
>>> viewer.getCTableTree().getItem(int).getCell(int)
>>> there are other access methods, but I'm not sure which would be best in
>>> your case.
>>>
>>> going the other way:
>>> cell.getItem().getContainer()
>>>
>>> Adding Listeners to cells is being reworked, especially now with the
>>> changes to the Title area's life cycle.
>>> What type of listeners are you needing and to which contents are you
>>> adding them?
>>>
>>>
>>> Al Major wrote:
>>>> let me clarify. i'm looking for the best way how to gain access to the
>>>> viewer from the cell or vice versa. and the appropriate lifecycle
>>>> methods to register and unregister the listeners.
>>>>
>>>> Al Major wrote:
>>>>> is there a recommended way for the cell contents to fire events that
>>>>> will get processed at the level of the viewer (actually the view that
>>>>> contains the viewer)?
>>>>>
>>>>> TIA,
>>>>>
>>>>> al
|
|
|
| Re: cell events [message #12578 is a reply to message #12519] |
Wed, 27 September 2006 12:07 |
 Jeremy Dowdall
Messages: 181
Registered: July 2009 |
Senior Member |
|
|
> a) the user interacts with the GEF viewer in a column. this resets the
> view properties (VP) for that particular viewer. an event is fired when
> this happens.
I think a java bean PropertyChangeListener will be good for handling
this, and have thus added support for it to the CContainerCell class
(which, as you know, is the base class for CTableTreeCell).
Presently, the listeners will have to be added to each individual cell
because there are just too many different ways they may (or may not) be
used. Additionally, your custom cell classes will have to call
fireIndexedPropertyChange or firePropertyChange as, and when, appropriate.
Additionally, you need to call the setExclusions method once you have
created your GEF viewer to exclude it from the list of controls that are
managed by the container - in order for the CTableTree to show
selections and handle traversals and mouse events properly it registers
itself with every SWT control in every cell in two ways:
ColorManagedControls and EventManagedControls; if the user is to be able
to interact with controls, as your GEF viewer is, then it needs to be
removed from these lists; setExclusions(Control) should be the easiest
choice in your case.
Note that this is still under construction, so the javadoc is a bit light.
> b) the new VP have to be applied to all GEF viewers in the same column
> (with lazy propagation, maybe only the visible ones).
>
> in practice, the user can only interact with the visible cells. so the
> "minimal" listener registration would register/unregister the listener
> as the cell becomes visible/invisible. but doing register/unregister
> when the GEF viewer (and/or cell composite) is initialized/disposed
> might also be a reasonable option (and may be required in some other
> usage scenario).
>
>
> Jeremy Dowdall wrote:
>> one way to get a cell from the viewer:
>> viewer.getCTableTree().getItem(int).getCell(int)
>> there are other access methods, but I'm not sure which would be best in
>> your case.
>>
>> going the other way:
>> cell.getItem().getContainer()
>>
>> Adding Listeners to cells is being reworked, especially now with the
>> changes to the Title area's life cycle.
>> What type of listeners are you needing and to which contents are you
>> adding them?
>>
>>
>> Al Major wrote:
>>> let me clarify. i'm looking for the best way how to gain access to the
>>> viewer from the cell or vice versa. and the appropriate lifecycle
>>> methods to register and unregister the listeners.
>>>
>>> Al Major wrote:
>>>> is there a recommended way for the cell contents to fire events that
>>>> will get processed at the level of the viewer (actually the view that
>>>> contains the viewer)?
>>>>
>>>> TIA,
>>>>
>>>> al
|
|
|
| Re: cell events [message #12619 is a reply to message #12578] |
Thu, 28 September 2006 17:34 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
i think the proposed solution will work. one further question
what's the best place to register/unregister the listeners. there are
two cases i'm interested in:
a) register when the GEF viewer is created / unregister when the viewer
is destroyed in the cell.
b) register when the cell becomes visible / unregister when the cell
becomes invisible .
specifically, in which methods of CTableTreeViewer will the registration
/ unregistration code live?
al
Jeremy Dowdall wrote:
>> a) the user interacts with the GEF viewer in a column. this resets the
>> view properties (VP) for that particular viewer. an event is fired when
>> this happens.
> I think a java bean PropertyChangeListener will be good for handling
> this, and have thus added support for it to the CContainerCell class
> (which, as you know, is the base class for CTableTreeCell).
> Presently, the listeners will have to be added to each individual cell
> because there are just too many different ways they may (or may not) be
> used. Additionally, your custom cell classes will have to call
> fireIndexedPropertyChange or firePropertyChange as, and when, appropriate.
>
> Additionally, you need to call the setExclusions method once you have
> created your GEF viewer to exclude it from the list of controls that are
> managed by the container - in order for the CTableTree to show
> selections and handle traversals and mouse events properly it registers
> itself with every SWT control in every cell in two ways:
> ColorManagedControls and EventManagedControls; if the user is to be able
> to interact with controls, as your GEF viewer is, then it needs to be
> removed from these lists; setExclusions(Control) should be the easiest
> choice in your case.
> Note that this is still under construction, so the javadoc is a bit light.
>
|
|
|
| Re: cell events [message #12640 is a reply to message #12619] |
Thu, 28 September 2006 19:06 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
i think the answer to b) is to use a paintedItemListener on CContainer.
is that correct? or is there a better way?
i still need to figure out the right way to hook viewer creation / disposal.
thx,
al
Al Major wrote:
> i think the proposed solution will work. one further question
>
> what's the best place to register/unregister the listeners. there are
> two cases i'm interested in:
> a) register when the GEF viewer is created / unregister when the viewer
> is destroyed in the cell.
> b) register when the cell becomes visible / unregister when the cell
> becomes invisible .
>
> specifically, in which methods of CTableTreeViewer will the registration
> / unregistration code live?
>
> al
>
|
|
|
| Re: cell events [message #13641 is a reply to message #12578] |
Sun, 08 October 2006 17:10 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>
> Additionally, you need to call the setExclusions method once you have
> created your GEF viewer to exclude it from the list of controls that are
> managed by the container - in order for the CTableTree to show
> selections and handle traversals and mouse events properly it registers
> itself with every SWT control in every cell in two ways:
> ColorManagedControls and EventManagedControls; if the user is to be able
> to interact with controls, as your GEF viewer is, then it needs to be
> removed from these lists; setExclusions(Control) should be the easiest
> choice in your case.
> Note that this is still under construction, so the javadoc is a bit light.
>
thanks! works like a charm. the viewers are getting input mouse events
fine.
i'm still working on getting events out of the viewers.
al
|
|
|
| Re: cell events [message #14735 is a reply to message #12578] |
Fri, 20 October 2006 17:48 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
everything works as advertised. i've got the initial implementation
working in toto. sweet!
i'll try to summarize the lifecycle events required by my app in a
separate thread or in bugzilla.
al
Jeremy Dowdall wrote:
>> a) the user interacts with the GEF viewer in a column. this resets the
>> view properties (VP) for that particular viewer. an event is fired when
>> this happens.
> I think a java bean PropertyChangeListener will be good for handling
> this, and have thus added support for it to the CContainerCell class
> (which, as you know, is the base class for CTableTreeCell).
> Presently, the listeners will have to be added to each individual cell
> because there are just too many different ways they may (or may not) be
> used. Additionally, your custom cell classes will have to call
> fireIndexedPropertyChange or firePropertyChange as, and when, appropriate.
>
> Additionally, you need to call the setExclusions method once you have
> created your GEF viewer to exclude it from the list of controls that are
> managed by the container - in order for the CTableTree to show
> selections and handle traversals and mouse events properly it registers
> itself with every SWT control in every cell in two ways:
> ColorManagedControls and EventManagedControls; if the user is to be able
> to interact with controls, as your GEF viewer is, then it needs to be
> removed from these lists; setExclusions(Control) should be the easiest
> choice in your case.
> Note that this is still under construction, so the javadoc is a bit light.
>
>> b) the new VP have to be applied to all GEF viewers in the same column
>> (with lazy propagation, maybe only the visible ones).
>>
>> in practice, the user can only interact with the visible cells. so the
>> "minimal" listener registration would register/unregister the listener
>> as the cell becomes visible/invisible. but doing register/unregister
>> when the GEF viewer (and/or cell composite) is initialized/disposed
>> might also be a reasonable option (and may be required in some other
>> usage scenario).
>>
>>
>> Jeremy Dowdall wrote:
>>> one way to get a cell from the viewer:
>>> viewer.getCTableTree().getItem(int).getCell(int)
>>> there are other access methods, but I'm not sure which would be best in
>>> your case.
>>>
>>> going the other way:
>>> cell.getItem().getContainer()
>>>
>>> Adding Listeners to cells is being reworked, especially now with the
>>> changes to the Title area's life cycle.
>>> What type of listeners are you needing and to which contents are you
>>> adding them?
>>>
>>>
>>> Al Major wrote:
>>>> let me clarify. i'm looking for the best way how to gain access to the
>>>> viewer from the cell or vice versa. and the appropriate lifecycle
>>>> methods to register and unregister the listeners.
>>>>
>>>> Al Major wrote:
>>>>> is there a recommended way for the cell contents to fire events that
>>>>> will get processed at the level of the viewer (actually the view that
>>>>> contains the viewer)?
>>>>>
>>>>> TIA,
>>>>>
>>>>> al
|
|
| | | | | |
| Re: cell events [message #565623 is a reply to message #12519] |
Wed, 27 September 2006 12:07 |
Jeremy Dowdall
Messages: 181
Registered: July 2009 |
Senior Member |
|
|
> a) the user interacts with the GEF viewer in a column. this resets the
> view properties (VP) for that particular viewer. an event is fired when
> this happens.
I think a java bean PropertyChangeListener will be good for handling
this, and have thus added support for it to the CContainerCell class
(which, as you know, is the base class for CTableTreeCell).
Presently, the listeners will have to be added to each individual cell
because there are just too many different ways they may (or may not) be
used. Additionally, your custom cell classes will have to call
fireIndexedPropertyChange or firePropertyChange as, and when, appropriate.
Additionally, you need to call the setExclusions method once you have
created your GEF viewer to exclude it from the list of controls that are
managed by the container - in order for the CTableTree to show
selections and handle traversals and mouse events properly it registers
itself with every SWT control in every cell in two ways:
ColorManagedControls and EventManagedControls; if the user is to be able
to interact with controls, as your GEF viewer is, then it needs to be
removed from these lists; setExclusions(Control) should be the easiest
choice in your case.
Note that this is still under construction, so the javadoc is a bit light.
> b) the new VP have to be applied to all GEF viewers in the same column
> (with lazy propagation, maybe only the visible ones).
>
> in practice, the user can only interact with the visible cells. so the
> "minimal" listener registration would register/unregister the listener
> as the cell becomes visible/invisible. but doing register/unregister
> when the GEF viewer (and/or cell composite) is initialized/disposed
> might also be a reasonable option (and may be required in some other
> usage scenario).
>
>
> Jeremy Dowdall wrote:
>> one way to get a cell from the viewer:
>> viewer.getCTableTree().getItem(int).getCell(int)
>> there are other access methods, but I'm not sure which would be best in
>> your case.
>>
>> going the other way:
>> cell.getItem().getContainer()
>>
>> Adding Listeners to cells is being reworked, especially now with the
>> changes to the Title area's life cycle.
>> What type of listeners are you needing and to which contents are you
>> adding them?
>>
>>
>> Al Major wrote:
>>> let me clarify. i'm looking for the best way how to gain access to the
>>> viewer from the cell or vice versa. and the appropriate lifecycle
>>> methods to register and unregister the listeners.
>>>
>>> Al Major wrote:
>>>> is there a recommended way for the cell contents to fire events that
>>>> will get processed at the level of the viewer (actually the view that
>>>> contains the viewer)?
>>>>
>>>> TIA,
>>>>
>>>> al
|
|
|
| Re: cell events [message #565702 is a reply to message #12578] |
Thu, 28 September 2006 17:34 |
Al Major
Messages: 72
Registered: July 2009 |
Member |
|
|
i think the proposed solution will work. one further question
what's the best place to register/unregister the listeners. there are
two cases i'm interested in:
a) register when the GEF viewer is created / unregister when the viewer
is destroyed in the cell.
b) register when the cell becomes visible / unregister when the cell
becomes invisible .
specifically, in which methods of CTableTreeViewer will the registration
/ unregistration code live?
al
Jeremy Dowdall wrote:
>> a) the user interacts with the GEF viewer in a column. this resets the
>> view properties (VP) for that particular viewer. an event is fired when
>> this happens.
> I think a java bean PropertyChangeListener will be good for handling
> this, and have thus added support for it to the CContainerCell class
> (which, as you know, is the base class for CTableTreeCell).
> Presently, the listeners will have to be added to each individual cell
> because there are just too many different ways they may (or may not) be
> used. Additionally, your custom cell classes will have to call
> fireIndexedPropertyChange or firePropertyChange as, and when, appropriate.
>
> Additionally, you need to call the setExclusions method once you have
> created your GEF viewer to exclude it from the list of controls that are
> managed by the container - in order for the CTableTree to show
> selections and handle traversals and mouse events properly it registers
> itself with every SWT control in every cell in two ways:
> ColorManagedControls and EventManagedControls; if the user is to be able
> to interact with controls, as your GEF viewer is, then it needs to be
> removed from these lists; setExclusions(Control) should be the easiest
> choice in your case.
> Note that this is still under construction, so the javadoc is a bit light.
>
|
|
| | |
| Re: cell events [message #566978 is a reply to message #12578] |
Fri, 20 October 2006 17:48 |
Al Major
Messages: 72
Registered: July 2009 |
Member |
|
|
everything works as advertised. i've got the initial implementation
working in toto. sweet!
i'll try to summarize the lifecycle events required by my app in a
separate thread or in bugzilla.
al
Jeremy Dowdall wrote:
>> a) the user interacts with the GEF viewer in a column. this resets the
>> view properties (VP) for that particular viewer. an event is fired when
>> this happens.
> I think a java bean PropertyChangeListener will be good for handling
> this, and have thus added support for it to the CContainerCell class
> (which, as you know, is the base class for CTableTreeCell).
> Presently, the listeners will have to be added to each individual cell
> because there are just too many different ways they may (or may not) be
> used. Additionally, your custom cell classes will have to call
> fireIndexedPropertyChange or firePropertyChange as, and when, appropriate.
>
> Additionally, you need to call the setExclusions method once you have
> created your GEF viewer to exclude it from the list of controls that are
> managed by the container - in order for the CTableTree to show
> selections and handle traversals and mouse events properly it registers
> itself with every SWT control in every cell in two ways:
> ColorManagedControls and EventManagedControls; if the user is to be able
> to interact with controls, as your GEF viewer is, then it needs to be
> removed from these lists; setExclusions(Control) should be the easiest
> choice in your case.
> Note that this is still under construction, so the javadoc is a bit light.
>
>> b) the new VP have to be applied to all GEF viewers in the same column
>> (with lazy propagation, maybe only the visible ones).
>>
>> in practice, the user can only interact with the visible cells. so the
>> "minimal" listener registration would register/unregister the listener
>> as the cell becomes visible/invisible. but doing register/unregister
>> when the GEF viewer (and/or cell composite) is initialized/disposed
>> might also be a reasonable option (and may be required in some other
>> usage scenario).
>>
>>
>> Jeremy Dowdall wrote:
>>> one way to get a cell from the viewer:
>>> viewer.getCTableTree().getItem(int).getCell(int)
>>> there are other access methods, but I'm not sure which would be best in
>>> your case.
>>>
>>> going the other way:
>>> cell.getItem().getContainer()
>>>
>>> Adding Listeners to cells is being reworked, especially now with the
>>> changes to the Title area's life cycle.
>>> What type of listeners are you needing and to which contents are you
>>> adding them?
>>>
>>>
>>> Al Major wrote:
>>>> let me clarify. i'm looking for the best way how to gain access to the
>>>> viewer from the cell or vice versa. and the appropriate lifecycle
>>>> methods to register and unregister the listeners.
>>>>
>>>> Al Major wrote:
>>>>> is there a recommended way for the cell contents to fire events that
>>>>> will get processed at the level of the viewer (actually the view that
>>>>> contains the viewer)?
>>>>>
>>>>> TIA,
>>>>>
>>>>> al
|
|
|
Goto Forum:
Current Time: Sat Dec 21 12:29:50 GMT 2024
Powered by FUDForum. Page generated in 0.05890 seconds |
] 
Search
Help
Register
Login
Home
