Cancel
Showing results for 
Search instead for 
Did you mean: 

Why is Action Button making multiple calls?

Community Manager Community Manager
Community Manager

The following is an edited email exchange between a Rulestream user and Rulestream support.  It is presented here for the knowledge it contains regarding Action Buttons and Event Handlers.

 

Note: Questions from the user are contained within a box.

 

I have a problem with events caused by an Action button.

I create a Custom part family form, add an Action button and specify a calling function (for example, SelectPrivod).

 

I’ve written the implementation of the method in Custom.vb as follows:

 

Public Sub g_rsEngineer_RsActionButtonClick(ByVal sender As Object, ByVal e As RuleStream.RsActionButtonClickEventArgs) Handles g_RsEngineer.RsActionButtonClick

        Select Case e.FunctionName

            Case "SelectPrivod"

                SelectPrivod()

         End Select

End Sub

 

I notice the following:

·         In different projects (TopLevel PartFamily) the Event is called in different ways

·         At the touch of a button the event can be called 1, 2 or 3 times

·         I can't understand where the double and triple calls come from

·         Mapping handlers in all PartFamilies are empty

Why is this happening?

 

 

Our guess is that you are using autosetRsEngineer as true in the profile, which is a best practice. However, you are also using the “handles” syntax in Custom.vb, which is not a best practice.

 

Here's some additional information from the Release Notes of 8.11.0:

 

Improved mapping of Rulestream events

It is now possible to map event handlers independently on a top-level-part-family basis, meaning different top-level part families within the same rules database can have different event handler functions.

 

A new tab for mapping event handlers on the part family form is displayed, but only on part families that are designated as top-level on their specs. That tab lists all possible events and the rule author may select from a list of possible event handlers that are defined in Custom.vb. A “public sub” declaration that includes an argument with any of the valid “EventArgs” is considered a possible event handler for populating this menu. It is the rule author's responsibility to ensure that any mapped sub has a compatible argument list for the specific event that it is being mapped to.

 

Image.jpg

  

If developing Custom.vb concurrently with mapping events, it is necessary to close and reopen the top-level part family to refresh the list of possible event handlers.

 

Prior to using top-level-part-family event handler mapping, every existing .NET “handles clauses” should be removed from all sub definitions in Custom.vb and the rule author should ensure that they are defined with a public, not private, access level.

 

This change also eliminates that multiple event handler calls that occurred when a running line item had rules from more than one Architect application.

 

“Handles” syntax can’t be used in Custom.vb?

Best practice is Handler Mappings?

 

  • We are not using Handlers mapping for top level Part Family.
  • We have a universal mechanism for all projects. Assigning the same to each project is very inconvenient.

 

We have a way to solve the problem with a regular button and “when changed” event, but prefer the implementation with the ActionButton.

 

Each application is compiled into its own DLL.  Custom.vb (and common.vb) get compiled in as well. If you use the handles syntax you will register one handler for each rule DLL and you will end up with one call to each copy of the same source code.  That is why you were seeing what appeared to be multiple events at the press of a single button.

 

By use of the top-level event handler mapping you will avoid that problem and can keep the event handler functions shorter/simpler as you can map different functions based on the top level part family mappings.