|
| Re: Manipulating Sweet bits programmatically [message #129170 is a reply to message #129154] |
Thu, 27 July 2006 23:04   |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Couple of questions:
1) Is this on your palette, so that you would want these set if dropped
from the palette. This is different than the ChooseBean. If dropped from
the palette you may not need a ContainmentHandler. You would need the
ContainmentHandler if you wanted to drop from either the palette or the
ChooseBean and have a non-standard setting.
2) Do you want it to always be the same on the drop, or will you be
changing the values depending on some criteria?
--
Thanks,
Rich Kulp
|
|
|
| Re: Manipulating Sweet bits programmatically [message #129201 is a reply to message #129170] |
Fri, 28 July 2006 13:06 |
 Tami Takamiya
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Rich,
Thank you for your response.
Rich Kulp wrote:
> 1) Is this on your palette, so that you would want these set if dropped
> from the palette. This is different than the ChooseBean. If dropped from
> the palette you may not need a ContainmentHandler. You would need the
> ContainmentHandler if you wanted to drop from either the palette or the
> ChooseBean and have a non-standard setting.
We do have a non-standard setting. It is on a palette and when it is
dropped from the palette, it shows a non-standard dialog box, where
users can specify some settings of the widget. Depending on the
settings specified on the dialog box, the widget (which extends
Composite) would contain either a Button or a Link.
> 2) Do you want it to always be the same on the drop, or will you be
> changing the values depending on some criteria?
We want to change the value depending on the setting specified by user.
So far, the only way I could think of is to have our own
processAllocation method instead of depending on
WidgetContainmentHandler#processAllocation. Our own processAllocation
method works and there we can specify our flags whatever we like, but if
there is a cleaner way, I would like to go in that direction. Thanks.
Tami
|
|
|
| Re: Manipulating Sweet bits programmatically [message #129227 is a reply to message #129201] |
Fri, 28 July 2006 14:16 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
No the process allocation override is correct. I recommend your override
first call the standard process allocation so that any standard widget
functions can be performed, and then it can manipulate the allocation to
put in the bits it wants to have.
--
Thanks,
Rich Kulp
|
|
|
| Re: Manipulating Sweet bits programmatically [message #129240 is a reply to message #129227] |
Fri, 28 July 2006 14:55 |
Tami Takamiya
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Rich Kulp wrote:
> No the process allocation override is correct. I recommend your override
> first call the standard process allocation so that any standard widget
> functions can be performed, and then it can manipulate the allocation to
> put in the bits it wants to have.
>
Yes, that is what I want to do. I assume that it can be done by
CommandBuilder#applyAttributeSetting, but it was not successful so far
for some reasons.
CommandBuilder#applyAttributeSetting accepts three paremeters:
EObject target, EStructuralFeature feature, and Object value.
For setting regular attribute, which can be reached by setter and
getter, we can set value by setting:
target: IJavaObjectInstance jo
feature: EStructuralFeature obtained by
jo.eClass().getEStructuralFeature("attribute_name_string");
value: IJavaInstance obtained by
BeanUtilities.createJavaObject("attribute_type_class_string ",
resourceSet,
"attribute_value_string");
I know the attributes that are using "Sweet" bits are different even
thought they can be set in the same way from Property sheet and I want
to know what and when they need to be set.
I guess the target should be something that represents the allocation
and feature should be something different as well.
Are they
jo.getAllocation(), and
jo.getAllocation().eClass().getEStructuralFeature("attribute_name_string ")
? (I will test it by myself...)
Tami
|
|
|
| Re: Manipulating Sweet bits programmatically [message #129252 is a reply to message #129240] |
Fri, 28 July 2006 15:33 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
You would not be applying attributes of the bean. You need to update the
ParseTreeAllocation itself, which represents the syntax of the entire
constructor.
Actually, I was wrong. You should not override processAllocation. You
need to write your own containment. It will be a combination of
WidgetContainmentHandler.processAllocation: This shows how to create the
allocation where you will be setting the bit field.
WindowContainmentHandler.contributeToDrop: This shows how to bring up a
dialog on the drop to ask questions and to finally create the
allocation. The reason that this is special is because you don't want to
bring up the dialog until the drop has occurred, but contributeToDrop is
called on each mouse move. So the dialog is actually brought up within a
Command's (implemented as a CommandWrapper) execute. This way the
execute doesn't happen until the mouse button has been released and the
true drop has happened.
--
Thanks,
Rich Kulp
|
|
|
|
| Re: Manipulating Sweet bits programmatically [message #129288 is a reply to message #129264] |
Fri, 28 July 2006 21:24 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Everybody is always on a steep learning curve!! There is a ton of things
that need to be done to extend it.
The fact that you got to ContainmentHandlers and Sweet bit manipulation
in only two weeks is actually rather amazing. Most of the time people
have trouble just getting a handle on the EMF model to model the code,
and how to update this model and interact with the remote vm.
Tami Takamiya wrote:
> Rich,
>
> Thank you for your reply. I will try that this weekend.
>
> It's been two weeks since I started working on JVE extension and I am
> still on a steep learning curve. Your suggestion is really helpful.
>
> Tami
>
> Rich Kulp wrote:
>
>> You would not be applying attributes of the bean. You need to update
>> the ParseTreeAllocation itself, which represents the syntax of the
>> entire constructor.
--
Thanks,
Rich Kulp
|
|
|
|
| Re: Manipulating Sweet bits programmatically [message #129618 is a reply to message #129313] |
Mon, 07 August 2006 14:16 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Be careful that this block of code is actually within a command itself.
This is because if this was a "move" then this would be an already
existing live component and you would of changed its allocation right
there, even though the commands weren't executed yet. These methods are
called on each and every mouse move before it is actually dropped. The
request could be canceled without the commands being executed, but if
you made the change directly it would take effect right then even though
the drop was canceled.
--
Thanks,
Rich Kulp
|
|
|
| Re: Manipulating Sweet bits programmatically [message #129654 is a reply to message #129618] |
Mon, 07 August 2006 14:57 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Actually you should be using a CommandWrapper and within the run() you
should create another set of commands to actually manipulate the parse
tree. You shouldn't manipulate it directly because then the changes
could not be undone.
See WindowContainmentHandler, and look for the CommandWrapper to see how
we manipulate the allocation.
But Congratulations on getting as far as you have. That is great!
Rich Kulp wrote:
> Be careful that this block of code is actually within a command itself.
> This is because if this was a "move" then this would be an already
> existing live component and you would of changed its allocation right
> there, even though the commands weren't executed yet. These methods are
> called on each and every mouse move before it is actually dropped. The
> request could be canceled without the commands being executed, but if
> you made the change directly it would take effect right then even though
> the drop was canceled.
--
Thanks,
Rich Kulp
|
|
|
| Re: Manipulating Sweet bits programmatically [message #613577 is a reply to message #129154] |
Thu, 27 July 2006 23:04 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Couple of questions:
1) Is this on your palette, so that you would want these set if dropped
from the palette. This is different than the ChooseBean. If dropped from
the palette you may not need a ContainmentHandler. You would need the
ContainmentHandler if you wanted to drop from either the palette or the
ChooseBean and have a non-standard setting.
2) Do you want it to always be the same on the drop, or will you be
changing the values depending on some criteria?
--
Thanks,
Rich Kulp
|
|
|
| Re: Manipulating Sweet bits programmatically [message #613583 is a reply to message #129170] |
Fri, 28 July 2006 13:06 |
Tami Takamiya
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Rich,
Thank you for your response.
Rich Kulp wrote:
> 1) Is this on your palette, so that you would want these set if dropped
> from the palette. This is different than the ChooseBean. If dropped from
> the palette you may not need a ContainmentHandler. You would need the
> ContainmentHandler if you wanted to drop from either the palette or the
> ChooseBean and have a non-standard setting.
We do have a non-standard setting. It is on a palette and when it is
dropped from the palette, it shows a non-standard dialog box, where
users can specify some settings of the widget. Depending on the
settings specified on the dialog box, the widget (which extends
Composite) would contain either a Button or a Link.
> 2) Do you want it to always be the same on the drop, or will you be
> changing the values depending on some criteria?
We want to change the value depending on the setting specified by user.
So far, the only way I could think of is to have our own
processAllocation method instead of depending on
WidgetContainmentHandler#processAllocation. Our own processAllocation
method works and there we can specify our flags whatever we like, but if
there is a cleaner way, I would like to go in that direction. Thanks.
Tami
|
|
|
| Re: Manipulating Sweet bits programmatically [message #613592 is a reply to message #129201] |
Fri, 28 July 2006 14:16 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
No the process allocation override is correct. I recommend your override
first call the standard process allocation so that any standard widget
functions can be performed, and then it can manipulate the allocation to
put in the bits it wants to have.
--
Thanks,
Rich Kulp
|
|
|
| Re: Manipulating Sweet bits programmatically [message #613595 is a reply to message #129227] |
Fri, 28 July 2006 14:55 |
Tami Takamiya
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Rich Kulp wrote:
> No the process allocation override is correct. I recommend your override
> first call the standard process allocation so that any standard widget
> functions can be performed, and then it can manipulate the allocation to
> put in the bits it wants to have.
>
Yes, that is what I want to do. I assume that it can be done by
CommandBuilder#applyAttributeSetting, but it was not successful so far
for some reasons.
CommandBuilder#applyAttributeSetting accepts three paremeters:
EObject target, EStructuralFeature feature, and Object value.
For setting regular attribute, which can be reached by setter and
getter, we can set value by setting:
target: IJavaObjectInstance jo
feature: EStructuralFeature obtained by
jo.eClass().getEStructuralFeature("attribute_name_string");
value: IJavaInstance obtained by
BeanUtilities.createJavaObject("attribute_type_class_string ",
resourceSet,
"attribute_value_string");
I know the attributes that are using "Sweet" bits are different even
thought they can be set in the same way from Property sheet and I want
to know what and when they need to be set.
I guess the target should be something that represents the allocation
and feature should be something different as well.
Are they
jo.getAllocation(), and
jo.getAllocation().eClass().getEStructuralFeature("attribute_name_string ")
? (I will test it by myself...)
Tami
|
|
|
| Re: Manipulating Sweet bits programmatically [message #613599 is a reply to message #129240] |
Fri, 28 July 2006 15:33 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
You would not be applying attributes of the bean. You need to update the
ParseTreeAllocation itself, which represents the syntax of the entire
constructor.
Actually, I was wrong. You should not override processAllocation. You
need to write your own containment. It will be a combination of
WidgetContainmentHandler.processAllocation: This shows how to create the
allocation where you will be setting the bit field.
WindowContainmentHandler.contributeToDrop: This shows how to bring up a
dialog on the drop to ask questions and to finally create the
allocation. The reason that this is special is because you don't want to
bring up the dialog until the drop has occurred, but contributeToDrop is
called on each mouse move. So the dialog is actually brought up within a
Command's (implemented as a CommandWrapper) execute. This way the
execute doesn't happen until the mouse button has been released and the
true drop has happened.
--
Thanks,
Rich Kulp
|
|
|
|
| Re: Manipulating Sweet bits programmatically [message #613612 is a reply to message #129264] |
Fri, 28 July 2006 21:24 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Everybody is always on a steep learning curve!! There is a ton of things
that need to be done to extend it.
The fact that you got to ContainmentHandlers and Sweet bit manipulation
in only two weeks is actually rather amazing. Most of the time people
have trouble just getting a handle on the EMF model to model the code,
and how to update this model and interact with the remote vm.
Tami Takamiya wrote:
> Rich,
>
> Thank you for your reply. I will try that this weekend.
>
> It's been two weeks since I started working on JVE extension and I am
> still on a steep learning curve. Your suggestion is really helpful.
>
> Tami
>
> Rich Kulp wrote:
>
>> You would not be applying attributes of the bean. You need to update
>> the ParseTreeAllocation itself, which represents the syntax of the
>> entire constructor.
--
Thanks,
Rich Kulp
|
|
|
|
| Re: Manipulating Sweet bits programmatically [message #613705 is a reply to message #129313] |
Mon, 07 August 2006 14:16 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Be careful that this block of code is actually within a command itself.
This is because if this was a "move" then this would be an already
existing live component and you would of changed its allocation right
there, even though the commands weren't executed yet. These methods are
called on each and every mouse move before it is actually dropped. The
request could be canceled without the commands being executed, but if
you made the change directly it would take effect right then even though
the drop was canceled.
--
Thanks,
Rich Kulp
|
|
|
| Re: Manipulating Sweet bits programmatically [message #613731 is a reply to message #129618] |
Mon, 07 August 2006 14:57 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Actually you should be using a CommandWrapper and within the run() you
should create another set of commands to actually manipulate the parse
tree. You shouldn't manipulate it directly because then the changes
could not be undone.
See WindowContainmentHandler, and look for the CommandWrapper to see how
we manipulate the allocation.
But Congratulations on getting as far as you have. That is great!
Rich Kulp wrote:
> Be careful that this block of code is actually within a command itself.
> This is because if this was a "move" then this would be an already
> existing live component and you would of changed its allocation right
> there, even though the commands weren't executed yet. These methods are
> called on each and every mouse move before it is actually dropped. The
> request could be canceled without the commands being executed, but if
> you made the change directly it would take effect right then even though
> the drop was canceled.
--
Thanks,
Rich Kulp
|
|
|
Powered by
FUDForum. Page generated in 0.04481 seconds
] 
Search
Help
Register
Login
Home
