Have you ever seen this error:
Assignment is not allowed for this variable? But it’s just a DotNet class that I’m trying to make an instance of. (The class in my example is DocumentFormat.OpenXml.Spreadsheet.Text that is used for adding strings to Excel sheets).
But this is Applied Hacking, so we can use reflection to get around this. Here is “DotNetConstructor”, simplified to a version where the constructor takes just one parameter
The idea is simple, get the ConstructorInfo and Invoke it. To do that, you need a DotNet Array first with the Types of parameters and then antoher array with the parameter values. This function can easily be extended to handle multiple parameters.
So instead of using:
Text := Text.Text('Value');
We can just do:
This seems to be the week for guest blogging, I wrote a post for the NAV team blog about database collations.
One of the oldest features in C/AL and the AL code before that is the TODAY function. It will return the current date from the local computer.
A close friend of TODAY is WORKINGDATE. Working Date is the concept of setting “today” to be something else.
When working with entering data, the ease of type t in a date field for today, and w for working date are good for entering data.
But what about when you’re using TODAY (or WORKINGDATE) in your code?
Yesterday I came across an example in one of our old products:
IF CALCDATE('CM+1D',DueDate) > TODAY THEN
Depending on the current date when the user pressed Post, different things would be posted.
It got me thinking, when is the use of TODAY appropriate in code?
The first valid use case would be to add a timestamp to records, field like “Modified Date, “Created Date”, “Approved Date”. Fields where you are recording the date of a user action.
In most other cases, you should use WORKINGDATE to give your users a chance to control the flow. And if actions in your code depend on Dates – let the user know about this.
Do you have other examples of the bad or good use of TODAY?