Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GLFW.SetWindowUserPointer/GLFW.GetWindowUserPointer #206

Closed
Mark-Bowers opened this issue Aug 25, 2020 · 3 comments
Closed

GLFW.SetWindowUserPointer/GLFW.GetWindowUserPointer #206

Mark-Bowers opened this issue Aug 25, 2020 · 3 comments

Comments

@Mark-Bowers
Copy link

I would like to be able to have access to glfwSetWindowUserPointer and glfwGetWindowUserPointer to avoid having to access a global, variable that contains the application context, from my callback functions. Unfortunately these functions have been appropriated the GLFW package as a way to keep track of a window's registered callbacks.

Is there any interest in a PR that supports the GLFW.SetWindowUserPointer/GLFW.GetWindowUserPointer APIs?

@jayschwa
Copy link
Member

Sure, as long as it doesn't mess up callbacks or make them slow. I imagine the way to do it is nest the callbacks and optional application pointer into an object, and the pointer to that parent object is what gets attached to the GLFW window.

@Mark-Bowers
Copy link
Author

Thanks, that was the exact approach I had in mind. I'll give it a try.

@Mark-Bowers
Copy link
Author

It turns out I don't need these functions after all. I am now using the following technique:

GLFW.SetKeyCallback(s.window, (w,k,sc,a,m)->keyboard(s,w,k,sc,a,m))

where s is my context parameter and a local variable in the function that I am calling SetKeyCallback from and keyboard is my callback function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants