Re: D/Objective-C 64bit
I would expect to be using an ObjcObject instead of an
NSObject here,
but this does not compile. The signature of the target action
seems to
be irrelevant, it may have no or more parameters. I guess this
is just
ok and the expected behavior.
Hmm, that sounds strange. What exact errors do you get?
source/appdelegate.d(47): Error: function
appkit.tableview.NSTableView.setDoubleAction (objc_selector*
aSelector) is not callable using argument types (extern
(Objective-C) void __selector(ObjcObject))
Line 46 & 47:
auto doubleAction = &AppDelegate.doubleClickAction ;
demoTableView.setDoubleAction(doubleAction) ;
Line 80:
void doubleClickAction(ObjcObject sender) {
actually, when line 46 & 47 are like above, it doesn't matter if
I change ObjcObject to NSObject, but I guess my problem here is
how Map the function in tableview.d:
void setDoubleAction(objc.runtime.SEL aSelector)
[setDoubleAction:] ;
[1]
https://github.com/jacob-carlborg/dmd/blob/d-objc/test/runnable/objc/objc_selector.d
I know Dip 43 almost by heart now, but I haven't yet discovered
the tests you wrote. Nice, this will be extremely helpful.
Best!
Re: D/Objective-C 64bit
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:
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.
Thanks again.
Re: D/Objective-C 64bit
what is funky in this context (see above): even when using
ObjcObject in both the mapping and the action method, the test
if (sender is demoTableView) {
//
}
does not fail in the action, only a cast to a NSTableView object
fails. Of course, in this setting it's not really a problem, I
can work directly on the demoTableView member and can forget
about the sender, but this is against how I would do it in
Objective-C where I can always cast an id reference to the
expected type.
Re: dfl2 is comming
I found build tool named dco. Could you explain were it can be helpful?
Re: dfl2 is comming
will it work for 64bit? On Saturday, 18 October 2014 at 14:39:05 UTC, FrankLike wrote: There were 15 forks of DFL on github (some of them working fine with 2.066), you made a 16nth, with another name. ;) What's the point? Btw, your version (just like most others) contains bugs causing the app to crash on exit. The issue is with destructors (in Timer and Tooltip, for example) that try to access some global/static variables, and when the app closes GC does its final cycle and calls destructors, and at this time many of those objects are already dead. It went silent in older versions of D, but since 2.065 was pretty visible. My fix is here: https://github.com/thedeemon/dfl/commit/290d6456f6d13447311845929fd929acb6938a5d (sadly, combined with additional changes I made when trying to find the bugs) Sorry,D2.066 is no 'dm' folder,its libs all moved in dmd2\windows\lib,and most new users like to use the 'dub' or Visual studio .net . A few minutes ago,I test to compile the dfl which was cloned from 'https://github.com/Rayerd/dfl',but found some errors,not get the *.objs,and must modify the bat file. Now,it's a important thing, let more new users to like the dfl in their ways:'dub' or Visual studio.net. I think its very easy to use it for you. Thank you very much.
Re: D/Objective-C 64bit
On 2014-11-04 09:07:08 +, "Christian Schneider"
said:
Ok, some more info:
I changed the mapping in tableview.d to:
void setDoubleAction(void __selector(ObjcObject))
[setDoubleAction:] ;
That's indeed the best way to do it.
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:
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.
There is no test for interface-to-class casts in the D/Objective-C test
suite, which means you're likely the first person to try that. It's
probably just an oversight in the compiler code.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: D/Objective-C 64bit
On 2014-11-01 10:47:54 +, Jacob Carlborg said: On 2014-11-01 01:58, Michel Fortin wrote: That said, there are other parts of D/Objective-C that could pose difficulties to existing languages tools, some syntactic (__selector, or "this.class" to get the metaclass) "this.class" could perhaps be called "this.classof", at least that's valid syntax. Although I don't know what to do about __selector. Once this is merged in DMD, __selector could be documented to be syntactically identical to a delegate (although semantically different) and it could be made syntactically valid for regular D code compiled with no Objective-C support (although it'd remain semantically invalid). That'd allow you to hide it in version blocks and static ifs. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: D/Objective-C 64bit
On 2014-11-04 13:29, Christian Schneider wrote:
what is funky in this context (see above): even when using
ObjcObject in both the mapping and the action method, the test
if (sender is demoTableView) {
//
}
does not fail in the action
That will just compare the address of the objects.
, only a cast to a NSTableView object
fails. Of course, in this setting it's not really a problem, I
can work directly on the demoTableView member and can forget
about the sender, but this is against how I would do it in
Objective-C where I can always cast an id reference to the
expected type.
See the reply by Michel. It's probably a bug/oversight in the compiler.
As a workaround you can, as you said, use NSObject instead of ObjcObject
in both places.
What happens if you declare "doubleClickAction" like this:
void doubleClickAction(NSTableView sender) { ... }
That will probably require a cast when passing the selector to
"setDoubleAction".
--
/Jacob Carlborg
Re: D/Objective-C 64bit
On 2014-11-04 23:46, Michel Fortin wrote: Once this is merged in DMD, __selector could be documented to be syntactically identical to a delegate (although semantically different) and it could be made syntactically valid for regular D code compiled with no Objective-C support (although it'd remain semantically invalid). That'd allow you to hide it in version blocks and static ifs. Yeah, that would be preferable. I would like to avoid the mess that the migration from D1 to D2 caused. Where if one wanted to support both some D2 code needed to be in a string mixin guarded with a version block. -- /Jacob Carlborg
Re: D/Objective-C 64bit
There is no test for interface-to-class casts in the D/Objective-C test suite, which means you're likely the first person to try that. It's probably just an oversight in the compiler code. Hey Michel, thanks very much for this explanation! That's actually good news. It certainly will be good to have this fixed, as the target action mechanism gets a lot of it's spice that the "sender" only needs to comply to a protocol and can be whatever control or even nil. Best! Christian
