TPrintPreview access violation

[sbussinger]

I'm running into a problem with TPrintPreview on some customer systems. I haven't found the cause yet and wanted to see if anyone else had run into the issue before. I'm running a somewhat older version of TPrintPreview (4.52) and will be upgrading to the most recent version to see if that helps.

I have madExcept running so I've got some details to work with. Here's an excerpt of the information provided on the exception:

Code: Select all

exception class   : EAccessViolation
exception message : Access violation at address 41315E33 in module 'OPTOWIN.EXE'. Read of address 00000001.

Main ($480):
41315e33 +007 OPTOWIN.EXE Preview            849 EnhMetaHasDDB
77f203c0 +6f5 GDI32.dll                          EnumEnhMetaFile
41315e64 +018 OPTOWIN.EXE Preview            855 MetafileHasDDB
41315e9e +02a OPTOWIN.EXE Preview            862 StretchDrawGraphicAsDIB
41319fba +126 OPTOWIN.EXE Preview           3351 TPrintPreview.PrintPages
41319c03 +013 OPTOWIN.EXE Preview           3262 TPrintPreview.Print

disassembling:
41315e2c     public EnhMetaHasDDB:            ; function entry point
41315e2c 848   push    ebp
41315e2d       mov     ebp, esp
41315e2f 849   test    ecx, ecx
41315e31       jz      loc_41315e3d
41315e31
41315e33     > mov     eax, [ecx]
41315e35       add     eax, -$4c
41315e38       sub     eax, 2
41315e3b       jnb     loc_41315e41
41315e3b
41315e3d     loc_41315e3d:
41315e3d       xor     eax, eax
41315e3f       jmp     loc_41315e43
41315e3f
41315e3f     ; ---------------------------------------------------------
41315e3f
41315e41     loc_41315e41:
41315e41       mov     al, 1
41315e3f
41315e43     loc_41315e43:
41315e43       neg     al
41315e45       sbb     eax, eax
41315e47 851   pop     ebp
41315e48       ret     8


Has anyone run into this error before? Is it by any chance fixed in the more recent versions of TPrintPreview?

[Kambiz]

Definitely the latest release fixes this issue.

[sbussinger]

The latest version did indeed fix my issues! Thanks!

A couple of comments on the changes though: The problems revolved around the MetaHasDDB() routine. You avoided the issues by just not using the routine any longer (though you didn't deleted the no longer used code). Just in case you were considering putting it back in use again I wanted to comment on a couple of potential issues that may have been related to the problems we saw before.

1. You should probably have an "StdCall;" modifier on the callback routine to ensure it's using the correct calling convention.

2. You're using the same callback routine for both the enhanced metafile and older metafile formats. This isn't really going to work because the record structures aren't the same between the two. The lpEMFR^.iType reference isn't going to work for the older metafiles (it'll actually look at the size field in the other record format).

Just wanted to pass this on since I noticed it. It's actually working fine for me without using the routine at all.

[Kambiz]

Thank you very much for the suggestions/comments.