How to transfer User options from codeunit to the global function of a table via c/al code

AntonyNgorora7
Member Posts: 18
Hi all,
I have a table called custom table with 7 fields:
- Custom Code datatype: Code;
- Custom Picture datatype: BLOB;
- Expiry Date of type: Date;
- Toxity of type option the options are: , Caution, Danger, and Hazardous;
- Custom Number of datatype: integer;
- Custom Description of type: text and
- Commission of type decimal.
I need to write a codeunit that will be called in the C/AL of the custom table that will transfer user options to the C/AL code.
From the option list the code works perfectly on the onValidate() function:
I have a table called custom table with 7 fields:
- Custom Code datatype: Code;
- Custom Picture datatype: BLOB;
- Expiry Date of type: Date;
- Toxity of type option the options are: , Caution, Danger, and Hazardous;
- Custom Number of datatype: integer;
- Custom Description of type: text and
- Commission of type decimal.
I need to write a codeunit that will be called in the C/AL of the custom table that will transfer user options to the C/AL code.
From the option list the code works perfectly on the onValidate() function:
0
Comments
-
This code works on the OnValidate() of the Toxity field
IF "Custom Toxity" = 1 THEN "Custom Description" := 'Caution'; IF "Custom Toxity" = 2 THEN "Custom Number" := 6; IF "Custom Toxity" = 3 THEN Commission := 99.0;
but when implemented on the codeunit it does not work.0 -
AntonyNgorora7 wrote: »I need to write a codeunit that will be called in the C/AL of the custom table that will transfer user options to the C/AL code.
From the option list the code works perfectly on the onValidate() function:Slawek Guzek
Dynamics NAV, MS SQL Server, Wherescape RED;
PRINCE2 Practitioner - License GR657010572SG
GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-030 -
Hi Slawek_Guzek, my goal is to transfer data from the user option field "Toxity" and change the values of the other fields in the table via the Codeunit global function. I want to call the Cdeunit function in the Toxity - OnValidate(), so that it runs as soon as the user makes an option from the option list.
For example, the codeunit should:
1. When the user chooses the option 'Caution' on the option list the text Caution should be added to the Custom Description field.
2. When the user chooses the option 'Danger' on the option list the Custom Number should be changed to 6.
3. When the user chooses the option 'Hazardous' on the option list the commission field should be changed to 99.0 -
Still not sure if I understand correctly.
Anyway - the codeunit can have a table as a parameter. You can pass your rec (your custom table) to the codeunit call in Toxity - OnValidate, like thisToxity - OnValidate CODEUNIT.RUN(CodeunitID,Rec)
Then inside the codeunit's OnRun trigger you can have your code changing values in your custom table (the one passed in CODEUNIT.RUN call:OnRun(Rec : your custom table) WITH Rec DO BEGIN IF "Custom Toxity" = 1 THEN "Custom Description" := 'Caution'; IF "Custom Toxity" = 2 THEN "Custom Number" := 6; IF "Custom Toxity" = 3 THEN Commission := 99.0; END;
I hope this answers your question. Not sure why do you need to have this in a separate codeunit, and why having the code in the Toxity - OnValidate trigger is not good enough. The only purpose I can think of is add flexilbility and enable different classification by specifying different codeunit ID to be run from Toxity - OnValidate in some setup, and that those codeunits will be added to your solution at later stages.Slawek Guzek
Dynamics NAV, MS SQL Server, Wherescape RED;
PRINCE2 Practitioner - License GR657010572SG
GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-030 -
Thank you very much @Slawek_Guzek It definitely did help, and answered my question.
I had initially put the validation rules in the Toxity - OnValidate trigger and it worked very well.
But I was informed that they prefered for the OnValidate trigger to have less code and to populate the code and validation rules on a Codeunit instead.
I am really grateful.0 -
Unless the ID of the codeunit in the CODEUNIT.RUN(CodeunitID,Rec) line is supposed to be configurable somehow (you specify the id of the codeunit to be run in a variable which is populated eariler in the code from some sort of setup) the Toxity - OnValidate trigger is the best place to put this sort of validation code and it makes a very little sense to move the code to a separate object outside the Toxity - OnValidate trigger
My 0.01£
Slawek Guzek
Dynamics NAV, MS SQL Server, Wherescape RED;
PRINCE2 Practitioner - License GR657010572SG
GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-030 -
That is very true, I agree, and I have taken note of this. Thank you very much for the valuable information.0
-
Why not add a function in codeunit and call that function from onvalidate ? You can pass any variables that you want .
Instead of CODEUNIT.RUN, just call that NewCodeUnit.DoThisFunction.
Putting it in a separate codeunit, makes it easier to maintain and update in the future.Microsoft Certified IT Professional for Microsoft Dynamics NAV
Just a happy frood who knows where his towel is0 -
Putting it in a separate codeunit, makes it easier to maintain and update in the future.
Why spreading given functionality between two objects, rather than having it all in one place, would make it easier to maintain and update in the future?
How about user access management, does managing user permission for two separate objects also make it easier than having to manage the permissions for the table alone?Slawek Guzek
Dynamics NAV, MS SQL Server, Wherescape RED;
PRINCE2 Practitioner - License GR657010572SG
GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-030 -
Having two instead of one objects would not make a big different managing the permissions. Normally once we setup the permission properly, we hardly change it in the future anyway.
It also depends on the requirement and personal preferences. Sometimes it makes sense to put simple codes in one place. However, I found out that normally we can always reuse the functionality elsewhere, so it is easier to maintain it if we have a separate codeunit (instead of putting it on the OnValidate).
Also when working with multiple developer, it is easier to spot and merge objects.Microsoft Certified IT Professional for Microsoft Dynamics NAV
Just a happy frood who knows where his towel is0 -
I have to say I prefer to put a lot of functionality into codeunits. It just makes things much easier to deploy, for instance I know I can fix an urgent bug by deploying a codeunit in the middle of the day, with no service restarts at all.
Where as if this was in a table, I would have to restart all the services, and users would get those error messages "The Definition of table blah blah has changed".0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions