atom feed22 messages in net.java.dev.rococoa.usersRe: BOOL mapping issues
FromSent OnAttachments
Harald KuhrFeb 9, 2010 11:58 am 
Duncan McGregorFeb 9, 2010 12:04 pm 
Harald KuhrFeb 9, 2010 12:27 pm 
Harald KuhrFeb 9, 2010 12:37 pm.java
Duncan McGregorFeb 10, 2010 12:37 am 
Harald KuhrFeb 10, 2010 2:39 am.java
Harald KuhrFeb 17, 2010 7:25 am 
Duncan McGregorFeb 18, 2010 1:56 am 
Andrew ThompsonFeb 18, 2010 6:52 pm 
Harald KuhrFeb 19, 2010 6:49 am 
Harald KuhrFeb 19, 2010 7:23 am 
Harald KuhrFeb 19, 2010 10:37 am 
Harald KuhrFeb 19, 2010 12:13 pm 
Duncan McGregorFeb 19, 2010 2:04 pm 
Harald KuhrFeb 19, 2010 3:06 pm 
Andrew ThompsonFeb 20, 2010 8:02 am 
Harald KuhrFeb 20, 2010 1:12 pm 
Andrew ThompsonFeb 20, 2010 5:22 pm 
Duncan McGregorFeb 21, 2010 2:55 am 
Harald KuhrFeb 21, 2010 8:14 am 
Duncan McGregorFeb 21, 2010 8:40 am 
Duncan McGregorFeb 21, 2010 9:01 am 
Subject:Re: BOOL mapping issues
From:Harald Kuhr (hara@gmail.com)
Date:Feb 19, 2010 6:49:01 am
List:net.java.dev.rococoa.users

Thanks Duncan and Andy for looking into this!

On 18. feb. 2010, at 10.57, Duncan McGregor wrote:

I've played with it a bit, and am as flummoxed as you.

Ah.. Flummoxed.. A wonderful word.. I should try to remember and use it more
often.. ;-)

It seems that calling to setHidden(bool) with true of false will make the return
from isHidden() false.

Yes, that is what bothers me. It really makes no sense (to me, although I am
pretty sure once all the details are sorted out, it does make sense).

Rococoa does no marshalling in this area - it assumes that you had the signature
right, and lets JNA do the heavy lifting. In fact by the time it gets to a
method invocation, the arguments are all passed to the vargs objc_msgSend
functions, so it's all typeless by then. But in any case, JNA maps Java bool and
Java int to the same type in C.

The other thing that we pass to objc_msgSend is the selector. This is basically
a pointer to the interned method name as a string. That means (I think ;-) that
ObjC classes cannot have a setHidden:(bool) and setHidden:(int) as they will
both have the same selector.

I wasn't aware of this, but it seems you are absolutely right.

On 19. feb. 2010, at 03.53, Andrew Thompson wrote:

That's a real mystery. I looked at the GNUStep version of the code to see if
anything clever is going on, but it really doesn't seem to be - at least in
that implementation.

(FYI
http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Source/NSView.m?rev=29417&view=markup)

Thoughts... What does isHiddenOrHasHiddenAncestor return?

From looking at the GNUStep code it returns

isHidden || super_view.isHiddenOrHasHiddenAncestor

And the view in the test case has no super view (I don't know how ObjC handles
nil in this case, but it doesn't blow up), so the return values should be
identical.

I've added test cases to my test just in case, and superview returns null, while
isHiddenOrHasHiddenAncestor returns the same as isHidden in all cases.

setHidden does more than just set a boolean. Does this work on a view that
actually has been added into a window? Could it be some other bad state?

It could. But, as isHidden simply returns the value of _is_hidden, and from the
(GNUStep) source _is_hidden is always set to the value of the flag parameter in
the setHidden method (no other value writes).

(The exact same behaviour does occur if we're dealing with a real view in a real
view hierarchy on sceen though, I just left that out of the test case)

PS: Downloaded JNA 3.2.4 + latest SVN build (2009-05-20) and they all produced
same results for my test case.