View RSS Feed

Development Team Blog

Mixing WinPrint 1 and WinPrint 2 Reports

Rate this Entry
In a recent forum message a VDF developer wrote:

I have an issue when a client runs a Winprint II report, then goes back and runs a Winprint 1 Report in the same application. (Winprint error. Could not create a new page!)
The problem is due to this program sending instructions from a WinPrint 1 report to the WinPrint 2 DLL or visa versa.

There are two global winprint objects. One that directs printing instructions to the WinPrint 1 DLL and one that directs printing to the WinPrint 2 DLL.

If your program mixes WinPrint 1 and WinPrint 2 reports then you need to make sure that the global variable WinPrintID is pointing to the corresponding global winprint object. You need to do this before sending any WinPrint instructions otherwise a WinPrint 2 instruction could be sent to the WinPrint 1 DLL or visa versa.

The name of the global WinPrint 1 object is oWinPrint

A copy of the global WinPrint 2 object handle is stored in another global variable ghoWinPrint2

Therefor just before you start sending any WinPrint instructions for a WinPrint1 report try:

Code:
Move oWinPrint to WinPrintID
Just before you send any WinPrint instructions for a WinPrint 2 report try:

Code:
Move ghoWinPrint2 to WinPrintID
You need to do this each time you need to start sending instructions for a particular report. i.e. it is no good to do this just once because this global variable can be set automatically by one of your reports (just not always at the right time).

Any time that the user is able to interact with your program is a bad time to set these variables. This is because you don't know what the user is going to do next and which report they will run. You should set the variable once your program is in a closed loop but before any winprint commands are sent.

If you see an error like the one you have reported then it means that the global variable is pointing to the wrong global winprint object.

Ensure program correctness - Use the Debugger

To make sure that you get this right and understand what your program is doing, I recommend running your application in the debugger. Put a watch on the global variable WinPrintID. Note how it changes.

To get an even better picture, you can right-click on the variable WinPrintID in the Watches panel and select the option "View as Object". This option displays a partial object tree rooted at the object represented by the selected variable. This debugger option works for any variable containing a valid object handle.

Comments