Ok -- so the logic here is that when a method is expecting a Ptr,
and you pass it a nil memoryblock, it is the operator_convert that
is raising the exception? It almost seems like operator_convert
should be smarter when dealing with nil objects?
Or, perhaps a IllegalCastException would make more sense?
It would not, because you're not casting in this situation; you are
converting. The conversion is accomplished by invoking a method;
when the object reference is nil, a NilObjectException is the
correct exception type.
But I cannot reproduce your situation...
You can see this technique useed in the rgbl code:
Private Delegate Function wglChoosePixelFormatARBDelegate(hdc as
UInt32, piAttribIList as Ptr, piAttribFList as Ptr, nMaxFormats as
UInt32, byref piFormats as UInt32, byref nNumFormats as UInt32) As
Integer
[...]
//get pointer to pbuffer create function
declare function wglGetProcAddress lib GL_LIB (lpszProc as
CString) as Ptr
dim fnPtr as Ptr = wglGetProcAddress("wglChoosePixelFormatARB")
//choose pixel format
dim pixelFormat as uint32
if fnPtr <> nil then
dim null as ptr
dim count as uint32 = 0
dim fn as new wglChoosePixelFormatARBDelegate(fnPtr)
call fn.Invoke(current_hdc, attribs, null, 1, pixelFormat, count)
if count = 0 then
raise new RBGLException("could not find a suitable pixel
format for the pbuffer")
end
else
raise new RBGLException("wglChoosePixelFormatARB is not
supported on this system")
end
As you see, they are intentionally passing "null" (a nil Ptr) instead
of nil to the delegate function that is expecting a Ptr. If you try
to pass nil, then it fails.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|