RE: [ve-dev] Methods of BeanProxyAdapter

[Rich Kulp <richkulp@xxxxxxxxxx>]

Hi, I'm sure it is being applied immediately.
Adding a new widget wouldn't cause some other widget to now apply a previous
property setting. What can happen is that the apply did not trigger an
new image request OR you've changed the order of refreshing such that when
the new image is finally requested the widget has not yet been updated.

It sounds like your widget update process
doesn't work correctly. I don't know how you are doing it with the ComponentManager,
but this is the process that occurs with standard AWT/Swing components.
For this example, say you have a button within a panel within a frame.
For Swing there will be a BeanProxyAdapter (ComponentProxyAdapter) for
the button and a BeanProxyAdapter for the panel and the frame (ContainerProxyAdapter).
We are going to be changing the text of the button.

1. The applied method will actually (through the applySetting() method) apply the text to the button immediately.
2. The applied method then calls the "revalidateBeanProxy" method.
3. ComponentProxyAdapter implementation of "revalidateBeanProxy" calls
                  if (isBeanProxyInstantiated())
                          getComponentManager().invalidate(getModelChangeController());
4. The componentManager then queues up an invalidate with the feedback controller (there is only one controller per vm). It does this by queuing up a runnable to the model controller for the current transaction being executed. If you are coming through the standard command stack, you will be within a transaction.
5. Now at the end of the transaction (which occurs when command stack is done executing the set of commands sent to it), the feedback controller gets its runnable executed. This runnable will then send, for each component that has been changed (in this case the button), an invalidate request to its component manager on the remote vm. The feedback controller will then send a request to vm's feedback controller that it wants the queued up invalid images to be validated and sent back.
   
   The component manager on the remote vm, when it receives the invalidate request, will then call invalidate() on that AWT/Swing component. The component manager on the remote vm will then tell the vm's feedback controller that the component is invalid. The vm's feedback manager will then queue up in its list of invalid components that component plus the parent chain of that component all of the way up the top-most parent (an awt.Window, which can be a Frame or a Dialog, or whatever the top-level is).
   
6. Now when the vm's feedback controller receives the request to send back the invalid images it will queue this request up to the AWT's EventQueue to be executed when possible on the AWT's UI Thread. The event will:
   a) call validate() on all of the top-level Windows that had invalidated children. This will validate the button. AWT validate will also call doLayout as necessary to relayout the controls.
   b) Send back a notification to the IDE with a list of all of the children that have now been validated and have a new image.
7. The feedback controller on the IDE receives these notifications and for each child that was sent, it goes to the cooresponding ComponentManager on the IDE (if there is one, in some cases there may not be because it was an intermediate component that has no BeanProxyAdapter for it).  That component manager will then see if there is an image listener for that component. If there is one it will then request a new image for that component.

So if you change the text of a button:

1. Text on button is changed
2. revalidateBeanProxy is called.
3. Button invalidate is queued up for the end of transaction
4. At transaction end, the button on the remote vm is invalidated (invalidate() called on it).
5. The vm feedback controller will then call validate on the frame that contains the button
6. The ide feedback controller receives notification that the frame, the panel, and the button all have an invalid image. But because only the frame has a image listener attached (because we only ask for images of the top-level component, no need to ask for child images since the top-level image includes that children in it), only the frame image is requested and sent back to the editpart.

For your parts, I don't know if when
you change the text of a button are you changing the text directly on the
button, or are you changing it in some ULC part that will eventually change
it on the Swing button that represents that ULC part. If you are changing
the button directly then everything should work fine. But if you are changing
some ULC part, it may be that the change does not get propagated to the
true swing button until after the above process has completed. In which
case you won't see the change until the next time a change occurs. So the
images will always be one step behind.




As for the question about the _expression_
proxy. The answer is you can't. That information is not saved. It is immediately
sent to the remote vm. You can turn on a trace to see what actually gets
sent to the remote vm. This would then get logged for you to see. To turn
on the trace, go to the Launch page for the workbench application being
launched, switch to the tracing page. Now make sure that "Enable tracing
for selected plugins" is checked, then go and make sure the org.eclipse.jem.proxy
plugin is checked in the tree, then check "debug/traceexpressions".
Then when you execute, all of the IExpression calls will be traced to the
.log file after execution.

Rich

"Janak Mulani" <janak.mulani@xxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

10/31/2005 10:57 AM

Please respond to
Discussions people developing code for the Visual Editor project

To	"Discussions people developing code for the Visual Editor project" <ve-dev@xxxxxxxxxxx>
cc
Subject	RE: [ve-dev] Methods of BeanProxyAdapter

Hi Rich,

Thanks.

>>> RLK >>>


In our case, even the setting of other properties in the property sheet
is
not propogated to the VM, although it is reflected in the model and code.
Only if we add a new widget to the canvas, the previously set property
is
set on the bean in the VM and then canvas reflects the correct picture.


The only thing I can think of is that in your ULCButton proxy adapter you
had overridden the "applied" method and didn't do the necessary
things that
applied does. That is why the recommendation is if you need to override
(as
the javadoc indicates) is that you should override applySetting or one
of
the other ones. The problem is if you override applied it doesn't do the
necessary checks that applied does, nor does it do the revalidate, and
without the revalidate it won't know the image has changed.
>>>>

In our ULCComponentProxyAdapter.applied we are calling super.applied i.e.
(BeanProxyAdapter.applied) if the feature is not "visible", for
"visible" we
just don't do anything.

In the debugger I checked that while setting a property,
beanProxyAdapter.notifyChanged calls  applied and then the _expression_
is
invoked.

Where in the VM can I check when the _expression_ is invoked? i.e. where
do I
put the breakpoint in the VM code to see that _expression_ invoked from IDE
is
executed in the VM?


>> RLK >>>
2. In a variable of type ExpressionProxy, what should one be looking for
to
find out the corresponding BeanProxy it represents on the target VM?
Basically how does one examine the _expression_ proxy? what should one look
for?


-- RLK What is it you are looking for? The _expression_ proxy has no idea
what
the real bean proxy is until the _expression_ has been invoked. And after
it
has been invoked the _expression_ proxy is disposed. That is why we add
listeners to the _expression_ proxy. The listeners are called when the
_expression_ proxy is resolved to the real bean proxy at a later time.

>>>

In the ExpressionProxy variable, where do I look for all the methods that
are going to be executed and the proxy on which they are going to be
executed?

Thanks and regards,

Janak

_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev