What a fascinating idea. Have been asked to look at an issue with batch printing of a report using RDLC layout in which some of the documents are more than one page - the issue being a mismatch in later documents of the data in page header and the main body. One idea that came to mind was that as asking BC to print n reports in one go exposed a bug that does not exist when printing each report separately, wouldn't it be nice to invoke the print operation n times instead. (OK likely inefficient). I'll keep it in mind in case I fail to solve the problem! Thank you again.
Dear Eric, Is there any way to add custom images to the actions? For example: in action when put property image you will get list of named image.... Example image = report. So, is there any method to add custom image? Or add it to appear in the list of actions? Best Regards, Nav
I created a monthly report with customer transactions that I wanted to send in the same manner as the Customer Statement with Email and Print if no email. Can you separate the output to different types? I tried to mimic the custom layout codeunit the statements uses but I feel it is overly complex and prone to not working (having to define the customer document layout instead of just using an email). What would you do - try to use the existing framework or build a more complex wrapper report?
How do those 4 FR lines actually do anything is boggling my mind. You are setting the FR := Ref.Field(1); // this chooses the field on the customer that the field ref points to, correct? Then you are setting the the FieldRef to the current customer using the FR.setrange(Customer."No."); After that, you are repeating a similar process for the Date Filter field on he next 2 lines. How does the FR affect the report or the RecordRef that you are passing in to the report? Great video... as always!
All "ref" variables are pointers, so FR := Ref.Field() creates a pointer to the field, and FR.Setfilter will then set a filter on that field the pointer points to.. in this case a recordref that's again pointing to an actual record. It's like programming C all over again :)
I don't know AL at all but i assume that AL doesn't have generics built in. So, if AL had generics, than this could easily be extended to work with any report ! Waiting for AL generics :p
Wow! Great lesson to understand how to use many advanced elements of the AL language. Thank you very much!
Thank you for this video. Great stuff again. This even helps me in an actual customer project.
What a fascinating idea. Have been asked to look at an issue with batch printing of a report using RDLC layout in which some of the documents are more than one page - the issue being a mismatch in later documents of the data in page header and the main body. One idea that came to mind was that as asking BC to print n reports in one go exposed a bug that does not exist when printing each report separately, wouldn't it be nice to invoke the print operation n times instead. (OK likely inefficient). I'll keep it in mind in case I fail to solve the problem! Thank you again.
Cool Erik
Dear Eric,
Is there any way to add custom images to the actions?
For example: in action when put property image you will get list of named image....
Example image = report.
So, is there any method to add custom image? Or add it to appear in the list of actions?
Best Regards,
Nav
What actions?
@@Hougaard I meant any action. Is there any way to add custom image to it?
Best Regards,
NAV
I created a monthly report with customer transactions that I wanted to send in the same manner as the Customer Statement with Email and Print if no email. Can you separate the output to different types? I tried to mimic the custom layout codeunit the statements uses but I feel it is overly complex and prone to not working (having to define the customer document layout instead of just using an email). What would you do - try to use the existing framework or build a more complex wrapper report?
Why wouldn't you use FIELDNO("No.") to return the field number for the field refs?
... but then I wouldn't show off my incredible talent for remembering useless information?
How do those 4 FR lines actually do anything is boggling my mind.
You are setting the FR := Ref.Field(1); // this chooses the field on the customer that the field ref points to, correct?
Then you are setting the the FieldRef to the current customer using the FR.setrange(Customer."No.");
After that, you are repeating a similar process for the Date Filter field on he next 2 lines.
How does the FR affect the report or the RecordRef that you are passing in to the report?
Great video... as always!
All "ref" variables are pointers, so FR := Ref.Field() creates a pointer to the field, and FR.Setfilter will then set a filter on that field the pointer points to.. in this case a recordref that's again pointing to an actual record.
It's like programming C all over again :)
I don't know AL at all but i assume that AL doesn't have generics built in.
So, if AL had generics, than this could easily be extended to work with any report !
Waiting for AL generics :p