Message_PrintTypeOdd and Message_PrintTypeKnown

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”.

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.

Interesting idea, Fred – thank you – but it makes no difference.

   REM Respond with PrintTypeKnown

   wpb%!12 = pm_myref%

   wpb%!16 = Message_PrintTypeKnown%

   SYS Wimp_SendMessage%, 17, wpb%, handle%

(gotta love Textile…)

Try sending as 19, not 17. That should prevent !Printers getting its own original message back.

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.

Assuming I understand things correctly, the following should work:

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 Respond with PrintTypeKnown
   handle% = wpb%!4
   BPUT#lf%, "Handle = " + STR$(handle%) + " (&" + STR$~(handle%) + ")"
   pm_myref% = wpb%!8
   wpb%!0  = 20
   wpb%!12 = pm_myref%
   wpb%!16 = Message_PrintTypeKnown%
   SYS Wimp_SendMessage%, 17, wpb%, handle%
   PROCprint(fname$)
  ENDIF

This works for me. After running you will need to quit using the task manager

ON ERROR ON ERROR OFF: ERROR EXT 1, REPORT$ +" ("+STR$(ERL)+")":END

DIM msgs% 4
!msgs% = 0

SYS "Wimp_Initialise", 310, &4B534154, "PrintTest", msgs% TO , task_handle%

m_size% = 0
m_task_handle% = 4
m_my_ref% = 8
m_your_ref% = 12
m_action_code% =16

filetype% = &FFF

DIM blk% 256
blk%!m_size% = 44 + 12
blk%!m_your_ref% = 0
blk%!m_action_code% = &80142: REM Message_PrintSave
blk%!36 = 8
blk%!40 = filetype%
$(blk%+44) = "TestFile"+CHR$0
SYS "Wimp_SendMessage", 18, blk%, 0

REPEAT
    SYS "Wimp_Poll", 1, blk% TO event_code%
    CASE event_code% OF
        WHEN 17, 18:
            CASE blk%!m_action_code% OF
                WHEN 0: END
                WHEN &80142: ERROR 1,"PrintSave"
                WHEN &80144: ERROR 1,"PrintError"
                WHEN &80140: REM IGNORE ERROR 1,"PrintFile"
                WHEN &80145: REM ERROR 1, "PrintTypeOdd"
                    IF blk%!m_your_ref% <> 0 THEN
                        REM print file directly
                        blk%!m_action_code% = &80146 : REM PrintTypeKnown
                        blk%!m_your_ref% = blk%!m_my_ref%
                        SYS "Wimp_SendMessage", 17, blk%, blk%!m_task_handle%
                    ELSE
                        IF blk%!40 = filetype% THEN
                            REM Print file saved in datasaveack path at blk% + 44
                            blk%!m_action_code% = &80146 : REM PrintTypeKnown
                            blk%!m_your_ref% = blk%!m_my_ref%
                            SYS "Wimp_SendMessage", 17, blk%, blk%!m_task_handle%
                        ENDIF
                    ENDIF
                WHEN &2: REM ERROR 1, "DataSaveAck"
                    SYS "XOS_GenerateError" ,blk%+44 TO A$
                    out%=OPENOUT(A$)
                    IF out% <> 0 BPUT#out%,"TEST":CLOSE#out%
                    blk%!m_action_code% = 3: REM dataload
                    blk%!m_your_ref% = blk%!m_my_ref%
                    SYS "Wimp_SendMessage", 17, blk%, blk%!m_task_handle%
            ENDCASE
    ENDCASE
UNTIL 0

Assuming I understand things correctly, the following should work

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.

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 <PrinterType$5> which worked with both PrintPDF and SPrinter (which baulks at text files but at least it offered a savebox).

WHEN &80145: REM ERROR 1, "PrintTypeOdd"
  IF blk%!m_your_ref% <> 0 THEN
    REM print file directly
    out% = OPENOUT("<PrinterType$5>")
    IF out% <> 0 BPUT#out%,"TEST" : CLOSE#out%
    blk%!m_action_code% = &80146 : REM PrintTypeKnown
    blk%!m_your_ref% = blk%!m_my_ref%
    SYS "Wimp_SendMessage", 17, blk%, blk%!m_task_handle%
  ELSE

PrinterType$5 appears to be just the ‘output to file’ setting in the printer’s configuration. OPENOUT("printer:") should work. printer$path is just set to the selected <PrinterType$n> 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.

I only got consistent results by using <PrinterType$5>

<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.

I didn’t know if the program Dave is writing prints it’s own files or not

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.)

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.

Hello Dave.
I’ve got Printer Manager 1.81 (01-Jun-13) RISC OS 5.23
Here I’ve got

PrinterType$0 : null:
PrinterType$2 : devices#buffer3:$.Serial
PrinterType$5 : RemotePrinterFS#proto=JetDirect;host=printer:
where 5 is a networked print spooler connected to HP LaserJet.

If I select the PDF type printer I get
PrinterType$0 : null:
PrinterType$2 : devices#buffer3:$.Serial
PrinterType$5 : Boot:^.Printing.Files.PsOut

I haven’t got a type 13 anywhere.

Yes there are still people here

HTH
Ron

<PrinterType$5> doesn’t exist on my system; types 0 and 13 do, and 0 is null:.

As Colin has pointed out using Printer: is the way to go (assuming the right printer is selected).

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.

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.

Although the PRM says that Printers can print text files, I guess the information is well out of date.

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 :-).

As Colin has pointed out using Printer: is the way to go (assuming the right printer is selected).

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.

suggests you should deposit the printout in <Printer$Temp>

Yes, the PRM mentions this too. However during testing I found that Printer$Temp wasn’t defined (Printers 1.84 with PrintPDF and SPrinter installed as printers). Printer: is defined and points to the correct location for the currently selected printer.

As an aside; I also found that when Printers is booted it sets Printer$Path to <Obey$Dir>.,Choices:Printers. but when it’s run it sets Printer$Path to Choices:Printers.,<Obey$Dir>. Is that deliberate?

However during testing I found that Printer$Temp wasn’t defined

It’s defined when Message_PrintFile and Message_PrintTypeOdd are sent. I think it’s needed for background printing.

Ah, thanks. Things start to make sense now. :-)

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.

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.