Tricky REALBasic bug with assignment in DIM statement

[Alex Lindsay]

Below is a description of a tricky problem I found with REALBasic 
5.5.3.  Please note that this is NOT a Valentina bug but a problem with 
REALBasic.  Looks like REALBasic is planning on fixing this in version 
6.0.  Please sign onto the bug report to make sure it isn't dropped:
<http://www.realsoftware.com/feedback/viewreport.php?reportid=lgynrrfl>

First e-mail from me:

I tracked down an unusual problem last week where the reference counting
behaved differently depending upon whether or not it was assigned as
part of the Dim assignment.  VCursor is a Valentina cursor and
GetCursor() is a method to get a reference to a new cursor.

 From memory:

First snippet:
Sub MySub()
    Dim cursor as VCursor = GetCursor()
    cursor = nil
End Sub

Second snippet:
Sub MySub()
    Dim cursor as Vcursor
    cursor = GetCursor()
    cursor = nil
End Sub

In the first snippet, something is keeping a reference to the cursor
until MySub() ends.  In the second snippet the cursor is released as
soon as the the cursor = nil line is executed.  I know that this is the
case since the cursor locks records and the locks are not released
indicating a reference to the cursor exists somewhere.  It is like a
hidden temporary variable exists and is holding a reference to the
cursor.

This seems to be a bug and was a very tough one to track down!

Any one else see anything like this?  Or should I assume insanity on my
part?

Alex


Response from REALBasic:

 > In the first snippet, something is keeping a reference to the cursor
 > until MySub() ends.  In the second snippet the cursor is released as
 > soon as the the cursor = nil line is executed.  I know that this is 
the
 > case since the cursor locks records and the locks are not released
 > indicating a reference to the cursor exists somewhere.  It is like a
 > hidden temporary variable exists and is holding a reference to the
 > cursor.

It's exactly like that, because that's exactly what's going on.

 > This seems to be a bug and was a very tough one to track down!

I'm not entirely convinced it's a bug, given that the reference is 
released
when the method ends. But if you want to see it changed, I recommend 
filing
a bug report/feature request in the feedback database.

Mars Saxman
REAL Software



Final e-mail from me:


Mars, thanks for you speedy answer!

 From my point of view, it's a bug since I can not release the reference
even though the only target of the assignment (cursor) has been set to
nil.  To make it worse, it is not obvious that there is another
reference to the cursor.  In my particular case, I was unable to create
a new cursor on the locked records until the previous cursor truly was
destroyed and unlocked the records.

Of course the work-around is trivial, but the tracking this down was not
trivial since the records that were locked were data dependent and so no
two runs of the code would necessarily lock the same records, resulting
in intermittent failure and much inappropriate cursing on my part! ;)

I have now filed my first a bug report:  lgynrrfl