WLX: ListPrint() arguments

tbeu · Post by *tbeu » 2007-08-03, 07:38 UTC

In the printer setup / printer configuration dialog of the lister the default printer, fonts and margins can be set. Default printer and margins are passed to the ListPrint() function of lister plugins (wlx) whereas the fonts are not. Any reason why fonts and font sizes are neglected for ListPrint()?

Post by *ghisler(Author) » 2007-08-06, 19:51 UTC

Originally, the lister plugin interface was developped mainly for graphical plugins, to show exotic image file formats etc. It wasn't meant as a replacement of the internal text viewer, that's why the font wasn't seen as necessary information for the plugin. the same is true for the fonts set for the normal display mode of the internal lister functions.

tbeu · Post by *tbeu » 2007-08-07, 11:52 UTC

Is it by design that only the file name (and extension) is passed to ListPrint() whereas the full path name is passed to ListLoad()?

Post by *ghisler(Author) » 2007-08-09, 15:49 UTC

The name is there just to show it in the print spooler. You can identify the file to be printed via the parameter ListWin.

tbeu · Post by *tbeu » 2007-08-09, 18:55 UTC

Then you must correct the listplugin.hlp which currently reads

FileToPrint The full name of the file which needs to be printed. This is the same file as loaded with ListLoad.

tbeu · Post by *tbeu » 2011-09-15, 07:11 UTC

listplugin.hlp 2.0 still reads

FileToPrint The full name of the file which needs to be printed. This is the same file as loaded with ListLoad.

, however FileToPrint of ListPrint() and FileToLoad of ListLoad() are not the same strings.

Post by *ghisler(Author) » 2011-09-16, 09:23 UTC

What do you mean? Do you get a different name passed to ListPrint than to ListLoad?

tbeu · Post by *tbeu » 2011-09-16, 09:47 UTC

ghisler(Author) wrote:Do you get a different name passed to ListPrint than to ListLoad?

Yes, read above.

Serge1 · Post by *Serge1 » 2013-01-10, 15:48 UTC

ghisler(Author) wrote:..., that's why the font wasn't seen as necessary information for the plugin. the same is true for the fonts set for the normal display mode of the internal lister functions.

Is the reply still relevant to the newer TC versions? If so, what do you think about the following idea:

TC selects one of the fonts (ANSI, ASCII) as a font for lister's parent window. (The parent window is under control of TC). After that, this font is reachable to lister functions by invoking GetCurrentObject() for parent window HDC.

The solution permits to pass down at least one font resource (from three) without changing or extending the current plugin interface API.