I disagree about the usability of C++ class methods as callback targets. Everyone who has replied thus far is correct in noting that the *direct* callback target must be a static method, but I like going this route anyway: the static method finds a class object pointer, somewhere, and immediately forwards its arguments to a class method to do the actual callback processing.
For a PalmOS Table, for instance, the class object pointer can be stashed away using TblSetRowData (for the zeroth row, for instance). For Lists, I've never done it, and don't see a handy place to store the object pointer; but it's not too bad to simply store the currently relevant pointer in some static variable, making the code non-re-entrant, if it's clear that that's not going to be a problem. Or you can make an associative map from PalmOS widget to C++ class object; in any case I can think of, a linear search would be an adequate map-lookup implementation, as there won't be more than a couple members in the map. At 09:51 AM 8/26/2002 -0400, Ken Savela <[EMAIL PROTECTED]> wrote: >Hi, Bill. > >If you didn't do this already, you must specify the function as >static since there's no way to directly specify the "this" >pointer using a simple callback function. The compiler is >complaining about the function's signature because the implied >"this" parameter is part of the signature. > >In general, callback functions in C++ (when called from things >like X, etc.) really need to have extern "C" binding to be truly >portable since these callbacks are called as C functions and >there is no requirement that C++ and C have the same calling >conventions (registers, parameter passing conventions, and so >forth). I think you can get away with simply using static, >however, with PalmOS. > >With respect to the object oriented-ness of callback functions >under PalmOS, I've found that this is often more trouble than >its worth. If I recall correctly, most PalmOS callback >functions do not allow for a "user data" parameter as do other >environments such as X-Windows. This "user-data" parameter is >handy for passing to the callback function a pointer-to-void >that can be cast to a pointer to some class. You can then wrap >a class member function with a simple function (with extern "C" >binding, of course) that takes the user data parameter and casts >it to a pointer to the proper class and then calls the member >function. Without such a user data parameter, it becomes much >more difficult to determine "this". I've found that a nice >clean procedural design in these cases is simpler than trying to >force an object oriented solution. But, that's just my opinion. > >Good luck. > > >Bill Heidler wrote: > >>A couple of weeks ago I tried to use an object class method in >>a call to >>TblSetLoadDataProcedure( ), and couldn't get it to work. I got a >>compile-time error to the effect that the function signature >>didn't match >>TableLoadDataFuncType, and the only difference was that the >>class method was >>qualified by the class name (sorry, I don't have the exact >>error message >>handy, but can construct an example if necessary). >> >>Has anyone else run into this, or know a way around it? I >>tried various >>kinds of casts, etc., to no avail. I do not consider myself a >>C++ language >>"expert", but definitely believe in using OO techniques as much >>as possible. >> >>Thanks, >>Bill Heidler >> >> >> >> > > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
