Printing directly to a certain printer based on logic

Namnack

Hi,

I read a couple of unresolved issues regarding the above topic.

It is actually possible to directly print to a certain printer depending on values in e.g. the customer record.

What you can do for example is use the REPORT.MODAL function which checks for a record in the printer selection table based on USERID and reportnumber. In order to print to a designated printer, just temporarily write a new record into the printer selections table, specifying the combination of userid, printername and reportnumber, just before executing the RUNMODAL command. Afterwards the record can be deleted again within the same code.

In order for this to work of course, the record inserted into the printer selection table needs to be unique.

E.g. :

IF RecCustomer.GET(SalesHeader."Sell-to Customer No.") THEN BEGIN
IF RecCustomer.Boolean THEN BEGIN
recPrinterselection.INIT;
recPrinterselection."User ID":=USERID;
recPrinterselection."Report ID":=205;
recPrinterselection."Printer Name":='Printername,CPW2:';
recPrinterselection.INSERT;
REPORT.RUNMODAL(205,FALSE,FALSE,SalesHeader."No.");

recPrinterselection.SETRANGE(recPrinterselection."User ID",USERID);
recPrinterselection.SETRANGE(recPrinterselection."report ID",205); IF recPrinterselection.FIND('-') THEN
recPrinterselection.DELETEALL;

kriki

BlackTiger wrote:

Change your coding style first... It's awful.

1. Was your code perfect and beautiful from the beginning?
2. If your code is perfect and beautiful now, why don't you start teaching him HOW to write it!

einsTeIn.NET

Yes, but afaik the printer selection solution is only possible if the user didn't change the page setup for this certain report. The setup will be stored in the .zup file and will be taken even if there is a record in table print selction.

fverkel

There is another problem.
You need to do a COMMIT before you can use the RUNMODAL.
So the INSERT will be definitive.
--> If there's an error in the report, then the original situation will not be restored.
--> If there is another session with the same USERID, then this will give problems.

ajhvdb

Thx, for sharing the code. Could someone move this to tricks and tips.

Xypher

I would have to protest against this being moved to Tips & Tricks.

Being that most would insist on not hard coding something like this. (Which could cause more problems in the future than it would currently provide useful)

(Including fverkel's mentioned problems as well as others)

kriki

Xypher wrote:

I would have to protest against this being moved to Tips & Tricks.

Being that most would insist on not hard coding something like this. (Which could cause more problems in the future than it would currently provide useful)

(Including fverkel's mentioned problems as well as others)

I agree it is not a Tips&Tricks solution.

ajhvdb

It's a good trick and everytime someone shares code this forum gets better and better. Off course it can be coded in a different way but i've seen snippets of code in this forum done worse.

The idea is good and with the remarks from the replies, I (and others) can make my own decision how or not to implement it. :-# Thx again Namnack and keep on sharing.

Slawek_Guzek

kriki wrote:

1. Was your code perfect and beautiful from the beginning?

BlackTiger wrote:

1. I know, it's hard to believe... Yes, on the second week.

Yesss, we all here know that your'e a code genius.. And all we can learn from your code...

Regards,
Slawek

idiot

BlackTiger wrote:

(ok... let's zi battle begins)

1. I know, it's hard to believe... Yes, on the second week.
2. I believe... Just look at standard code and read coding recomendation. It's enougn.

Here is mine:
1) So, no any "notations" whatsoever. Neither "camel", nor "hungarian". Any notation is stupid in modern coding.
2) Spaces before and after ":=".
3) Full readable names for fields and tables. "Short readable" names for variables.
4) NO spaces in list of parameters for procedure/method.
5) BEGIN on same line as "THEN"
6) Enclose REPEAT..UNTIL in BEGIN..END in constructions like "IF..THEN..BEGIN REPEAT..UNTIL..; END;
7) NO (bloody) BLOCK COMMENTS! ("{...}")
8) Use IF (NOT) Table.ISEMPTY THEN Table.DELETEALL; instead of IF Table.FIND(NEXT,LAST) THEN Table.DELETEALL;

Ok. 8 points enough.

PS:
9) (personal) Use "MethodName();" if method has no parameters.
10) Do not put tablename in "Table.SETRANGE(<tablename>.Field,Value1,Value2);"

I sort of agree with blacktiger except points 1, 4, 6
I prefer not to use BEGIN END if the situation does not call for it, also keep to the same line if situation permits so less scrolling up & down searching for codes (IF ... THEN DO IT).
For 3, I'' like to add not to create variables unless absolutely necessary,
also please don't do funny things like having a function to just return TRUE/FALSE & this function is hidden in some obscure codeunit somewhere & variable was created just for this...
For 8. please help to change all occurrence of standard codings FIND('-') to FIND (NEXT, LAST) so I have less tuning to do, etc..., while we'are at it please also change all instances of similar i := i + 1 into i += 1...
I also prefer linking tables to be specified in OnPreDataItem() rather than DataItemLink, I don't use DataItemLink or DataItemView anymore...

Xypher

DataItemTableView (which I think you were referring to near the end of your post) is still nice to use. That is if you don't want the ReqFilter to show a tab for that dataitem.


But yeah this is turning into another topic. Since the debate on code formatting is purely based on opinion (the computer doesn't care how you type it as long as it can make sense of it) you might as well take the conversation to private messages with BlackTiger