I have the necessary extension points and my Tab class is extending AbstractLaunchConfigurationTab. I am doing nothing different to examples, such as, the CommonTab. I call updateLaunchConfigurationDialog() when a widget event is fired.
EDIT: The listener method for my widgets are definitely being called and the performApply method is being called. I am doing what the CommonTab class does with one of its radio buttons, for example:
fSharedRadioButton.addSelectionListener(new SelectionAdapter() {
#Override
public void widgetSelected(SelectionEvent evt) {
handleSharedRadioButtonSelected();
}
});
/**
* handles the shared radio button being selected
*/
private void handleSharedRadioButtonSelected() {
setSharedEnabled(isShared());
updateLaunchConfigurationDialog();
}
The only difference is that my widget is a spinner:
executionsSpinner.addSelectionListener(new SelectionAdapter() {
#Override
public void widgetSelected(SelectionEvent e) {
updateLaunchConfigurationDialog();
}
});
When updateLaunchConfigurationDialog is called the framework triggers a call to your tab's performApply method.
performApply is passed an ILaunchConfigurationWorkingCopy instance as an argument. When performApply returns that ILaunchConfigurationWorkingCopy instance is compared with the original, unmodified ILaunchConfiguration. If there are any differences then the Apply button is enabled.
You must hence make some modification to the argument of performApply for Apply to be enabled, just as Greg notices in their comment.
Related
I am working on an editor plugin and now implementing support for code hovers.
I have extended AbstractInformationControl (and implemented IInformationControlExtension2) to create a new control for showing the hover info.
It works almost fine, but I am unable to receive property change events in my information control. What I try is like this, but the event handler does not fire:
public class MyHoverInfoControl extends AbstractInformationControl implements IInformationControlExtension2 {
public MyHoverInfoControl(Shell parentShell, String string) {
super(parentShell, string);
create();
Activator.getDefault().getPreferenceStore().addPropertyChangeListener(new IPropertyChangeListener() {
#Override
public void propertyChange(PropertyChangeEvent event) {
// TODO Auto-generated method stub
}
});
}
The control itself contains a StyledText. I have also tried to add a KeyListener to this StyledText to see if key events are received, and it only seemed to work if I click into the control (it is not enough to hover over a text to show the control). But property change event does not seem to be received even after the click.
Is it possible to receive property change events for an AbstractInformationControl subclass?
We have implemented several custom ORM objects in our webshop implementation that have references (dependencies) to Intershop Product system object.
When a user tries to delete a certain product in back-office, it causes problems because references to that product may still exist in our custom objects. Naturally, deleting a product that is referenced from one of our custom objects generates an exception like this:
java.sql.SQLTransactionRollbackException: ORA-02091: transaction rolled back ORA-02292: integrity constraint (INTERSHOP.A1POSTPAIDPRICE_CO_002) violated - child record found
We have figured that we could solve that by implementing an ORMObjectListener and overriding objectDeleting method to delete all the references before the product actually gets deleted.
Intershop cookbook for ORM layer states:
"Instances must implement the interface ORMObjectListener for a given ORM object type and register at the factory. The listener is called when instances of the given type are created, changed or removed."
(https://support.intershop.com/kb/index.php/Display/2G3270#Cookbook-ORMLayer-Recipe:NotificationofPersistentObjectChanges)
However, we cannot find a cookbook for registering the listener at the factory. What do we need to do to register the listener?
Also, if there is some better way for handling dependencies to system objects on our custom objects during delete event, I'm open to suggestions.
UPDATE:
This is the listener class I have tried with so far:
public class ProductDeleteListener implements ORMObjectListener<ProductPO> {
#Inject
ProductPOFactory productPOFactory;
/** The Constant LOGGER. */
private static final Logger LOGGER = LoggerFactory.getLogger(ProductDeleteListener.class);
public ProductDeleteListener() {
productPOFactory.addObjectListener(this, new AttributeDescription[0]);
}
#Override
public boolean isOldStateNeeded() {
// TODO Auto-generated method stub
return false;
}
#Override
public void objectChanged(ProductPO object, Map<AttributeDescription, Object> previousValues) {
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("PRODUCT LISTENER TEST - CHANGE");
}
}
#Override
public void objectChanging(ProductPO object, Map<AttributeDescription, Object> previousValues) {
// TODO Auto-generated method stub
}
#Override
public void objectCreated(ProductPO object) {
// TODO Auto-generated method stub
}
#Override
public void objectCreating(ProductPO object) {
// TODO Auto-generated method stub
}
#Override
public void objectDeleted(ORMObjectKey objectKey) {
// TODO Auto-generated method stub
}
#Override
public void objectDeleting(ProductPO object) {
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("PRODUCT LISTENER TEST - PRE DELETE");
}
}
}
But it is not working. Nothing gets logged when object changes or gets deleted.
In addition to what Willem Evertse wrote you need to place your registration code in a class that gets instantiated via Intershop Component Framework.
implementation.component:
<components xmlns="http://www.intershop.de/component/2010" scope="global">
<implementation name="ProductDeleteListenerRegistrar"
class="your.fullqualifed.ProductDeleteRegistrar" start="start" stop="stop"></implementation>
instances.component:
<components xmlns="http://www.intershop.de/component/2010"> <instance name="ORMValidator" with="ORMValidator" scope="global"/></components>
You need to write a class, e.g. ProductDeleteRegistrar and provide start method in which you can add registration calls like Willem described. As for stop method you need to safely unregister your object listener. Make sure both methods are declared to be synchronized.
I think registering a listen would be the right approach. Maybe just look out for performance problems.
You are right that there are no examples of this, but here is an example.
Get the factory that you want to receive messages from. In your case, it is ProductPOFactory
ProductPOFactory productFactory = (ProductPOFactory) NamingMgr.getInstance().lookupFactory(ProductPO.class);
productFactory.addObjectListener(new MyProductChangeListener());
MyProductChangeListener needs to extend AbstractORMObjectListener<ProductPO>
and implement the method public void objectDeleting(T object)
Every time a product gets deleted your listener should be called and then you can clean up your custom orm objects. You can have a look at ImageSetDefinitionPOListener as an example
I have a “Check” Direct Menu Item contributed in my fragment.e4xmi. It’s selected state should reflect the value of a boolean preference. Setting the preference in the #Execute method works fine:
#Execute
public void execute(MMenuItem item, #Preference IEclipsePreferences preferences) {
preferences.putBoolean("selected", item.isSelected());
}
But initializing the DirectMenuItem’s selected state from the preference doesn’t work:
#PostConstruct
public void init(MMenuItem item, #Preference("selected") boolean selected) {
item.setSelected(selected);
}
When the #PostConstruct method is called, the MMenuItem linked with the handler is not yet present in the current context.
Also, moving the setSelected call into #CanExecute doesn’t seem to work; the change made there is not reflected in the UI.
So, how to solve this issue (linking the selected state of a menu item with a boolean preference) in e4?
Doing this in #CanExecute works when using a Handled Menu Item rather than Direct Menu Item. Some UI things don't seem to work well in Direct handlers.
Following up to your question and the discussion in https://dev.eclipse.org/mhonarc/lists/e4-dev/msg09498.html I implemented the following solution for a DirectToolItem.
#Inject
public void initialize(EModelService modelService, MPart part){
MUIElement toolItem = modelService
.find("a.b.c.d.toolitemId", part.getToolbar());
isActive = ((MDirectToolItem) toolItem).isSelected();
}
The #Inject method gets called once, and I know the location of the MDirectToolItem resp. I can inject the part. This seems to suffice to synchronize the e4 application model and my model.
For the record, I've come up with the following add-on:
/**
* The basis for an add-on which synchronizes the {#linkplain MItem#isSelected()
* selection state} of {#link MItem}s tagged with one of the tags passed to
* {#link ItemSelectionSynchronizationAddonBase#ItemSelectionSynchronizationAddonBase(String...)}
* with some external source.
* <p>
* Subclasses need to implement {#link #getSelection(String)} to retrieve the
* desired selection state for a given tag.
*/
public abstract class ItemSelectionSynchronizationAddonBase {
private EModelService modelService;
private MApplication application;
private final List<String> tags;
public ItemSelectionSynchronizationAddonBase(String... tags) {
this.tags = new ArrayList<>(asList(tags));
}
/**
* Injects all objects necessary to work with the E4 Application Model. Not done
* in the constructor simply to keep subclasses unburdened by the knowledge
* about the exact objects needed.
*/
#PostConstruct
public void injectUiModel(EModelService modelService, MApplication application) {
this.modelService = modelService;
this.application = application;
}
/**
* Synchronizes the selection state of all {#link MItem}s found in the
* Application Model when startup is complete. This does <strong>not</strong>
* include items that exist only in part descriptors, but no concrete parts yet.
* These items will be synchronized when the part gets created and
* {#link #partActivated(Event)}.
*/
#Inject
#Optional
public void applicationStartupComplete(
#EventTopic(UIEvents.UILifeCycle.APP_STARTUP_COMPLETE) #SuppressWarnings("unused") Event event) {
synchronizeSelections(application, tags,
EModelService.ANYWHERE | EModelService.IN_MAIN_MENU | EModelService.IN_PART);
}
/**
* Synchronizes the selection state of all {#link MItem}s found in the
* Application Model for the part that was just activated.
*/
#Inject
#Optional
public void partActivated(#EventTopic(UIEvents.UILifeCycle.ACTIVATE) Event event) {
MPart part = (MPart) event.getProperty(UIEvents.EventTags.ELEMENT);
synchronizeSelections(part, tags, EModelService.IN_PART);
}
/**
* Synchronizes the selection state of all {#link MItem}s with the given tags.
* Should be called by the subclass when the value changes in the external
* source.
*/
protected void synchronizeSelections(List<String> tags) {
synchronizeSelections(application, tags,
EModelService.ANYWHERE | EModelService.IN_MAIN_MENU | EModelService.IN_PART);
}
private void synchronizeSelections(MUIElement searchScope, List<String> tags, int searchFlags) {
List<MItem> items = modelService.findElements(searchScope, null, MItem.class, tags, searchFlags);
for (MItem item : items) {
for (String tag : tags) {
if (item.getTags().contains(tag)) {
item.setSelected(getSelection(tag));
}
}
}
}
/** Gets the current selection state associated with the given tag. */
protected abstract boolean getSelection(String tag);
}
Subclasses can then override getSelection to, e.g., use the tag as a basis for retrieving a preference or (as is done in my code) getting the value from a Java bean. Just note that getSelection takes only care of one sync direction (pull). The subclass will also need to call synchronizeSelections whenever an event occurs that necessitates a UI update (push, e.g., caused by a PropertyChangeEvent).
I wonder if there is any difference between two parts of code:
//1
public partial class MyPage : System.Web.UI.Page
{
public override void DataBind()
{
base.DataBind();
this.myTableGrid.SetupDataSource();
}
}
//2
public partial class MyPage : System.Web.UI.Page
{
public void Page_DataBind(object e, EventArgs e)
{
this.myTableGrid.SetupDataSource();
}
}
Essentially, they both accomplish the same task. Your Page_DataBind method will be called in base.DataBind() so it might save a teeny tiny (i.e. negligible) amount of cpu clicks as it doesn't have to call the method delegate.
One difference in example 2 is that you can call that method, without having to call DataBind() on the page.
This may prove useful if have a lot of controls on your page but only want to databind a few of them (as databinding can prove to be a costly operation, given that it makes heavy use of reflection and type casts).
I am researching Prism v2 by going thru the quickstarts. And I have created a WCF service with the following signature:
namespace HelloWorld.Silverlight.Web
{
[ServiceContract(Namespace = "http://helloworld.org/messaging")]
[AspNetCompatibilityRequirements(RequirementsMode =
AspNetCompatibilityRequirementsMode.Allowed)]
public class HelloWorldMessageService
{
private string message = "Hello from WCF";
[OperationContract]
public void UpdateMessage(string message)
{
this.message = message;
}
[OperationContract]
public string GetMessage()
{
return message;
}
}
}
When I add a service reference to this service in my silverlight project it generates an interface and a class:
[System.ServiceModel.ServiceContractAttribute
(Namespace="http://helloworld.org/messaging",
ConfigurationName="Web.Services.HelloWorldMessageService")]
public interface HelloWorldMessageService {
[System.ServiceModel.OperationContractAttribute
(AsyncPattern=true,
Action="http://helloworld.org/messaging/HelloWorldMessageService/UpdateMessage",
ReplyAction="http://helloworld.org/messaging/HelloWorldMessageService/UpdateMessageResponse")]
System.IAsyncResult BeginUpdateMessage(string message, System.AsyncCallback callback, object asyncState);
void EndUpdateMessage(System.IAsyncResult result);
[System.ServiceModel.OperationContractAttribute(AsyncPattern=true, Action="http://helloworld.org/messaging/HelloWorldMessageService/GetMessage", ReplyAction="http://helloworld.org/messaging/HelloWorldMessageService/GetMessageResponse")]
System.IAsyncResult BeginGetMessage(System.AsyncCallback callback, object asyncState);
string EndGetMessage(System.IAsyncResult result);
}
public partial class HelloWorldMessageServiceClient : System.ServiceModel.ClientBase<HelloWorld.Core.Web.Services.HelloWorldMessageService>, HelloWorld.Core.Web.Services.HelloWorldMessageService {
{
// implementation
}
I'm trying to decouple my application by passing around the interface instead of the concrete class. But I'm having difficulty finding examples of how to do this. When I try and call EndGetMessage and then update my UI I get an exception about updating the UI on the wrong thread. How can I update the UI from a background thread?
I tried but I get UnauthorizedAccessException : Invalid cross-thread access.
string messageresult = _service.EndGetMessage(result);
Application.Current.RootVisual.Dispatcher.BeginInvoke(() => this.Message = messageresult );
The exception is thrown by Application.Current.RootVisual.
Here is something I like doing... The service proxy is generated with an interface
HelloWorldClient : IHelloWorld
But the problem is that IHelloWorld does not include the Async versions of the method. So, I create an async interface:
public interface IHelloWorldAsync : IHelloWorld
{
void HelloWorldAsync(...);
event System.EventHandler<HelloWorldEventRgs> HelloWorldCompleted;
}
Then, you can tell the service proxy to implement the interface via partial:
public partial class HelloWorldClient : IHelloWorldAsync {}
Because the HelloWorldClient does, indeed, implement those async methods, this works.
Then, I can just use IHelloWorldAsync everywhere and tell the UnityContainer to use HelloWorldClient for IHelloWorldAsync interfaces.
Ok, I have been messing with this all day and the solution is really much more simple than that. I originally wanted to call the methods on the interface instead of the concreate class. The interface generated by proxy class generator only includes the BeginXXX and EndXXX methods and I was getting an exception when I called EndXXX.
Well, I just finished reading up on System.Threading.Dispatcher and I finally understand how to use it. Dispatcher is a member of any class that inherits from DispatcherObject, which the UI elements do. The Dispatcher operates on the UI thread, which for most WPF applications there is only 1 UI thread. There are exceptions, but I believe you have to do this explicitly so you'll know if you're doing it. Otherwise, you've only got a single UI thread. So it is safe to store a reference to a Dispatcher for use in non-UI classes.
In my case I'm using Prism and my Presenter needs to update the UI (not directly, but it is firing IPropertyChanged.PropertyChanged events). So what I have done is in my Bootstrapper when I set the shell to Application.Current.RootVisual I also store a reference to the Dispatcher like this:
public class Bootstrapper : UnityBootstrapper
{
protected override IModuleCatalog GetModuleCatalog()
{
// setup module catalog
}
protected override DependencyObject CreateShell()
{
// calling Resolve instead of directly initing allows use of dependency injection
Shell shell = Container.Resolve<Shell>();
Application.Current.RootVisual = shell;
Container.RegisterInstance<Dispatcher>(shell.Dispatcher);
return shell;
}
}
Then my presenter has a ctor which accepts IUnityContainer as an argument (using DI) then I can do the following:
_service.BeginGetMessage(new AsyncCallback(GetMessageAsyncComplete), null);
private void GetMessageAsyncComplete(IAsyncResult result)
{
string output = _service.EndGetMessage(result);
Dispatcher dispatcher = _container.Resolve<Dispatcher>();
dispatcher.BeginInvoke(() => this.Message = output);
}
This is sooooo much simpler. I just didn't understand it before.
Ok, so my real problem was how to decouple my dependency upon the proxy class created by my service reference. I was trying to do that by using the interface generated along with the proxy class. Which could have worked fine, but then I would have also had to reference the project which owned the service reference and so it wouldn't be truly decoupled. So here's what I ended up doing. It's a bit of a hack, but it seems to be working, so far.
First here's my interface definition and an adapter class for the custom event handler args generated with my proxy:
using System.ComponentModel;
namespace HelloWorld.Interfaces.Services
{
public class GetMessageCompletedEventArgsAdapter : System.ComponentModel.AsyncCompletedEventArgs
{
private object[] results;
public GetMessageCompletedEventArgsAdapter(object[] results, System.Exception exception, bool cancelled, object userState) :
base(exception, cancelled, userState)
{
this.results = results;
}
public string Result
{
get
{
base.RaiseExceptionIfNecessary();
return ((string)(this.results[0]));
}
}
}
/// <summary>
/// Create a partial class file for the service reference (reference.cs) that assigns
/// this interface to the class - then you can use this reference instead of the
/// one that isn't working
/// </summary>
public interface IMessageServiceClient
{
event System.EventHandler<GetMessageCompletedEventArgsAdapter> GetMessageCompleted;
event System.EventHandler<AsyncCompletedEventArgs> UpdateMessageCompleted;
void GetMessageAsync();
void GetMessageAsync(object userState);
void UpdateMessageAsync(string message);
void UpdateMessageAsync(string message, object userState);
}
}
Then I just needed to create a partial class which extends the proxy class generated by the service reference:
using System;
using HelloWorld.Interfaces.Services;
using System.Collections.Generic;
namespace HelloWorld.Core.Web.Services
{
public partial class HelloWorldMessageServiceClient : IMessageServiceClient
{
#region IMessageServiceClient Members
private event EventHandler<GetMessageCompletedEventArgsAdapter> handler;
private Dictionary<EventHandler<GetMessageCompletedEventArgsAdapter>, EventHandler<GetMessageCompletedEventArgs>> handlerDictionary
= new Dictionary<EventHandler<GetMessageCompletedEventArgsAdapter>, EventHandler<GetMessageCompletedEventArgs>>();
/// <remarks>
/// This is an adapter event which allows us to apply the IMessageServiceClient
/// interface to our MessageServiceClient. This way we can decouple our modules
/// from the implementation
/// </remarks>
event EventHandler<GetMessageCompletedEventArgsAdapter> IMessageServiceClient.GetMessageCompleted
{
add
{
handler += value;
EventHandler<GetMessageCompletedEventArgs> linkedhandler = new EventHandler<GetMessageCompletedEventArgs>(HelloWorldMessageServiceClient_GetMessageCompleted);
this.GetMessageCompleted += linkedhandler;
handlerDictionary.Add(value, linkedhandler);
}
remove
{
handler -= value;
EventHandler<GetMessageCompletedEventArgs> linkedhandler = handlerDictionary[value];
this.GetMessageCompleted -= linkedhandler;
handlerDictionary.Remove(value);
}
}
void HelloWorldMessageServiceClient_GetMessageCompleted(object sender, GetMessageCompletedEventArgs e)
{
if (this.handler == null)
return;
this.handler(sender, new GetMessageCompletedEventArgsAdapter(new object[] { e.Result }, e.Error, e.Cancelled, e.UserState));
}
#endregion
}
}
This is an explicit implementation of the event handler so I can chain together the events. When user registers for my adapter event, I register for the actual event fired. When the event fires I fire my adapter event. So far this "Works On My Machine".
Passing around the interface (once you have instantiated the client) should be as simply as using HelloWorldMessageService instead of the HelloWorldMessageServiceClient class.
In order to update the UI you need to use the Dispatcher object. This lets you provide a delegate that is invoked in the context of the UI thread. See this blog post for some details.
You can make this much simpler still.
The reason the proxy works and your copy of the contract does not is because WCF generates the proxy with code that "Posts" the callback back on the calling thread rather than making the callback on the thread that is executing when the service call returns.
A much simplified, untested, partial implementation to give you the idea of how WCF proxies work looks something like:
{
var state = new
{
CallingThread = SynchronizationContext.Current,
Callback = yourCallback
EndYourMethod = // assign delegate
};
yourService.BeginYourMethod(yourParams, WcfCallback, state);
}
private void WcfCallback(IAsyncResult asyncResult)
{
// Read the result object data to get state
// Call EndYourMethod and block until the finished
state.Context.Post(state.YourCallback, endYourMethodResultValue);
}
The key is the storing of the syncronizationContext and calling the Post method. This will get the callback to occur on the same thread as Begin was called on. It will always work without involving the Dispatcher object provided you call Begin from your UI thread. If you don't then you are back to square one with using the Dispatcher, but the same problem will occur with a WCF proxy.
This link does a good job of explaining how to do this manually:
http://msdn.microsoft.com/en-us/library/dd744834(VS.95).aspx
Just revisiting old posts left unanswered where I finally found an answer. Here's a post I recently wrote that goes into detail about how I finally handled all this:
http://www.developmentalmadness.com/archive/2009/11/04/mvvm-with-prism-101-ndash-part-6-commands.aspx