Message_PrintTypeOdd and Message_PrintTypeKnown
Dave Higton (1515) 3525 posts |
I’m trying to get an application to take over text printing, but it isn’t doing it. The PRM says that the Printer Manager broadcasts a Message_PrintTypeOdd, and that the app should respond by replying with Message_PrintTypeKnown – presumably after acknowledging the Message_PrintType odd so that it doesn’t get returned to sender? Anyway, my app clearly sees the Message_PrintTypeOdd broadcast, and attempts to acknowledge and reply. However, the Printer Manager still says that this printer cannot handle text files. So what am I missing or doing wrong? The relevant section of code is here: WHEN Message_PrintTypeOdd% ftype% = wpb%!40 IF ftype% = &FFF THEN fname$ = FNget_string_ctrl(wpb% + 44) BPUT#lf%, "PrintTypeOdd, fname = " + fname$ + ", event type " + STR$(event%) REM Acknowledge the message to prevent it being passed further or returned handle% = wpb%!4 BPUT#lf%, "Handle = " + STR$(handle%) + " (&" + STR$~(handle%) + ")" pm_myref% = wpb%!8 wpb%!12 = pm_myref% SYS Wimp_SendMessage%, 19, wpb%, handle% REM Respond with PrintTypeKnown wpb%!12 = pm_myref% wpb%!16 = Message_PrintTypeKnown% SYS Wimp_SendMessage%, 17, wpb%, handle% PROCprint(fname$) ENDIF The PROCprint does the printing operation; Gutenprint is invoked and the printout file generated; and it doesn’t poll the wimp. I have used some diagnostic code (removed from the above) which shows that the task name associated with handle% is “Printer Manager”. |
Fred Graute (114) 645 posts |
Try removing the acknowledgement and just send an PrintTypeKnown message in reply. The Wimp won’t broadcast a message further when there’s a reply to it. |
Dave Higton (1515) 3525 posts |
Interesting idea, Fred – thank you – but it makes no difference. |
Rick Murray (539) 13840 posts |
REM Respond with PrintTypeKnown (gotta love Textile…) Try sending as 19, not 17. That should prevent !Printers getting its own original message back. |
Dave Higton (1515) 3525 posts |
No, that doesn’t work. Sending as 19 doesn’t send a message back to the other app – it merely prevents the message from going further. Unless, of course, you meant that I should send as 19 and then again as 17? For how to use User_Message_Acknowledge, see Wimp_SendMessage (&400E7, paper PRM 3-197). The only thing you change is to copy my_ref into your_ref. One other thing: sending as 19 causes another problem; opening a menu from the Printers icon on the icon bar locks Printers up and requires Alt-Break to recover. |
Fred Graute (114) 645 posts |
Assuming I understand things correctly, the following should work:
|
Colin (478) 2433 posts |
This works for me. After running you will need to quit using the task manager
|
Dave Higton (1515) 3525 posts |
I agree with you. One proviso: according to paper PRM 3-263, the call to PROCprint should come before the message reply, but it still doesn’t work, either with the code just as above, or with the print before the message. |
Fred Graute (114) 645 posts |
After some playing around with Colin’s code I got things to work. The main sticking point seems to be the pathname to print to. I only got consistent results by using
|
Colin (478) 2433 posts |
PrinterType$5 appears to be just the ‘output to file’ setting in the printer’s configuration. I didn’t know if the program Dave is writing prints it’s own files or not so the part you quote was added for completeness. Only the task initiating the print will receive it – which is why you check to see if it is a reply – and only if the print queue is empty and the printer is ready. It can be ignored. Note at this point the filetype field is invalid and the filename isn’t a full path. If you ignore the 1st PrinterTypeOdd or you are not printing your own files you save the file when you receive datasaveack which puts it in the queue. When the queued file is ready to print a broadcast (your_ref = 0) PrinterTypeOdd is sent with a valid filetype and full path of the file to print. |
Dave Higton (1515) 3525 posts |
<PrinterType$5> doesn’t exist on my system; types 0 and 13 do, and 0 is null:. Attempts to send to <PrinterType$5> cause an error “… must be given a name…” – not surprisingly. Sending to <PrinterType$13> results in a “doesn’t support text printing” error box, affter which Gutenprint kicks in and prints the file successfully to the printer.
This is the app I referred to in the “Printing plain text” thread in General. The idea is what I suppose might be called a helper app; if someone attempts to print a plain text file, e.g. by dragging a text file to the Printers icon, or by requesting an old app to print that assumed a text printer, then my app should provide the assistance to Printers and convert the text to a form that’s printable by a graphics printer. Although the PRM says that Printers can print text files, I guess the information is well out of date. If I print from an app, that app receives a unicast PrintTypeOdd message. Assuming that the app doesn’t want to re-invent the plain-text-printing-to-a-graphics-printer wheel, it ignores it. Then there’s a broadcast PrintTypeOdd message, which is seen by my TextPrint app; that’s where my above code comes from. (My “old app” that used to use plain text printing is a home accounts app. It prints the transactions, one per line, in 77 columns, assuming a monospaced font. I used to have a Brother M1109 printer, which broadly emulated an FX80 printer. It worked fine. I still use the app, which was originated nearly 30 years ago on an A3000, although it has been updated a bit in the intervening years.) |
Dave Higton (1515) 3525 posts |
I should add that I used Reporter to check whether TextPrint was sending messages OK. It showed the printer manager broadcasting (i.e. sending successively to each app) a PrintTypeOdd message. When TextPrint received it, the next event was TextPrint sending PrintTypeKnown to the print manager. The very next event was an error from the print manager saying that the printer doesn’t support text printing. This is Printers 1.76 (14-Jan-12) on RISC OS 5.22 on a BBxM, if it should make any difference. I guess there are very few people still on the RO scene who have been involved with printing at this level. |
Ron (2686) 63 posts |
Hello Dave. PrinterType$0 : null: If I select the PDF type printer I get I haven’t got a type 13 anywhere. Yes there are still people here HTH |
Fred Graute (114) 645 posts |
As Colin has pointed out using
So you can print text files but just want to get rid of the error message? That might need a different approach using Wimp filters. Or are you planning to provide some kind of control over how text files are printed? Might be difficult if the printing app does its own formatting.
It sure is, text mode printing is less and less supported which is why I added graphics mode printing to StrongED (oh, and to allow printing in colour :-). |
Sprow (202) 1158 posts |
Looking at printer manager (as the sender of the message), and SrcEdit (as an example implementer of receipt of the message), suggests you should deposit the printout in <Printer$Temp> which printer manager will then spot on return and spool to the correct physical printer for you. |
Fred Graute (114) 645 posts |
Yes, the PRM mentions this too. However during testing I found that As an aside; I also found that when Printers is booted it sets |
Colin (478) 2433 posts |
It’s defined when Message_PrintFile and Message_PrintTypeOdd are sent. I think it’s needed for background printing. |
Fred Graute (114) 645 posts |
Ah, thanks. Things start to make sense now. :-) |
Steffen Huber (91) 1953 posts |
Dave, have you tried asking in the newsgroups? If you are lucky, you might get an answer from Martin Würthner, who has intimate knowledge of the RISC OS printing system. |
Dave Higton (1515) 3525 posts |
Here’s the killer experiment. I just changed the source of TextPrint slightly so it accepts files of type Text, Obey and &321 (a file type I picked at random as being very unlikely to be a known filetype), instead of just Text. I dragged a short text file of each of those three types to Printers in turn. The Obey file and the &321 file were printed without an error message. The Text file caused an error message from the Printer Manager, and was then printed OK. There’s a bug in the Printer Manager, isn’t there? It always gives an error message when a text file is dragged to it and another app replies with Message_PrintTypeKnown, even though it subsequently does all the right things. |