Quote:
|
To be honest, its not really any different from if the throw error switch is false. This is because the error is "handled".
|
Now I do see it too - you're right. Nice idea postboning the error-exit. That seems now allright to me. Nonetheless, somehow it's not the right way to go. It still leaves to much room to guessing whether memory is freed from the particular object or not...
Im still trying to read from the pointers. At least I got it working the way, that the function works when called from the macro creating the object. My mistake was, not destroying OTemp. That I do now with one more line:
Code:
Function ObjectFromPointer(lPtr As Long) As Object
Dim oTemp As Object
Mem_Copy oTemp, lPtr, 4
Set ObjectFromPointer = oTemp
Mem_Copy oTemp, 0&, 4
End Function
That way it can be used in the first macro, proofing that if the pointer contains an object, it can be copied to an object (remember this words):
Code:
Sub ExampleForObject2()
Dim objRange As Object
Set objRange = Sheets(1).Range("A1")
lng_ObjPtr = ObjPtr(objRange)
If ObjectFromPointer(lng_ObjPtr) Is Nothing Then
MsgBox "Object is Nothing"
Else
MsgBox "Object exists"
End If
'Set objRange = Nothing
End Sub
That runs without any error. Now let's go to the check afterwards:
Code:
Sub ObjectIsGone2()
If ObjectFromPointer(lng_ObjPtr) Is Nothing Then
MsgBox "Object is Nothing"
Else
MsgBox "Object exists"
End If
End Sub
Now again that will make excel crash!!
Crashing at the point
Mem_Copy oTemp, lPtr, 4 in the function. Even with changing oTemp declared as Variant, it can't be done. So what else can be behind the pointer???
There's a chance that the address get's occupied of something else, but what can that be, you can't address to a variant?