Event Handlers In Acumatica

 

Hello everybody,

today I want to share with you how order of event handlers in Acumatica is organized.

Each graph has list of event handlers for each type of manipultaion. Also new declarations of methods can be added to the start or then end of collection, and there are events which are added in the beginning of collection.

According to T300 event handlers which are added to the end of collection:

    • FieldUpdated(PXCache sender, PXFieldUpdatedEventArgs e)

    • RowSelecting(PXCache sender, PXRowSelectingEventArgs e)

    • RowSelected(PXCache sender, PXRowSelectedEventArgs e)

    • RowInserted(PXCache sender, PXRowInsertedEventArgs e)

    • RowUpdated(PXCache sender, PXRowUpdatedEventArgs e)

    • RowDeleted(PXCache sender, PXRowDeletedEventArgs e)

    • RowPersisted(PXCache sender, PXRowPersistedEventArgs e

Let's say we considered about RowPersisted event. Then the schema will be following:

Base.RowPersisted -> 1st level event handler -> 2nd level event handler. In other words, initially Acumatica code will be executed, and after your code will be executed.

There are also events which has another order which are added to the beginning of the collection:

• FieldSelecting(PXCache sender, PXFieldSelectingEventArgs e)

• FieldDefaulting(PXCache sender, PXFieldDefaultingEventArgs e)

• FieldUpdating(PXCache sender, PXFieldUpdatingEventArgs e)

• FieldVerifying(PXCache sender, PXFieldVerifyingEventArgs e)

• RowInserting(PXCache sender, PXRowInsertingEventArgs e)

• RowUpdating(PXCache sender, PXRowUpdatingEventArgs e)

• RowDeleting(PXCache sender, PXRowDeletingEventArgs e)

• RowPersisting(PXCache sender, PXRowPersistingEventArgs e)

• CommandPreparing(PXCache sender, PXCommandPreparingEventArgs e)

• ExceptionHandling(PXCache sender, PXExceptionHandlingEventArgs e)

From RowPersisting prospective following chain will be executed:

2nd level.RowPersisting  -> 1st level.RowPersisting -> Base.RowPersisting. In other words initially your code will be executed, and only thereafter Acumatica code will be executed and (!!!!) modify your changes to some others. In my practice it was situation, that my changes to RowPersisting was lost because Acumatica basic code removed my code.

Probably you can have question, is there a way to modify this behaviour. What if I want to change order? Yes, it's possible. You just need to use PXAcumaticaEvent template. Look at code below:

protected void DAC_RowUpdated(PXCache cache, PXRowUpdatedEventArgs e, PXRowUpdated del)
{
  //your code can be here 
  if (del != null)
     del(sender, e);
  //or here. Or even in both places
}
Or you can even ignore calling of base code.
protected void DAC_RowUpdated(PXCache cache, PXRowUpdatedEventArgs e, PXRowUpdated del)
{
  //your code can be here 
}
In the second case basic code will not be executed.

With such tricks you can modify behavior in the way you like.

No Comments

Add a Comment
 

 

How To Override Base Event In Acumatica

 

Hello everybody,

Imagine following scenario. You have some code in base class, which you need to change. How to do it. For this purpose you can use PXOverride attribute.

See the following code:

public class YourExtension : PXGraphExtension<SomeBasicGraph>
{
   [PXOverride]
   public void MethodForOverriding(string viewName, IEnumerable items)
   {
      // Method body
   }
}

In case which is presented MethodForOverriding of base class will be called. If you want to avoid it, you can add additional argument to the code, and then manipulate how to call it or even omit calling of method from base logic. Look at the following code:

public class YourExtension : PXGraphExtension<SomeBasicGraph>
{
[PXOverride]
public void MethodForOverriding(string viewName, IDictionary keys, IDictionary values, Func<string, IDictionary, IDictionary, int> methodDel)
{
   //some your code
   int res = methodDel(viewName, keys, values);
   //again some of your code. For example you can modify res.
   return res;
}
}

This is very similar to overriding events of DAC classes as mentioned here

No Comments

 

Add a Comment
 

Deleteddatabaserecord In Acumatica

 

Hello everybody,

today I want to share notice about DeletedDatabaseRecord database field. Sometime in db you can notice DeletedDatabaseRecord field. For example there is DAC Sub. You can even wonder what is this if it is not visible for users? It is purposed Acumatica for monitoring is record deleted, and presented. 

Another area of usage DeletedDatabaseRecord is extension tables. If you want to use extension table, and basic table has DeletedDatabaseRecord, then you should add it to extension table as well.

No Comments

 

Add a Comment
 

 

Auto Discovery Mechanism Of Acumatica Extensibility Framework

 

Hello everybody,

another interesting notice today. 

Imagine following situation.

1. You have base class. Let it is called GraphX. 

2. In your library you created extentions of this grap: GraphXExt1, GraphXExt2 at the same level. For example like this:

public class GraphXExt1 : PXGraphExtension<GraphX>
{
   protected virtual void ARTran_USRProjectID_FieldDefaulting(PXCache sender, 
PXFieldDefaultingEventArgs e) { } } public class GraphXExt2 : PXGraphExtension<GraphX> { protected virtual void ARTran_USRProjectID_FieldDefaulting(PXCache sender, PXFieldDefaultingEventArgs e) { } }

3. Then question, if page will be loaded, which ARTran_USRProjectID_FieldDefaulting will be executed? From GraphXExt1 or from GraphXExt2?

The answer is the last loaded ( !!!!! ). If last loaded by framework will be GraphXExt2 then GraphXExt2 will be the winner. If last loaded will be GraphXExt1 then page will execute ARTran_USRProjectID_FieldDefaulting of GraphXExt1. Acumatica doesn't have any way to configure loading sequence of graphs. It means that it is crazy idea to make changes of the same member in two different graphs.

No Comments

 

Add a Comment
 

 

Extentsion Table In Acumatica With Isoptional

 

Hello everybody,

today I want to notice few words about attribute IsOptional. DAC extension can be mapped by inner join, or by left join statement. 

[PXTable(IsOptional = value)] // default is false, or Inner join
public class DACTableExtension : PXCacheExtension<BaseDACTable>
{
 ... 
}

As far as I understand idea behind name, IsOptional means are there additional items from left join. And if set to true, means yes, there are, and if set to false ( default way ) there are not.

The left join way ( IsOptional = true ) can be used for

  • not synched tables
  • creates extension record when record in base table created or updated
  • calculates default field values if no extension table record is found.
  • can be used as separated DAC ( this is shocking for me from viewpoint why to make extension, which can have separated life).

The inner join ( default ) way:

  • always synched
  • extension records automatically created with connection to base record
  • copies key column values to each extension table
  • removes from original db table record when there is not corresponding extension table record
  • can be used as separated DAC ( for me again this was another surprise )

If to summarise, both ways you can use as separeted DAC

No Comments

Add a Comment
 

 

What Is Companyid In Acumatica

 

Hello everybody,

today I want to notice few words about companyid field. What is it's purpose. Initially Acumatica provides two !!!! companyid. 1 and 2. Why two? The first is for some Acumatica internal usage, and then your company will get id 2. Even if you believe that your company deserve to be 1, you'll get 2 or more. It means that first active company will have id 2 or bigger. So, if you have some DAC which should be used by few companies, then you just add companyid field, make it as key, and that's it, Acumatica will track to which company your entity should belong.

No Comments

 

Add a Comment
 

 

Why Columnwidth Can Be Ignored Or Another Gotcha

 

I discovered recently another gotcha in Acumatica.

The ColumnWidthproperty value is never applied to the UI controls if the Merge property is set to True for the same PSLayoutRule component.

No Comments

 

Add a Comment
 

Grid Toolbar Buttons In Acumatica

 

Hello everybody,

have you ever wondered, that SkinID property may regulate grid toolbar set of buttons? For me it was unknown untill today. Here it is list of id's and buttons according to T200:

  • Primary: Adds the Add, Delete, Fit to Screen, and Exportbuttons to the toolbar. This value is typically used for a grid on a simple edit page that consists of the single grid.
  • Details or DetailsInTab: Adds the Refresh, Add, Delete, Fit to Screen, and Export buttons to the toolbar. This value is typically used for a grid that displays the detail data on a master-detail page
  • Inquire: Adds the Refresh, Fit to Screen, and Export buttons to the toolbar. This value is typically used for grids on inquiry and processing pages
  • Selector: Adds the Refresh and Fit to Screen buttons to the toolbar
  • Attributes or ShortList: Hides the toolbar.

Now I know how to configure buttons of grid

No Comments

 

Add a Comment
 

 

Debugging Learning Algorithm

 

Few notes of how to debug machine learning algorithm:

  1. Get more training examples
  2. Try smaller sets of features
  3. Try getting additional features
  4. Try adding polinomial features
  5. Try increasing lambda
  6. Try decreasing lambda

What those trys can achieve:

  1. fixes high variance
  2. fixes high variance
  3. fixes high bias
  4. fixes high bias
  5. fixes high bias
  6. fixes high variance

1 Comment

  • Alex Turok said

    Hi Yuriy,

    I've just stumbled upon your blog. A cool mix of machine learning and Acumatica development insights! That's really great, keep it up!

 

Add a Comment
 

 

How To Make Efficient Usage Of Neural Networks

 

Small note of how to use more effective of Neural Networks:

1. Use different numbers of hidden layers

2. Different numbers of units per layer

3. Different types of unit

4. Different types of strengths of weight penalty

5. Different learning algorithms

No Comments

 

Add a Comment