Yosvel wrote:
> when i just call _HrQueryAllRows i got the following error:
>
> Unhandled exception at 0x3553e82b in Mail.exe: 0xC0000005: Access
> violation reading location 0x01374008.
>
> And I have already initialized mapi and mapi utils... :-(
>
> Any suggestion????
I haven't tried this myself for a long time, but -
Is this the same function as before - the @24 one? You do realise, I hope,
that the @24 is there for a reason - it means the function is __stdcall and
not __cdecl, i.e. if you're typedefing it yourself you need
typedef HRESULT (*__stdcall PFNHrQueryAllRows)(
LPMAPITABLE ptable,
LPSPropTagArray ptaga,
LPSRestriction pres,
LPSSortOrderSet psos,
LONG crowsMax,
LPSRowSet FAR * pprows
);
or similar - I forget where the * goes w.r.t. the calling convention.
If you don't get this right then the stack is left in a mess and things will
go wrong when you try to exit a function; it'll expect to find the return
address on the top of the stack but instead it'll find arguments left from
your HrQueryAllRows call. (The distinction is that __cdecl functions expect
their caller to clean up the arguments on the stack and __stdcall a.k.a.
PASCAL functions expect the function itself to clean up the arguments; if
you call a __stdcall function from code that thinks its calling a __cdecl
function then no-one cleans up the stack.)
There's probably macros defined in the MAPI headers to mean __stdcall more
portably (STDMETHODCALLTYPE at first glance) although if you need to specify
the @24 on the GetProcAddress then that isn't portable anyway.
Mind you, the address in your error doesn't look like things I'd expect to
see in a function stack anyway, and if you're in debug mode then the debug
runtime's checkesp should have caught this. But, off the top of my head,
this is my best guess what's happening.
Good luck,
Rup.
