Posts
The development of 4GL Ingres applications happens on Unix.Access to the Unix environment is made possible through windows terminals using a terminal emulator .
When printing a report from inside the 4GL application, the application calls the 'system' command which passes arguments to the 'report' command.The actual report is run and the output is being redirected to the local printer on windows by sending escape sequences to the terminal emulator which open the local printer port and send the data (pure text) to it in RAW format with no translation whatsoever by the windows driver.
The problem is that the report looks not 'pretty' as it consists of dots and dashes acting as placeholders for the textual data.
The presentation would be much better in another format like HTML.
The plan was to :
add HTML tags inside the actual report file,before it is run,so the dot and dashes would be replaced by the tags. In practice each .prln or .pr report command should be tweaked to include the HTML tags.
Then the newly formated file would be send to windows and internet explorer would open it without user intervention as to aid the user in previewing it before it is actually send for printing.
The problem is achieving interoperability,interception and subsequently manipulation of that data by windows, between unix and windows and one solid way is by opening a DBI connection to the Ingres server from windows hence getting and formatting the data on windows. One disadvantage of this approach is that you should swift/rewrite the report logic and queries already there in a certain format/language into equivalent DBI format/language thus creating a new programm for each report (and in a language different than that of the report generation language), in essence this leads to do the work again and in another environment which has cost in time and effort.
Another approach was to write a program that monitors and manipulates the printer queue as to avoid the situation described above.
It would function by checking every job added to the queue and if that job is a text file that contains a unique identifier set by the report then it is forwarded to internet explorer and deleted from the printer queue.
With the queue manipulation approach you don't alter any of the logic ,don't do any of the work again,don't write a new programm; you can tweak the report or use it as is and just capture and manipulate the report's output .
The printer monitoring and job manipulation was done using Perl and the Win32::API module which interfaces with the system dlls and calls the functions residing in them (stopping,resuming a job etc).Since the dlls are written in C it meant getting deep into unmanaged code with,of course, all its associated risks.
It was really hard doing that in Perl as you had to allocate and deallocate memory manually and then parse the printing structures using memory padding specific to the the windows architecture, which amongst others means abusing the 'pack' and 'unpack' functions!Pack to create the structures needed and subsequently passing them into the dll's and 'unpack' for parsing the resulting structures.
At the heart of the programm lies the 'FindFirstPrinterChangeNotification' and 'FindNextPrinterChangeNotification' of the winspool.drv dll, which take note of any printer events and would fire up whenever a new job was added to the queue.
The Win32::Registry module was used to check if there is a default spooling directory and if not it sets the registry entry to $systemroot.'\system32\spool\PRINTERS. That's needed because when there is time to read the file created by the spooler,the programm must know where to look for finding it.
The communication with Internet explorer was achieved using the Win32::OLE module.
A snippet on how to get the default printer :
sub getprinter {
$getdefault=new Win32::API('winspool.drv','GetDefaultPrinterA','PP','N');
$buffer= pack('x4');
$getdefault->Call(0,$buffer);
$buffer=unpack('L',$buffer);
$text=" " x $buffer;
$getdefault->Call($text,$buffer);
print "name of printer : $text\n";
check_registry();
$OpenPrinter=new Win32::API('winspool.drv','OpenPrinterA','PPP','N');
$handle = pack('x4');
$pdefaults = pack('x8L',0x4);
$OpenPrinter->Call($text,$handle,$pdefaults);
$handle=unpack('L',$handle);
}The Win32::API module is cool but maybe a better alternative would be using the Inline C module,which as they say provides a better interface.I haven't tried it yet so I don't have a personal opinion on it.Or maybe use Visual Basic as it is native to the windows environment and has wrapper functions which are translated to api calls.
The downside of this approach is that you have to spend effort in designing the report like it is a valid HTML page but perhaps instead of using HTML the report could be exported in XML ,so to shift away from the presentation layer. But the advantage is that that you can capture the data from unix and alter it in any form desirable.This was an experiment with mixed opinions on its applicability in the real world but still remaining an interesting approach.
When printing a report from inside the 4GL application, the application calls the 'system' command which passes arguments to the 'report' command.The actual report is run and the output is being redirected to the local printer on windows by sending escape sequences to the terminal emulator which open the local printer port and send the data (pure text) to it in RAW format with no translation whatsoever by the windows driver.
The problem is that the report looks not 'pretty' as it consists of dots and dashes acting as placeholders for the textual data.
The presentation would be much better in another format like HTML.
The plan was to :
add HTML tags inside the actual report file,before it is run,so the dot and dashes would be replaced by the tags. In practice each .prln or .pr report command should be tweaked to include the HTML tags.
Then the newly formated file would be send to windows and internet explorer would open it without user intervention as to aid the user in previewing it before it is actually send for printing.
The problem is achieving interoperability,interception and subsequently manipulation of that data by windows, between unix and windows and one solid way is by opening a DBI connection to the Ingres server from windows hence getting and formatting the data on windows. One disadvantage of this approach is that you should swift/rewrite the report logic and queries already there in a certain format/language into equivalent DBI format/language thus creating a new programm for each report (and in a language different than that of the report generation language), in essence this leads to do the work again and in another environment which has cost in time and effort.
Another approach was to write a program that monitors and manipulates the printer queue as to avoid the situation described above.
It would function by checking every job added to the queue and if that job is a text file that contains a unique identifier set by the report then it is forwarded to internet explorer and deleted from the printer queue.
With the queue manipulation approach you don't alter any of the logic ,don't do any of the work again,don't write a new programm; you can tweak the report or use it as is and just capture and manipulate the report's output .
The printer monitoring and job manipulation was done using Perl and the Win32::API module which interfaces with the system dlls and calls the functions residing in them (stopping,resuming a job etc).Since the dlls are written in C it meant getting deep into unmanaged code with,of course, all its associated risks.
It was really hard doing that in Perl as you had to allocate and deallocate memory manually and then parse the printing structures using memory padding specific to the the windows architecture, which amongst others means abusing the 'pack' and 'unpack' functions!Pack to create the structures needed and subsequently passing them into the dll's and 'unpack' for parsing the resulting structures.
At the heart of the programm lies the 'FindFirstPrinterChangeNotification' and 'FindNextPrinterChangeNotification' of the winspool.drv dll, which take note of any printer events and would fire up whenever a new job was added to the queue.
The Win32::Registry module was used to check if there is a default spooling directory and if not it sets the registry entry to $systemroot.'\system32\spool\PRINTERS. That's needed because when there is time to read the file created by the spooler,the programm must know where to look for finding it.
The communication with Internet explorer was achieved using the Win32::OLE module.
A snippet on how to get the default printer :
sub getprinter {
$getdefault=new Win32::API('winspool.drv','GetDefaultPrinterA','PP','N');
$buffer= pack('x4');
$getdefault->Call(0,$buffer);
$buffer=unpack('L',$buffer);
$text=" " x $buffer;
$getdefault->Call($text,$buffer);
print "name of printer : $text\n";
check_registry();
$OpenPrinter=new Win32::API('winspool.drv','OpenPrinterA','PPP','N');
$handle = pack('x4');
$pdefaults = pack('x8L',0x4);
$OpenPrinter->Call($text,$handle,$pdefaults);
$handle=unpack('L',$handle);
}The Win32::API module is cool but maybe a better alternative would be using the Inline C module,which as they say provides a better interface.I haven't tried it yet so I don't have a personal opinion on it.Or maybe use Visual Basic as it is native to the windows environment and has wrapper functions which are translated to api calls.
The downside of this approach is that you have to spend effort in designing the report like it is a valid HTML page but perhaps instead of using HTML the report could be exported in XML ,so to shift away from the presentation layer. But the advantage is that that you can capture the data from unix and alter it in any form desirable.This was an experiment with mixed opinions on its applicability in the real world but still remaining an interesting approach.
Comments