Control(OpenGLSurface).Handle v. DesktopOpenGLSurface.ContextHandle

According to the documents OpenGLSurface was deprecated.

In this documents we can see that the old property “Handle” is now “ContextHandle” and it is an integer.
But when I use it in code “ContextHandle” is a Pointer, not an integer!

Up to now I had used Control(OpenGLSurface).Handle which was an Integer without problems.

I need to use the Handle in a Declare. Which value have I to use?

Thanks for your help.

You’ve put this thread in the private Testers channel for an old, now released version. You should post in General for more public visibility.

1 Like

You are right.
Can I change the channel or do I have to text it again?

Moved to General category.

1 Like

How do you want to make further use of the handle?

Thanks Anthony. How did you do it?

This is the code I have been using for many years and it worked perfectly well.

#If TargetWindows  Then
  #If Target32Bit Then
    LocalPrevWndProc = SetWindowLong(Control(OpenGl_Surface).Handle, GWL_WNDPROC, AddressOf WindowProc)
  #ElseIf Target64Bit
    LocalPrevWndProc = SetWindowLongPtr(Control(OpenGl_Surface).Handle, GWL_WNDPROC, AddressOf WindowProc)

I am a forum moderator.

OpenGLSurface (deprecated) and DesktopGLSurface both have a ‘ContextHandle’ property of type integer. Means ContextHandle’s type should be an integer, not a pointer.
I did not check in the IDE, but if ContextHandle’s type now is a pointer, I would consider it being a bug, at least an inconsistency between IDE and documentation.
Handles and pointers are not the same (ref. Wikipedia)
In Xojo, the term ‘handle’ is used for both handles and pointers:
DesktopControl property ‘Handle’ of type ‘ptr’

Hello Prof Sastre,

Yes, you are correct that the ContextHandle should be a pointer, not an integer.

Here is a method from my Declares book to create a memoryblock from an integer memory address.

From Xojo’s documentation: memoryblock, the pointer can be retrieved from a MemoryBlock in two ways:

You could change the declare to take the ptr instead of the integer.
or cast the ptr to integer.

Ptr and Integer for the handle should have the same value.

1 Like

Thank you Anthony, Torsten, Eugene and Christian for your comments.
I think I will give another go and tell you about the result.

I’ve tried

Var j As Ptr = OpenGl_Surface.ContextHandle
Var k As Ptr = DesktopControl(OpenGl_Surface).Handle

before the code

#If TargetWindows Then

and I get two different pointers. Is it normal?
Anyway, when I try to convert these pointers to an integer (Var kk As Integer = k.Integer(0)) the application crashes.

According to the documentation:


A Ptr is 4 bytes for 32-bit apps and 8 bytes for 64-bit apps.

You can compare one Ptr to another Ptr or to Nil.

You can convert the value referenced to by the pointer to a specific data type using the available methods.

You can assign a Ptr to a MemoryBlock.

You can convert the value referenced to by the pointer to a specific datatype using the Pointer Properties: Boolean, Byte, CFStringRef, Class, Color, CString, Currency, Double, Int16, Int32, Int64, Int8, Integer, Object, Ptr, Short, Single, String, UInt16, UInt32, UInt64, UInt8, Variant, WindowPtr, WString

That’s because they should be casted to an integer instead.

Dim I as integer = integer( desktopControl.handle )

What your code is doing is getting an int64 at the ptr location, not an integer of the pointer’s location.

Thanks Sam. You are right. In fact I was thinking about it but I didn’t know how to do it,

Now I’ve done:

and I obtain two Integers (65536 and 3807270), but I don’t know which one to use.
Of course I can try both and see what happens, but I’d like to understand it.
Can you help me?

I tried, and the second one

Dim kk As Integer = Integer(DesktopControl(OpenGL_Surface).Handle)

works!! But why??

I think that the clue of all this is here:


Although there is an error of variable type (ContextHandle is a Ptr, not an Integer) it seems that the pointer is to an “underlying OpenGL context”. I have no idea what it means, but it seems that the “underlying context” is not the “handle”.
That’s what I think, but obviously I am not sure at all.

The documentation is short on this and should be amended accordingly.

A context in Opengl is a pointer. Opengl is given numbers and the context provides the meaning behind the numbers, which is referenced as a pointer.

An example would be: here are the numbers 4,6, and 9. Opengl context places a meaning to these numbers. Without context, these numbers could mean colour, position, vector, light, etc. All opengl commands pass through the Opengl context.

The pointer to Opengl needs to be known by the window that draws Opengl.

If you are using glfw then you can use the command getcurrentcontext (I think that’s the name, I am not at my development computer)

One of them is the underlying OS control for the OpenGL “View” and one is the OpenGL contents.
At least this is how it works on the Mac. So if you need to customize the control, you use the control.handle property, but if you want to alter the OpenGL content, you use t’other one.

The TextArea on the macOS is also two parts, one if for the scroll view of the text content and t’other is for the text content.