[Openmcl-devel] Events, Windows, and OpenMCL

[Gary Byers]

On Mon, 11 Dec 2006, Brent Fulgham wrote:

>
> One last question for the night:
>
> Is there an easy way to test that the "windowRef" returned for a Cocoa window 
> is valid?  According to 
> "http://developer.apple.com/documentation/Cocoa/Conceptual/CarbonCocoaDoc/Articles/CarbonCocoaComm.html" 
> the windowref in a Cocoa application should be a valid Carbon reference. 
> However, this doesn't seem to work.
>
> If I do something like:
> ?(require 'cocoa)
>
> ... lots of stuff ...
>
> ? (defvar *A* (ccl::new-cocoa-window))
> *A*
> ? (defvar *B* (ccl::send *A* 'window-ref))
> *B*
> ? *A*
> #<NS-WINDOW <NSWindow: 0x3a6cb0> (#x3A6CB0)>
> ? *B*
> #<NS-OBJECT <NSCFType: 0x3ad950> (#x3AD950)>
> ? (defvar *C* (ccl::%get-ptr *B*))
> *C*
> ? *C*
> #<A Mac Pointer #xA07C35C0>
>
> I don't think the NS-OBJECT returned is what I want, because calling various 
> Carbon-based things don't seem to do anything.

The thing printed as an NS-OBJECT of mostly unknown class - the
thing returned by invoking *A*' window-ref method and which you
have assiged to *B* - is what Carbon would call a "windowRef".

? (#_IsValidWindowPtr *B*)
1               ; boolean true

A lot of things (some documented, some not) are "toll-free bridged"
between Cocoa and CoreFoundation.  Something that's just a random
CoreFoundation type is (apparently) also an instance of an internal
NSCFType Cocoa class.

The bridge tries very hard -not- to know about ObjC classes that
aren't declared in header files.  (This is intentional: it makes
it easier to run applications under different OS releases than
they were compiled/saved under); it can tell that the NSCFType
is an ObjC object, but since it doesn't really want to know about
the internal NSCFType class it just claims that the object is an
instance of the first superclass of NSCFType that it believes in.
In this case, it's just an NSObject.

The first word of any ObjC object is a pointer to its class.
If we look up the address of the (internal) NSCFType class,

? (ccl::lookup-objc-class "NSCFType")
#<A Mac Pointer #xA07C35C0>

we see that that class has the same address as *C* in your
example.  (Of course, the exact address of the class depends
on what version of the Cocoa libraries you have installed.)

>
> ? (#_HideWindow *C*)
> NIL
>

Try

(#_HideWindow *B*)

(#_MoveWindow *B* 100 200)


I honestly don't know if that'll work, but if it doesn't it
may be because of Cocoa/Carbon integration issues.  (You can
probably do more mixing of Cocoa and Carbon in the same
application than you could a few OS releases ago and I'd
expect simple things like the above to work, but there
may still be things that you can't quite do; it may (for
instance) sometimes be the case that Carbon event handlers
don't have the intended effect because Cocoa intercepts
things earlier in the event process.

I think (for instance) that Carbon and Cocoa handle view
hierarchies and redisplay in ways that are somewhat 
similar but which may be different in enough details
that it's hard to mix-and-match.  The "modern" Carbon
approach (HIView, etc.) is probably closer to Cocoa's
approach (NSView, etc.), but I think that it may be
non-trivial to try to mix HIViews and NSView in the
same program (and it may not even be possible. I don't
know.)


> Does not hide the window.
>
> ? (#_MoveWindow *C* 100 200)
>
> Does not move the window.
>
> Thanks,
>
> -Brent
>
>