Validate Trigger with no changes in field does not fire

NAVFuchs

In NAV 2013 when you try to validate a already filled field e.g. the Field "No." in the Sales line, the trigger is not executed, when
the field value is not changed. This is often used to update all fields e.g. Description, sales price etc... It just fires when you delete
the value in the field and re-enter the value.

Is this a bug or shall this be a perfomance issue.

mohana_cse06

I just tried adding below code at end of No. OnValidate trigger

MESSAGE('Fired');

It fired when I entered 1000 and re-entered 1000.

Please check whether you have added any customization by like in OnValidate trigger..

IF xRec."No." <> "No." THEN BEGIN

NOTE: I am using NAV2013 Build 33781

Savatage

Were you trying to F2 like the older versions or did you actually type in the same value?
viewtopic.php?f=32&t=56706

NAVFuchs

typing in the same value does not even fire the trigger. Pressing F2-END-<Enter> also nothing happens. And it doesn't matter which
field you are using. Everywhere the same behaviour.

I am also using Version 7.0.33781.0 together with SQL 2012

Very strange and still no idea.

mohana_cse06

Did you check what I meant in my first post?

NAVFuchs

Did you try to trigger the field without typing in the same value, just to run validate code of the field?

mohana_cse06

You mean to Press F2 and TAB without entering value again?

I tried few scenarios here

1. retype value + TAB - validate trigger fired in both NAV2009R2 and NAV2013
2. lookup and select value + TAB - validate trigger fired in NAV2009R2 but not in NAV2013
3. Press F2 + TAB - Validate trigger not fired in NAV2009R2 and NAV2013 but fired in NAV2009R2 Classic

Whats happening? :?:

Tommy_Schou

1. retype value + TAB - validate trigger fired in both NAV2009R2 and NAV2013
2. lookup and select value + TAB - validate trigger fired in NAV2009R2 but not in NAV2013
3. Press F2 + TAB - Validate trigger not fired in NAV2009R2 and NAV2013 but fired in NAV2009R2 Classic

Using build 33995 here and get the same behavior here. .

NAV 2013 seems to check whether you have actually edited the field before firing the trigger. Pressing F2+Enter will, as you have found, NOT fire the trigger anymore.

Just something to get used to I guess.

beran

This behavior is by design. It is assumed that tabbing through a field is (should) not changing (change) the state of the current row at all. The tabbing does not even touch the business logic running on the client and even if the same value is entered Again the logic is not touched.

The three-tier client has been optimized to only call the server if it is absolutely needed since the latency can be fairly high. Tabbing through fields can become very slow with high latency.

The validation of the client is also changed handling differently than the original 2-tier client. If a field has errors the cursor can be moved to the next fields. This is done due to the fact that the WinClient cannot keep focus in one field and hence we chose to solve it this way.

mohana_cse06

beran wrote:

The tabbing does not even touch the business logic running on the client and even if the same value is entered Again the logic is not touched.

But lets say I have added Item 1000 without Ge. Prod. Posting Group and while posting it throws error.

I went to Item card and set Gen. prod. Posting Group and selected same 1000 from lookup.

It should get the Gen. Prod. Posting Group which is working in NAV2009R2 but not in NAV2013.

jglathe

Hi,

beran wrote:

This behavior is by design. It is assumed that tabbing through a field is (should) not changing (change) the state of the current row at all. The tabbing does not even touch the business logic running on the client and even if the same value is entered Again the logic is not touched.

This breaks the use pattern of NAV, as Mohana mentioned. You cannot revalidate a value already entered. A lot of business logic is relying on this. At least F2-TAB and F2-Enter should work.

What really scares me is the "by design" statement. Sounds for me like mitigating the effect of a bad decision with more bad decisions. This isn't a new product being created here, it has more than 20 years of history. But using RTC feels more like a first attempt on an ERP GUI.

with best regards

Jens