Important Notes, Tips & Troubleshooting

Q:	The export of images does not work correctly, what is the cause?

A:	It might be a buggy video card driver (for example we heared that the original Viper 770 drivers cause malfunctions during picture export). Try to obtain a newer or compatible driver.

Q:	The picture export to Metafile (WMF) does not work under Win9x. The VPE function PictureExportPage() returns "failure", what is going wrong?

We experienced that the Windows API function CreateMetaFile() - which is used internally by VPE - can not work with long file names. Accordingly you can not create a Metafile when having long file names within the target directory structure or if the file name itself is a long file name.
Workaround: use the Windows API function GetShortPathName() to convert the long target path / file name into the short form and provide the result to PictureExport[Page]().
NOTE: this problem is only related to Win9x (WinNT 4 SP4 showed no such problems) and only to Metafiles (WMF). All other image types, like Enhanced Metafiles (EMF) and the bitmap file types like BMP, PNG, JPEG, etc. work ok.

If I call VPE.SetupPrinter() the window of our main application is not disabled, it is still running. I would have expected that it is disabled, because if the user pushes a second time onto the "Setup" button in our application, we call a second time VPE.SetupPrinter(). Because VPE is already executing the printer setup dialog, our application crashes. Why isn't the window of our main application disabled automatically?

Because VPE fires events during the setup process to inform your application about the status of the setup, the main window of your application is not disabled by VPE. Solution: disable any GUI element which could cause that VPE.SetupPrinter() is called a second time while the printer setup dialog is shown or disable your application before calling VPE.SetupPrinter() and enable it after the call returns.

We create huge numbers of VPE documents in a batch process. This means, in a loop of hundreds of iterations we permanently call OpenDoc(), export for example the document contents to image files and call CloseDoc() afterwards. Under Win9x we notice that the User resources are shrinking continuously until no resources are left over. Is this a bug in VPE, does VPE have a memory leak?

No, this is not a problem of VPE. It is caused by the design of Win9x: with every call to OpenDoc(), VPE creates internally the invisible windows (Frame, Client, Toolbar, Statusbar, etc.) which are needed for the preview. When calling CloseDoc() all those windows are destroyed and therefore the allocated space on the User Heap is freed.
However, Windows itself does not compact the User Heap unless process control is returned to the Windows subsystem. After deep investigation of this issue, we encountered that you should execute the following code in order to let Windows shrink the User Heap:

VpeCloseDoc();

MSG msg;

while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))

{

TranslateMessage(&msg);

DispatchMessage(&msg);

}

Immediately after calling VpeCloseDoc(), the code above yields process control back to Windows, which will make Windows compact its User Heap. Calling VpeDispatchAllMessages() or Sleep() does NOT help.

NOTE: The problem described above does only occur, if you are running a batch process which does not interact event driven with the user and which executes hundreds of
OpenDoc() / CloseDoc() sequences without yielding process control regularly back to Windows. If you are using VPE normally in a GUI application which is driven by events - as all the demos shipped with VPE are - there will no such problem arise, because process control is automatically returned to Windows after each document has been created.

Q:	A barcode is displayed correctly in the preview, but is not of the same size when printed. Is this a bug?

A:	VPE prints the bar codes in correct size. You need to know the following about barcodes, to understand it:

The width of the thin and thick modules (the black and white lines) have ratios, for example 1:2. This means, thin lines are half as thick as thick lines.

Example: a given barcode has 63 modules, 43 thick and 20 thin modules, and shall be painted into a rectangle which has a width of 10 cm.

The barcode library now computes the maximum width of a single module, so that all modules will best fit into the given rectangle while considering the rule that the thin / thick ratio is 1:2. It can happen then that there are wide gaps at the end of the barcode, because it can not fill the given rectangle.

The preview shows the barcode in the full rectangle, because when drawing to the preview, the barcode library ignores the ratio rule, otherwise - due to the low resolution of the screen - sometimes a barcode would not be shown at all or only in part.

Q:	One and the same barcode is printed in different widths on different printers. Is this a bug, how can I avaoid it?

A:	See the question and answer above. This is caused by different printer resolutions. Workaround: set the printer's resolution of the different printers to the same value, e.g. 300 DPI.

Q:	I embedded the VPE Preview in a window of my own application, but now VPE does not react on keypresses and / or the mouse wheel (and in the Interactive Edition the focus handling does not work properly, if my application looses / receives the focus).

If embedded, the VPE Preview window is a child window of your application's window. Therefore you need to set the focus to the VPE Preview window explicitly everytime the parent window of VPE (this is your application's window) receives the focus (and - of course - if VPE is the active control within that window). Another solution is that you forward all messages of interest (WM_KEYDOWN, WM_MOUSEWHEEL, WM_SETFOCUS, WM_KILLFOCUS) to the VPE Preview window.

FAQ

FAQ