Problem with a non-collapsible compartment [message #145239] |
Sat, 04 August 2007 21:10 ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: NOSPAM.xyz.com
Hi, I have A Top-Level Node with a compartment. I need to open
a dialog after a double-click anywhere in that node. So I install
installEditPolicy(EditPolicyRoles.OPEN_ROLE, new
OpenParamDialogEditPolicy());
on this compartment's EP.
If the compartment is collapsible everything works fine - on double-click
its edit part gets
SelectionRequest of type "open" and so on.
However if the compartments is non-collapsible ( canCollapse="false"
hideIfEmpty="false" in *gmfgen)
and occupies the whole area of the parent's top-level node than nobody gets
a "open" request at all, neither the compartment EP nor its parent EP.
I know that you may wonder why would somebody want to switch-off one of the
neatest
UI features of GMF, but in the context of my application it just doesn't
make sense to
collapse a compartment but leave its parent node occupying real estate. So I
use a compartment only
for the cool sliders but I must have it fully expanded all the time.
Any idea why would such a compartment suddenly stop receiving "open"
requests?
Regards,
Theo M
|
|
|
Re: Problem with a non-collapsible compartment [message #145702 is a reply to message #145239] |
Tue, 07 August 2007 17:22 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: NOSPAM.xyz.com
"Theo" <NOSPAM@xyz.com> wrote in message
news:f92poh$ou3$1@build.eclipse.org...
> Hi, I have A Top-Level Node with a compartment. I need to open
> a dialog after a double-click anywhere in that node. So I install
>
> installEditPolicy(EditPolicyRoles.OPEN_ROLE, new
> OpenParamDialogEditPolicy());
> on this compartment's EP.
>
> If the compartment is collapsible everything works fine - on double-click
> its edit part gets
> SelectionRequest of type "open" and so on.
> However if the compartments is non-collapsible ( canCollapse="false"
> hideIfEmpty="false" in *gmfgen)
> and occupies the whole area of the parent's top-level node than nobody
> gets
> a "open" request at all, neither the compartment EP nor its parent EP.
> I know that you may wonder why would somebody want to switch-off one of
> the neatest
> UI features of GMF, but in the context of my application it just doesn't
> make sense to
> collapse a compartment but leave its parent node occupying real estate. So
> I use a compartment only
> for the cool sliders but I must have it fully expanded all the time.
> Any idea why would such a compartment suddenly stop receiving "open"
> requests?
> Regards,
> Theo M
I think I found it. When one chooses non-collapsible compartment in the
tooling the generated compartment EP does not override
ShapeCompartmentEditPart's
getDragTracker(Request req)
It returns just a RubberbandDragTracker which knows nothing about REQ_OPEN
and so on.
I overrode it to rerurn SelectEditPartTracker and now it seems to work, but
i'll have to test further.
Theo
|
|
|
Powered by
FUDForum. Page generated in 0.03219 seconds