Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#42 UserData defined per-callback

open
nobody
None
5
2005-09-22
2005-09-22
Anonymous
No

I noticed that the functions "glutSetWindowData"
and "glutGetWindowData" while not documented, are in
fact implimented. These seem like they could be useful
to provide the address of a class with additional
information on the window - such as virtual functions for
display etc.

I recomend the following however:

1) provide user data on a per-callback basis
2) adopt a doxygen commenting style

for example, in C++ a user could type the following

====================================

class MyClass {
...
static void invokeMouseMember(int button, int state,
int x, int y)
{
((MyClass*)glutGetMouseData())->onMouse(button,
state, x, y);
}

....

MyClass myData;
glutMouseFunc(MyClass::invokeMouseMember);
glutMouseData(&myData);

or even

glutExtendedMouseFunc(MyClass::invokeMouseFunc,
&myData);

or even for c

struct tagMouseData
{
...
};
typedef struct TagMouseData MouseData;

void onMouse(int button, int state, int x, int y)
{
MouseData* data = (MouseData*)glutGetMouseData
();
.....
}

========================================

Discussion

  • Richard Rauch
    Richard Rauch
    2005-09-26

    Logged In: YES
    user_id=854844

    My impression is that adding per-callback data the way that
    you suggest would be problematic. It would perhaps be easier
    to have a glutAddCallbackData() which works with the most
    recent callback registered/selected. The window callback
    registration/use is already wrapped in a macro so window
    callbacks would be relatively easy to tinker with that way.
    Non-window callbacks would be more difficult.

    My initial impression, however, is that this is not an
    appropriate change to make.

    A minor nit-pick about the C++ code is that a member function
    (even a static member function) is not quite the same as a C
    function; technically, passing a pointer to such a function
    can break. You should instead pass the function in as an
    {extern "C" { ... }} construct, in order to be perfectly
    correct. This makes C++ code that wants to use a class
    function to handle callbacks from C code a little messy.