Tech Tuesday: Conditionally Auto Opening an Extender Window with Extender Enterprise

The initial question was straightforward:

I have an Extender window based on the Item Number in the Sales Transaction Entry scrolling window, is there a way to conditionally automatically open the Extender window based on that Item Number?

We can start with the “easy” answer (ignoring the “conditionally” parameter).

Extender can be configured to auto open an Extender window based on a field event (Field Entry, Field Exit, Line Change (for scrolling windows only)).

This works well when you want to open the Extender window every time.

However, this user wanted to conditionally auto open that Extender Window so the Auto Open feature on the Extender window won’t work for that.

Because the auto open on the window won’t work for us, finish creating the the Extender Window normally but do not mark the “Auto Open” checkbox on the window itself.

Once you save the Extender Window, we’ll make a new “Extender Window Group”

 

The idea behind an Extender Window group is that if you have multiple Extender Windows, you can click one menu item and open them all at once.

One extra feature of the Window Group is that with can add “conditions” to each window so that we can restrict our windows being opened if they don’t meet the criteria set.

For example, the customer wanted to open for specific items, so let’s say I wanted the Extender Window to automatically open for Items “ACCS-CRD-12WH”, “128 SDRAM”, and “ACCS-HDS-1EAR”.

Unfortunately, there are a couple of issues we ran into:

• This is an “open condition” meaning that with the restrictions these are the ONLY items that the Extender window would open for. Not just “automatically” – but only these items. The user might not want that restriction (although they usually do).
• But more importantly, this type of restriction isn’t going to work for this purpose.

  The reason why it won’t work as we need it to is that the conditions are all “AND” conditions. So, when testing, what we found is that all conditions must be true to open the Extender Window. Because the Item Number cannot be all these things at the same time, the condition check fails, and the Extender window does not open. Ideally, we would be able to have Extender “OR” these conditions together but at this time that isn’t a feature. Potentially we could have an “One of many” or “In” clause and then list all the items on one condition, but Extender doesn’t let us do that either as of this writing.

The end user suggested that perhaps they could put all the items that should auto-open into a specific Item Class. While that was a good idea (and what we ended up going with), it won’t work in this scenario because Extender can only read values that are on the GP User Interface. And while Item Number, Item Description, etc are on the GP SOP Scrolling window, Item Class is not. For that reason, we cannot use that information directly using a method like this.

But we are using Extender Enterprise, perhaps we can indirectly use the Item Class information?

Warning – Boring Dexterity Internals and “how things work” ahead!

Items that show under the “Additional” menu are the result of adding a Dexterity “form trigger”. The menu items are added in order of trigger registration in Dynamics. Triggers are typically registered before the user logs into the application – but since these “additional menu items” are added per company in Extender, Extender adds them on company login which is almost guaranteed to be last on your GP system making the Extender menu items at the bottom of any GP additional menu list (if there are any put there by other products such as Manufacturing).

Fun fact – the Additional Menu used to be called the “Extras” menu before GP 6. Another useful tidbit was that unlike other “menu items” in GP, we could not reference this Extras/Additional menu or items in that menu in code.

Fast forward quite a few versions with command-based menus in GP 2013 R2. Since then, if enabled, GP has the new “ribbon” that we’re used to seeing in our office products.

Because we are using Extender Enterprise, we have a couple of features that gives us some flexibility.

Extender Enterprise has new “Actions” that we can put on any field in GP. In this case, we can create a new global action for the Item Number field in SOP Entry scrolling window instead of using the “auto open” checkbox on our Extender Window.

Next, because we are Extender Enterprise, we also can write Dexterity sanScript code however we would like (well, as the language and our ability allows!). In this case, we can still only read the same window UI fields to get the Item Number entered by the user – but we can also read the GP tables to find that Item Class Code for the item.

Lastly, we think (We hope.  But since I’m writing this article – it kind of ruins the suspense) that we have the capability to do something based on the above results – namely that we can invoke the correct Extender menu item for our Extender Window.

The next step is to build the Extender Action for this feature. Because we’re going to implement this in our action code, you would want to delete the Extender Window Group for this (unless you needed it for other reasons) and take off the Auto Open checkbox on the Extender Window as well.

The flow of our Extender Action is:

1. Get the “tag” of the Ribbon menu itself for the target window (Sales Transaction Entry)
2. Loop through the item groups on that Ribbon menu looking for the group called “Additional”
3. That is the group the same as “Actions” is the first group on the window. Once we have the group, there is only one item on the Additional group, it is the Additional menu item itself, get the tag for that.
4. Loop through the items on that are on that menu looking for the name of our additional window (SOP Line Extra Data in this example)
5. If we find the menu item named “SOP Line Extra Data”, invoke that menu item.

 

The Dexterity code behind the “Run Dynamics GP script” is somewhat complex and the multiple “for loops” that it uses to iterate through the menus is a bit hard to read unless you walk through the code with “warning” statements to tell where you are in the loop. However the code is well commented and there are only a few spots that you would likely need to change to meet your needs for this type of feature.

The highlights are:

In this piece of the script, we read the Item Number from the GP SOP Entry Scrolling Window and then read the IV00101 table to find out the item class. For this example, we only want to auto-open the Extender window if the item is class “RETAIL”. In Fabrikam, one of the items in this class is ACCS-CRD-25WH.

You can change the condition here to be whatever you want since YOU are now coding the data check yourself.

 

We need to get the menu tag for the window, we need to put in the correct Dexterity GP technical name for the GP window. How to get that name is the topic for another article.

The last piece above is adjusting the name of the Extender menu item that we are looking for. If we really wanted to test our Dexterity skills, we could read the EXT20100 table and find the Extender Window Name based on the Extender_Window_ID that we created. Then compare the value here – but since you aren’t likely going to change that name we can take the easy way and just hard code it.

 

Wrapping it up, what did we learn?

1. Extender has an Auto-Open feature that can be used for the Extender Window
2. Extender can also have multiple Extender Windows attached to Extender Window Groups also with an Auto-Open feature.
3. Extender Window groups can have Restrictions/Conditions attached to them per Extender Window.
4. We can use Extender Enterprise Actions/Scripting to handle our own complex restrictions
5. We can manipulate the GP Additional menu items – in this example we could search the command lists and execute/select an item in this list

 

This example was created using GP 2018 and a zip file of the project can be downloaded HERE.

Regards,
Patrick Roth
eOne