Setting properties on a dereferenced NSRangePointer has no effect
Hi all, NSFormatter defines a method with the following selector: isPartialStringValid:proposedSelectedRange:originalString:originalSelectedRange:errorDescription: This is its signature: - (BOOL)isPartialStringValid:(NSString **)partialStringPtr proposedSelectedRange:(NSRangePointer)proposedSelRangePtr originalString:(NSString *)origString originalSelectedRange:(NSRange)origSelRange errorDescription:(NSString **)error The relevant bit here is the proposedSelRangePtr argument, which is a NSRangePointer. When subclassing NSFormatter in ruby, I define the method as: def isPartialStringValid(partialStringPtr, proposedSelectedRange:proposedSelRangePtr, originalString:origString, originalSelectedRange:origSelRange, errorDescription:error) When implementing the Cocoa Programming exercises in MacRuby, I ran across the following situation: At some point in that method definition, in the original code, Aaron sets the range properties directly: proposedSelRangePtr->location = [*partialStringPtr length]; proposedSelRangePtr->length = [match length] - proposedSelRangePtr->location; Initially, I did similar in MacRuby proposedSelRangePtr[0].location = partialStringPtr[0].length proposedSelRangePtr[0].length = match.length - proposedSelRangePtr[0].location This has no effect. It does not raise, but the values go unchanged. I can NSLog the range values before and after and they're the same. My final solution was to assign a new range to that location: proposedSelRangePtr[0] = NSRange.new(partialStringPtr[0].length, match.length - partialStringPtr[0].length) But I wonder why setting the range properties had no effect. MacRuby bug?
Hi Caio, Sorry for the late response. This is a limitation of our implementation of pointers. Sadly, I don't recall the problem anymore (as I wrote that stuff 2 years ago), but I think it's related to the way we cache the Pointer internal data. For 1.0, we should either document this or try to make proposedSelRangePtr[0].location=42 work, as I suspect people will hit the same problem. Could you file a ticket? We will continue the investigation there. Thanks! Laurent On Jan 21, 2011, at 1:37 PM, Caio Chassot wrote:
Hi all,
NSFormatter defines a method with the following selector:
isPartialStringValid:proposedSelectedRange:originalString:originalSelectedRange:errorDescription:
This is its signature:
- (BOOL)isPartialStringValid:(NSString **)partialStringPtr proposedSelectedRange:(NSRangePointer)proposedSelRangePtr originalString:(NSString *)origString originalSelectedRange:(NSRange)origSelRange errorDescription:(NSString **)error
The relevant bit here is the proposedSelRangePtr argument, which is a NSRangePointer.
When subclassing NSFormatter in ruby, I define the method as:
def isPartialStringValid(partialStringPtr, proposedSelectedRange:proposedSelRangePtr, originalString:origString, originalSelectedRange:origSelRange, errorDescription:error)
When implementing the Cocoa Programming exercises in MacRuby, I ran across the following situation:
At some point in that method definition, in the original code, Aaron sets the range properties directly:
proposedSelRangePtr->location = [*partialStringPtr length]; proposedSelRangePtr->length = [match length] - proposedSelRangePtr->location;
Initially, I did similar in MacRuby
proposedSelRangePtr[0].location = partialStringPtr[0].length proposedSelRangePtr[0].length = match.length - proposedSelRangePtr[0].location
This has no effect. It does not raise, but the values go unchanged. I can NSLog the range values before and after and they're the same.
My final solution was to assign a new range to that location:
proposedSelRangePtr[0] = NSRange.new(partialStringPtr[0].length, match.length - partialStringPtr[0].length)
But I wonder why setting the range properties had no effect. MacRuby bug?
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On 2011-01-26, at 20:22 , Laurent Sansonetti wrote:
For 1.0, we should either document this or try to make proposedSelRangePtr[0].location=42 work, as I suspect people will hit the same problem. Could you file a ticket? We will continue the investigation there.
Ok, will get on to that ticket. If the assignment can't be made to work, I'd expect it at least to raise instead of failing silently.
participants (2)
-
Caio Chassot
-
Laurent Sansonetti