Remove handler from another plugin

[DannyC]

I have two different plugins and they both do stuff on salesOrder.SaveEnd.

In one of the plugins I need to fire the salesOrder.Save() method because I'm writing to the Notes tab. Before I do salesOrder.Save() I remove the plugin's handlers for SaveEnd. That ensures the SaveEnd only fires once.
But this fires the other plugin's SaveEnd event again because I don't know if I can remove the other plugin SaveEnd event handler.

I want both plugins to only fire the SaveEnd event once. What's the trick to removing the handler from another plugin?

version 7.2.1

I'm hesitant to attach the plugins as there's lots of client-specific stuff in there. I hope I've explained the situation enough.

[pricerc]

I am pretty sure a plugin needs to add and remove its own event handlers. I think that's a .NET constraint.

So you would need to have methods in the plugin that do the removing/adding for you.

What might be easier is a "suppress event" property:

Code: Select all

class Plugin1 {
...
public bool SuppressSaveEnd { get; set; }

void SalesOrder_SaveEnd(...)
{
    if(SuppressSaveEnd) return;

    ...
}
...


and in your other plugin:

Code: Select all

class Plugin2 {
...

void SalesOrder_SaveEnd(...)
{
    try
    {
        Plugin2.SuppressSaveEnd = true;
...
    }
    finally {
        Plugin2.SuppressSaveEnd = false;
    }
}
...


If you're not using it for anything else, you could also use the Tag on the sales order:

Code: Select all

class Plugin1 {
...
void SalesOrder_SaveEnd(...)
{
    if((bool) salesOrder.Tag) return;

    ...
}


Code: Select all

class Plugin2 {
...

void SalesOrder_SaveEnd(...)
{
    try
    {
        salesOrder.Tag = true;
...
    }
    finally {
        salesOrder.Tag = false;
    }
}
...


[SBarnes]

I haven’t actually tested this but in each handler make the first line be removing the handler you are in and at the bottom of the handler make the last line being adding it back in as I think that should work.

The only down side is it will change the order the events fire in on future calls.

[SBarnes]

Ok so after testing my previous suggestion, it doesn't work but the attached does.

The Steps are:

1. Makes sure the plugin class is renamed to something unique in each plugin
2. Make the handler public and static in each plugin
3. Have both plugins reference each other.
4. Remove and Add handlers by referencing them through their class name.


Of course the other way which I was trying to help Danny with offline was sticking flags in the generic object collection and bailing out based upon these, my mistake in what I told him to do was the wrong way around the steps should actually be as follows:

1. Set a flag in each handler in the Generic Object collection call them flag1 and flag2 and then remove them at the end of the handler i.e. flag1 in handler1 and flag2 in handler2
2. In handler 2 look for flag 1 if there then return, in handler 1 look for flag2 if there then return

This is probably a better solution than making handlers static etc. but the question was how to add and remove handlers across two plugins which is what the attached does.

[SBarnes]

If you want to see how to do it with flags in the generic object list see the attached.

[DannyC]

Appreciate the responses Ryan and Stuart.
And Stuart, special shout out for fiddling about on a weekend with a couple of sample plugins too.

I went with the generic object collection as the concept was grasped more readily but looking into it deeper I can see how Ryan's solution would also work (basically the same idea as the generic object), and also the class naming option too.

Anyway, I've implemented it at the client site and it's working a treat.

[pricerc]

3. Have both plugins reference each other.

This can cause weird problems, because of the fact that plugins are compiled independently when starting Jiwa.

So if you start Jiwa on a clean machine, you'll be unable to compile either plugin because the dependency on the other one is missing.

[SBarnes]

Yes I am aware of this, it usually involves commenting stuff out to one of them is compiled, that's why the generic object collection flags is a better solution, no references needed at all.

[pricerc]

Yes I am aware of this, it usually involves commenting stuff out to one of them is compiled, that's why the generic object collection flags is a better solution, no references needed at all.

why have I not previously noticed this "GenericObjectCollection" thing that I see is lurking in JiwaApplication.BusinessLogic.Maintenance ?

[SBarnes]

I will admit I know it's there thanks to Mike, it exists on Business Logic objects and on Forms and I think Jiwa Collections.

I use it quite often not only for flags but also if I have added an extra table to Jiwa and then for example have the extra fields on a tab I've added, I keep it in the Generic Object collection and pull it out on things like save end and read end, I added extra images to inventory by doing just that and rolling my own collection item object and Jiwa collection.

I've just used it today for example with a client and the Rest API where we auto print a picking slip on save by setting a flag in the generic object collection and editing the save end for sales orders in the rest api and bailing out if the flag is set we don't send 2 hooks.

It's great for communication across plugins as well.