CFRange (Boxed) elements not accessible
Hello Laurent and team, The following code: string_range = CTLineGetStringRange(line) returns a CFRange, which is a C-structure with two elements: location and length. Attempting to access: string_range.location results in the error message: undefined method `location' for #<Boxed:0x200699fe0> (NoMethodError) (I think a similar error related to CLLocation has been discussed here before.) Is there a way to get around this problem? ----------------- Paul Howson Warwick Qld Australia
Hi Paul, I believe that here the function is typed to return an anonymous struct (likely a bug in the bridgesupport file), so MacRuby won't be able to associate it as an NSRange. You may be able to access location using string_range[0] and length using string_range[1]. Laurent On May 30, 2010, at 6:19 PM, Paul Howson wrote:
Hello Laurent and team,
The following code:
string_range = CTLineGetStringRange(line)
returns a CFRange, which is a C-structure with two elements: location and length.
Attempting to access:
string_range.location
results in the error message:
undefined method `location' for #<Boxed:0x200699fe0> (NoMethodError)
(I think a similar error related to CLLocation has been discussed here before.)
Is there a way to get around this problem?
----------------- Paul Howson Warwick Qld Australia _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On 31/05/2010, at 11:47 AM, Laurent Sansonetti wrote:
Hi Paul,
I believe that here the function is typed to return an anonymous struct (likely a bug in the bridgesupport file), so MacRuby won't be able to associate it as an NSRange. You may be able to access location using string_range[0] and length using string_range[1].
Laurent
Thanks Laurent. That appears not to work: undefined method `[]' for #<Boxed:0x2006947a0> (NoMethodError) Is the bridgesupport file produced elsewhere within Apple? (i.e. out of your control) Any other suggestions for getting around this bug? Thanks, Paul ----------------- Paul Howson Warwick Qld Australia
Hi Paul, On May 30, 2010, at 9:51 PM, Paul Howson wrote:
On 31/05/2010, at 11:47 AM, Laurent Sansonetti wrote:
Hi Paul,
I believe that here the function is typed to return an anonymous struct (likely a bug in the bridgesupport file), so MacRuby won't be able to associate it as an NSRange. You may be able to access location using string_range[0] and length using string_range[1].
Laurent
Thanks Laurent.
That appears not to work:
undefined method `[]' for #<Boxed:0x2006947a0> (NoMethodError)
I see :( Could you file a ticket about this? I believe we should expose the structure fields for these special Boxed objects.
Is the bridgesupport file produced elsewhere within Apple? (i.e. out of your control)
Yep, the file ships with the system, so we have full control. I just checked and the problem has been fixed in the new version of BridgeSupport that we are working on.
Any other suggestions for getting around this bug?
It is possible to fix the problem by manually editing the file. /System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreText.framework/Resources/BridgeSupport/CoreText.bridgesupport Then, locate the description of CTLineGetStringRange. It should be something like: <function name='CTLineGetStringRange'> <arg type='^{__CTLine=}'/> <retval type64='{?=qq}' type='{?=ii}'/> </function> And replace with: <function name='CTLineGetStringRange'> <arg type='^{__CTLine=}'/> <retval type64='{_CFRange=qq}' type='{_CFRange=ii}'/> </function> I understand that editing the file manually is probably not an option if you intend to ship the project later, but I think we can add a fix in trunk to expose the fields. We can maybe find another workaround if needed. Laurent
On 31/05/2010, at 6:12 PM, Laurent Sansonetti wrote:
Any other suggestions for getting around this bug?
It is possible to fix the problem by manually editing the file.
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreText.framework/Resources/BridgeSupport/CoreText.bridgesupport
Then, locate the description of CTLineGetStringRange. It should be something like:
<function name='CTLineGetStringRange'> <arg type='^{__CTLine=}'/> <retval type64='{?=qq}' type='{?=ii}'/> </function>
And replace with:
<function name='CTLineGetStringRange'> <arg type='^{__CTLine=}'/> <retval type64='{_CFRange=qq}' type='{_CFRange=ii}'/> </function>
I understand that editing the file manually is probably not an option if you intend to ship the project later, but I think we can add a fix in trunk to expose the fields. We can maybe find another workaround if needed.
Editing the file fixed the problem. By the time I'm ready to ship something, these changes will have percolated through the system I'm sure. Thanks, Paul.
On May 31, 2010, at 6:42 PM, Paul Howson wrote:
On 31/05/2010, at 6:12 PM, Laurent Sansonetti wrote:
Any other suggestions for getting around this bug?
It is possible to fix the problem by manually editing the file.
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreText.framework/Resources/BridgeSupport/CoreText.bridgesupport
Then, locate the description of CTLineGetStringRange. It should be something like:
<function name='CTLineGetStringRange'> <arg type='^{__CTLine=}'/> <retval type64='{?=qq}' type='{?=ii}'/> </function>
And replace with:
<function name='CTLineGetStringRange'> <arg type='^{__CTLine=}'/> <retval type64='{_CFRange=qq}' type='{_CFRange=ii}'/> </function>
I understand that editing the file manually is probably not an option if you intend to ship the project later, but I think we can add a fix in trunk to expose the fields. We can maybe find another workaround if needed.
Editing the file fixed the problem. By the time I'm ready to ship something, these changes will have percolated through the system I'm sure.
Good :) Otherwise, it might be possible to convert the object to a real CFRange by doing: NSRangeFromString(NSStringFromRange(obj)) (This is untested but I suspect it might work...) Laurent
participants (2)
-
Laurent Sansonetti
-
Paul Howson