Order Buttons constantly being Queried

[tmeisinger]

I've create a few buttons on the pf:OrderTab and they are specific by Order Type...

If I leverage the QueryStatusEventHandler of the RegisterHandler, it seems to be called many, many times. I'm not able to UnregisterHandler because I need it to interrogate each Order as it is opened.

Is this as designed? Or, I suppose I'm missing something major.

[BobRichards]

I can only assume the control event handlers are doing what they are supposed to do. In an event driven application, many user interactions can generate flurries of events that are seamlessly handled in the background due the lightweight objects being passed (and usually being ignored by objects that do not match the CommandID).

I'm not sure of your intent, but if you want to enable/disable custom controls based on the Settlement type, perhaps you can use the IWindowManager and subscribe to the ActiveDocumentChanged event.

Code: Select all

IWindowManager wndMgr = GetService<IWindowManager>();
wndMgr.ActiveDocumentChanged += WndMgr_ActiveDocumentChanged;

In the handler, the ActiveDocument property returns an IWindowFrame object. Query the frame GetProperty() method to get the Order. If it is null, it is not an order (it might be the Home screen). If you get non-null, you have an order. Look at the settlement type and enable/disable the buttons you need.

Code: Select all

private void WndMgr_ActiveDocumentChanged(object sender, EventArgs e)
{
    IWindowFrame frame = GetService<IWindowManager>().ActiveDocument;
    IOrder order = (IOrder)frame.GetProperty("Order");
    if (order != null)
    {
        // We have an order...
    }
}

As a reminder to others, make sure you check to make sure the order isn't readonly before you write to it in your custom code (order.IsReadOnly).

[tmeisinger]

We tried to go into production using the QueryStatusEventHandler, but that has caused too much of a slow down.

I was able to utilize the Windows Manager to find when an order has changed, but I am not able to reference the Button's Enabled property. Any chance you could give me a head start?

[BobRichards]

Where do my assumptions break down?

• Previously you wrote a shell package with buttons with invoke handlers and you could enable/disable.
• Now you have added to that package the capability to detect when the user changes windows.
• If the user selects an Order, you can get the order.
• You can determine if the order is writable and its settlement type.
• If all of this is in your package, you should be able to call the enable for the button you created from the prior step.

I have not actually written this code as an example so I don't have any specific help. Is this the jist of whay you have done?

[tmeisinger]

Thanks Bob, I went ahead and registered the invoke handlers upon order change, and then unregister after it is checked. This seems to be much more efficient than what I had before. I was just curious how to reference the Custom Button's Enable property without registering the invoke handlers.

PS: Don't ever think it's you, it's probably always me...

[BobRichards]

Not to stir the pot but we keep the invoke/query handlers active. I'm curious about why your handlers were slowing the system down. We are in and out of the handlers very quickly. You can't reach out to the database or get non-cached data from the mid-tier or it will really slow the system down.

As long as your system works, I'd stay with it.