> Could it be this issue [1]? Can you please see if you can reproduce it using just plain C.
>
> https://issues.dlang.org/show_bug.cgi?id=5570

Uh, oh, that bug looks like a major annoyance in 64bit! I made a few checks, all appkit methods returning a NSRect currently produce a runtime segfault. But this does not apply to NSSize, nor NSPoint, functions returning either NSSize or NSPoint work.

What I have found out so far: all the extern C functions in geometry.d work just fine.. e.g. NSRectFromString does what it's supposed to do.

> Can't you just call "super" in the beginning of the method and then call return "this" at the end. Something like this:
>
> override KeyboardView initWithFrame(NSRect frame) [initWithFrame:] {
>     super.initWithFrame(frame);
>     // my stuff
>     return this;
> }

Ups, sorry, my bad! I was trying this and had an exception, but not from the constructor! Of course this works just fine! Excuse me for the noise, I should remove my post (if I only could ;).

On 2014-11-18 21:46, Christian Schneider wrote:

> Yes, of course, and this is really not an issue! And this convenience
> function can be rewritten in a few lines of code, if really necessary.

Good, I just want to make sure you can continue. Than we can figure out the minor issues later. Anyway, I added it to my todo list.

-- 
/Jacob Carlborg

On 2014-11-18 21:54, Christian Schneider wrote:

> Uh, oh, that bug looks like a major annoyance in 64bit! I made a few
> checks, all appkit methods returning a NSRect currently produce a
> runtime segfault. But this does not apply to NSSize, nor NSPoint,
> functions returning either NSSize or NSPoint work.
>
> What I have found out so far: all the extern C functions in geometry.d
> work just fine.. e.g. NSRectFromString does what it's supposed to do.

If this is works for extern(C) functions then it might be a problem with the extern(Objective-C) functions. Perhaps it's not using the correct objc_msgSend functions under the hood.

-- 
/Jacob Carlborg

On 2014-11-18 21:54, Christian Schneider wrote:

> Uh, oh, that bug looks like a major annoyance in 64bit! I made a few
> checks, all appkit methods returning a NSRect currently produce a
> runtime segfault. But this does not apply to NSSize, nor NSPoint,
> functions returning either NSSize or NSPoint work.
>
> What I have found out so far: all the extern C functions in geometry.d
> work just fine.. e.g. NSRectFromString does what it's supposed to do.

I forgot to ask, do you have a small test case showing this problem? Without windows or any other fancy stuff.

-- 
/Jacob Carlborg

> I forgot to ask, do you have a small test case showing this problem? Without windows or any other fancy stuff.

Just setup a small temporary repository for this:

https://github.com/DiveFramework/FixingNSRect

Without an OSX application with windows et al, it won't show you the "send bug report" dialog, this is where I found the other information. If you want to, you can open the most simple example in DiveFramework, e.g. OpenGLView and ask the main window for bounds or the frame.

After a good night sleep, I came up with this: no way this can be a deal breaker, if push comes to shove I'll just create a small Framework containing wrapper functions with NSRect pointers for all the methods returning NSRect. Luckily, there are not too many of these. But still, they are extremely vital once you start messing with complicated gui stuff e.g. like darn NSScrollViews or even worse NSSplitViews.

Thanks for having a look into this ;)

On 2014-11-18 09:07:10 +0000, Christian Schneider said:

> This is what I came up with so far:
> 
> override KeyboardView initWithFrame(NSRect frame) [initWithFrame:] {
>      //my stuff
>      return cast(KeyboardView) super.initWithFrame(frame) ;
> }

Why not use a constructor and let the compiler manage the boilerplate?

	this(NSRect frame) [initWithFrame:] {
		//my stuff
		super(frame);
	}

This should emit the same code as the function above (but I haven't tested). And then you can write:

	auto view = new KeyboardView(someFrame);

and have proper type safety.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

> Why not use a constructor and let the compiler manage the boilerplate?
>
> 	this(NSRect frame) [initWithFrame:] {
> 		//my stuff
> 		super(frame);
> 	}
>
> This should emit the same code as the function above (but I haven't tested). And then you can write:
>
> 	auto view = new KeyboardView(someFrame);
>
> and have proper type safety.

Thanks Michel, my question was based on a completely wrong assumption (really sorry, my bad), the code of course works, which is again really cool about the D/Objective-C bridging.

When I prepare the framework glue headers I usually add both variations init.. and this(), so the coder who uses it can take the shortcut if he prefers. I try to stay as close as possible to the naming conventions of the Cocoa framework, it facilitates somewhat the documentation lookup in Xcode. Named parameters is probably the feature I like most about Objective-C, it makes the code so much more readable and auto-documents, if one is careful.

On 2014-11-04 10:07, Christian Schneider wrote:
> Ok, some more info:
>
> I changed the mapping in tableview.d to:
>
> void setDoubleAction(void __selector(ObjcObject))
> [setDoubleAction:] ;
>
> This should be the way to do it. Now in the implementation of the
> action:
>
>       void doubleClickAction(ObjcObject sender) {
>           NSLog("double click action") ;
>           NSLog("the sender: %@", sender) ;
>       }
>
> This works fine and prints the log:  2014-11-04 10:01:57.967
> tableview[9988:507] the sender: <NSTableView: 0x7f8309f156b0>
>
> But now I would like to do something with this sender, like I do
> often in an Objective-C project:
>
> NSTableView tableView = cast(NSTableView)sender ;
>
> I get a  EXC_BAD_ACCESS (SIGSEGV) on this line. Only when I
> replace both ObjcObject with NSObject (in tableview.d, the
> mapping, and the target action) this cast works. I might be
> missing something obvious here.

This should be fixed now in my forks [1] [2]. Note, I've also replaced the selector syntax, [foo], with a compiler recognized UDA, @selector("foo").

[1] https://github.com/jacob-carlborg/dmd/tree/d-objc
[2] https://github.com/jacob-carlborg/druntime/tree/d-objc

-- 
/Jacob Carlborg

> This should be fixed now in my forks [1] [2]. Note, I've also replaced the selector syntax, [foo], with a compiler recognized UDA, @selector("foo").
>
> [1] https://github.com/jacob-carlborg/dmd/tree/d-objc
> [2] https://github.com/jacob-carlborg/druntime/tree/d-objc

OMG, what did you do? all my beautiful appkit and foundation header files are destroyed! do you plan any other such attacks?

lol, i must admit, i was a bit shocked about this sudden surprise. what is the main motivation? i thought the old style looked good because it made visually clear that it was glue into objective-c, as it looked very familiar. with a little scripting / string processing i can adapt to the new style, i guess.