## TPrintPreview access violation

Please post bug reports, feature requests, or any question regarding the DELPHI AREA projects here.

### TPrintPreview access violation

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   : EAccessViolationexception message : Access violation at address 41315E33 in module 'OPTOWIN.EXE'. Read of address 00000001.Main ($480):41315e33 +007 OPTOWIN.EXE Preview 849 EnhMetaHasDDB77f203c0 +6f5 GDI32.dll EnumEnhMetaFile41315e64 +018 OPTOWIN.EXE Preview 855 MetafileHasDDB41315e9e +02a OPTOWIN.EXE Preview 862 StretchDrawGraphicAsDIB41319fba +126 OPTOWIN.EXE Preview 3351 TPrintPreview.PrintPages41319c03 +013 OPTOWIN.EXE Preview 3262 TPrintPreview.Printdisassembling:41315e2c public EnhMetaHasDDB: ; function entry point41315e2c 848 push ebp41315e2d mov ebp, esp41315e2f 849 test ecx, ecx41315e31 jz loc_41315e3d41315e3141315e33 > mov eax, [ecx]41315e35 add eax, -$4c41315e38       sub     eax, 241315e3b       jnb     loc_41315e4141315e3b41315e3d     loc_41315e3d:41315e3d       xor     eax, eax41315e3f       jmp     loc_41315e4341315e3f41315e3f     ; ---------------------------------------------------------41315e3f41315e41     loc_41315e41:41315e41       mov     al, 141315e3f41315e43     loc_41315e43:41315e43       neg     al41315e45       sbb     eax, eax41315e47 851   pop     ebp41315e48       ret     8

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

Posts: 10
Joined: July 2nd, 2004, 7:55 pm

Definitely the latest release fixes this issue.
Kambiz

Kambiz

Posts: 2429
Joined: March 7th, 2003, 7:10 pm

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.
sbussinger
Active Member

Posts: 10
Joined: July 2nd, 2004, 7:55 pm

Thank you very much for the suggestions/comments.
Kambiz

Kambiz