"Ken Krugler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > >I have a table with a custom draw procedure. When the draw procedure get's > >called (from TblDrawTable/TblRedrawTable), the globals are pooched. > > Any OS routine can use/modify/trash register A4, as long as it > restores it before returning to the caller. Callbacks which access > globals have to ensure that A4 is set up correctly. Your technique is > one way of handling this. For other situations where there's no good > place to stash the pointer, you can either use a feature (slow but > easy) or set up a bit of callback glue code (fast but tricky).
Wouldn't this be true for all code that uses callbacks, and not just for shared libraries? (i.e. if the OS code is bashing A4, then a "normal" program would be unable to access globals in its callback function). The only other code that I have that is susceptible to problems is the event handler callbacks for the forms in my shared library. I haven't run into any problems so far, but it is possible... I'm not familiar with "callback glue code". I did some searching in the KB, and I'm left guessing it would involve using DmWrite to patch the function on the fly with code to set A4... could you englighten me? (or better yet, point me at a sample?) Thanks David -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
