Johannes Wikman NAB Solutions AB CTO

We have apps that runs a lot of different logic from Base Application and other apps in the background, as scheduled tasks or via Web Services (API and/or OData). One scenario that we cannot handle today is when the File.DownloadFromStream() function is invoked, which results in an unhandled “Callback functions are not allowed” error.

We would like to suggest a new platform event to handle this scenario:

OnDownloadFromStream(FileStream: InStream; DialogTitle: Text; ToFolder: Text; ToFilter: Text; ToFile: Text; var Success: Boolean)

Or

OnDownloadFromStream(FileStream: InStream; ObjectPayload: JsonObject; var Success: Boolean)

This event should then be exposed for extensions in codeunit 419 "File Management".

If a subscriber sets the Success parameter to true, the download should be suppressed and no “Callback functions are not allowed” error thrown if running in a background session.

This would make it possible to create extensions that handles all kinds of export of data from Business Central.

I want to suggest a new platform event that makes it possible for us to override the user settings for the Role (which is deciding which role center to use).

A simple suggestion of event signature could be something like this:

    [BusinessEvent(false)]
    procedure GetRoleCenterID(var ID: Integer)
    begin
    end;

And it could be placed in the "System Action Triggers" codeunit..

The ID parameter would then contain the page ID of the Role Center that is configured by the user's profile/role selected in the settings. By changing this ID, the role center page with the new ID will be opened instead.

It could be a more advanced event if you want to, but above would fulfill our needs right now.

Details are found in this Yammer thread: https://www.yammer.com/dynamicsnavdev/threads/2014819869237248

There are no function on RecordRef that corresponds to Record.SetAutoCalcFields()

If we want to loop a RecordRef with a FlowField or Blob field that we need the value for each record, we have to call FieldRef.CalcField() for each record, which is very bad for performance.

Current way:

        FldRef := RecRef.Field(MyFieldNo);
        FldRef2 := RecRef.Field(MyFieldNo2);
        if RecRef.FindSet() then
            repeat
                FldRef.CalcField();
                FldRef2.CalcField();
                // Do something with FldRef.Value() and FldRef2.Value()
            until RecRef.Next() = 0;

I would like a SetAutoCalcField() function that could be used like this:

        FldRef := RecRef.Field(MyFieldNo);
        FldRef2 := RecRef.Field(MyFieldNo2);
        RecRef.SetAutoCalcField(MyFieldNo);
        RecRef.SetAutoCalcField(MyFieldNo2);
        if RecRef.FindSet() then
            repeat
                // Do something with FldRef.Value() and FldRef2.Value()
            until RecRef.Next() = 0;

The syntax could be like this:

[Ok := ] RecordRef.SetAutoCalcField(FieldNo: Integer)

And the function needs to be called once for each field to auto calculate.

Since quite a while we are able to sort on any fields with Record.SetCurrentKey(), even if the fields is not part of a defined key (even though not documented, but reported as document bug).

The corresponding functionality is missing on RecordRef.

On RecordRef we can only set sorting with the RecordRef.CurrentKeyIndex() function, which is bound to the defined Keys on the table.

I have a scenario where I need to find the maximum or minimum value of a given field, but without being able to sort on the specific field I have to loop all records to find out the largest/smallest value and this can of course have a huge negative impact on performance.

I suggest to add a new function on RecordRef with the following signature

RecordRef.SetAscending([FieldNo: Integer [, Ascending: Boolean]])

Parameters:

FieldNo: The number of the field that should be sorted on. If omitted, the sorting for RecordRef would be reset to the primary key in ascending order (similar as RecordRef.Reset(), but it doesn't reset filters)

Ascending: Specifies true if the field should be sorted in ascending order; otherwise false. Default is true.

To sort on more than one field, RecordRef.SetAscending should be called once for each field.

To first sort the RecordRef by field number 1 and then on field number 2:

RecordRef.SetAscending(1);
RecordRef.SetAscending(2);

To first sort the RecordRef by field number 1 descending and then on field number 2 ascending:

RecordRef.SetAscending(1, false);
RecordRef.SetAscending(2);

As discussed in https://www.yammer.com/dynamicsnavdev/threads/1430313497944064

The following code is possible to use today, even though it might not be recommended, and it's not (yet) officially supported:

---

RecRef.Open(27);

RecRef.FindFirst();

VariantRecRef := RecRef;

Codeunit.Run(5431, VariantRecRef);

RecRef := VariantRecRef;

[Do something with the results in RecRef...]

---

In a similar way, this is also possible:

---

RecRef.Open(27);

RecRef.FindFirst();

VariantRecRef := RecRef;

Page.Run(30, VariantRecRef);

---

These are flexible and all, but it just feels as if there are unnecessary (and memory plus performance expensive) casting involved.

I suggest that the platform is improved to support the following overloads of Codeunit.Run() and Page.Run[Modal]():

[Ok := ] Codeunit.Run(Number: Integer, var RecRef: RecordRef)

Page.Run(Number: Integer, RecRef: RecordRef[, FieldNo: Integer])

Page.Run(Number: Integer, RecRef: RecordRef[, FieldRef: FieldRef])

[Action := ] Page.RunModal(Number: Integer, RecRef: RecordRef[, FieldNo: Integer])

[Action := ] Page.RunModal(Number: Integer, RecRef: RecordRef[, FieldRef: FieldRef])

I hope the signatures are self-explanatory.

I found this idea, that is somewhat related. If RecordRef and Record could be casted to each other, above would also be solved. https://experience.dynamics.com/ideas/idea/?ideaid=08a6c1b1-2583-eb11-8ced-0003ff45ceba