Purchasing Order Entry - initial disable email/print

[neil.interactit]

Hi guys,

I am having trouble initially disabling email/print on the Purchasing Order Entry form. In code, I disable ID_RecordSetStatusToMenu, ID_RecordEmail, ID_RecordPrint ... "set status" is disabling fine, but email/print do not disable initially. On the first change within the form, email/print then disable. It feels like there is a handler being called (during the form load) subsequent to my handler(s) that is overriding my logic.

My hooks are:

Code: Select all

        AddHandler _purchaseOrderForm.PurchaseOrder.PropertyChanged, AddressOf PurchaseOrderExtraLogic
        AddHandler _purchaseOrderForm.PurchaseOrder.CreateEnd, AddressOf PurchaseOrderExtraLogic
        AddHandler _purchaseOrderForm.PurchaseOrder.ReadEnd, AddressOf PurchaseOrderExtraLogic
        AddHandler _purchaseOrderForm.PurchaseOrder.CopyEnd, AddressOf PurchaseOrderExtraLogic
        AddHandler _purchaseOrderForm.PurchaseOrder.DeserialiseEnd, AddressOf PurchaseOrderExtraLogic


Can you advise a handler I can use that fires after whatever is enabling email/print?

Cheers,
Neil.

[neil.interactit]

Bump

[Scott.Pearce]

Had a quick look. There are some silly buggers going on with SetPermissions and the ID_RecordEmail tool. What happens if you instead manipulate the permissions collection to control the enable/disable of the emailing tool - i.e. in form (or business logic) setup:

Code: Select all

PurchaseOrder.AbstractPermissionCollection("Email Order").AccessLevel = Security.UserGroup.AccessLevels.Disallow


Try something like that and I'll dig deeper tomorrow. Sorry I can't be more thorough today.

[neil.interactit]

Hi Scott,

Looks like that has me on the right track. My preliminary test here seems to indicate that AccessLevel affects initially but not subsequently (so the opposite of the enabled/disabled approach). I have nailed this by using both approaches:

Code: Select all

        _purchaseOrderForm.UltraToolbarsManager1.Ribbon.Tabs("Main").Groups("Actions").Tools("ID_RecordEmail").SharedProps.Enabled = isAuthorised
        _purchaseOrderForm.PurchaseOrder.AbstractPermissionCollection("Email Order").AccessLevel = IIf(isAuthorised, UserGroup.AccessLevels.Allow, UserGroup.AccessLevels.Disallow)


This has the emailing under control but isn't disabling the printing (initally) ... I had a look through that collection but couldn't spot any print related item ... is there another approach to disabling printing?

Cheers,
Neil.

[Scott.Pearce]

I've worked out why this is happening:

1. When the form first starts, the reports for the particular form are read in by the base form. This causes and event to fire and therefore a base function "UpdatePrintTool" to be called. This checks whether any reports are defined for the form, if there are, enable the print button, if not disable the print button. (i.e. the reports collection has changed, I need to refresh the UI toolbar buttons).
2. The UpdatePrintTool also calls the base "SetPermissions" after it has disabled or enabled the print button (so user permissions can be reapplied over the top).
3. SetPermissions (overridden by the purchase order form) then messes with ID_RecordEmail:

Code: Select all

        If PurchaseOrder.AbstractPermissionCollection("Email Order").AccessLevel <> Security.UserGroup.AccessLevels.Allow Or _PurchaseOrder.ChangeFlag = True Then
            UltraToolbarsManager1.Tools("ID_RecordEmail").SharedProps.Enabled = False
        Else
            UltraToolbarsManager1.Tools("ID_RecordEmail").SharedProps.Enabled = True
        End If


4. Your plugin runs and disables the Email button.
5. The base form calls UpdatePrintTool again before .show-ing.

So, UpdatePrintTool is called twice, and perhaps shouldn't be when a form is being set up initially. Further, your plugin is not hooking in late enough in this process. You should also hook into the forms' .show() event.

[Scott.Pearce]

I created a sample for you:

viewtopic.php?f=27&t=472

[neil.interactit]

Very sweet. Many thanks.

In case it helps others, the solution, from Scott's detail above, boils down to:

Code: Select all

        AddHandler _purchaseOrderForm.PurchaseOrder.PropertyChanged, AddressOf PurchaseOrderExtraLogic
        AddHandler _purchaseOrderForm.PurchaseOrder.CreateEnd, AddressOf PurchaseOrderExtraLogic
        AddHandler _purchaseOrderForm.PurchaseOrder.ReadEnd, AddressOf PurchaseOrderExtraLogic
        AddHandler _purchaseOrderForm.PurchaseOrder.CopyEnd, AddressOf PurchaseOrderExtraLogic
        AddHandler _purchaseOrderForm.PurchaseOrder.DeserialiseEnd, AddressOf PurchaseOrderExtraLogic
        AddHandler _purchaseOrderForm.Shown, AddressOf PurchaseOrderExtraLogic


So, adding the extra handler:

Code: Select all

        AddHandler _purchaseOrderForm.Shown, AddressOf PurchaseOrderExtraLogic


Which fires after all the stuff above.

[Ernst]

you can also go to utility, set permission, and Under Tools, make those buttons disallowed, which makes them disappear from the menu.
Used for Delete button successfully, as client didn't want staff deleting, unsent PO. Which would allow a staff to make a PO, email it to somebody and then delete it.