[Mono-osx] Mono 2.6 and Windows.Forms on MacOSX

[Lee V. Andrus]

Miguel de Icaza-2 wrote:
> 
> Hello,
> 
>> My project is implementing
>> System.Windows.Forms.XplatUICocoa, the Cocoa Driver for Mono's MWF.  This
>> is
>> the heart of the implementation of MWF.  It currently uses MObjc and
>> MCocoa to
>> facilitate access to the Cocoa framework.  All the other implementations
>> of
>> XplatUIDriver just use PInvokes to access the underlying window system
>> APIs,
>> but they all are based on simple C functions calls.  Marshaling Mono
>> subclasses of the Cocoa framework classes across the divide is a big
>> help.
> 
> Nice approach.    Is any of this code available for previewing anywhere?
> 
I do not have an online repository.  Here are the new source files and diffs
for files that had to be changed to integrate them.
http://old.nabble.com/file/p27156597/System.Drawing.diff.zip
System.Drawing.diff.zip  
http://old.nabble.com/file/p27156597/System.Windows.Forms.diff.zip
System.Windows.Forms.diff.zip 
It is a work in progress.  I would appreciate any suggestions.  I started by
copying files of the Carbon Driver and renaming every reference to "Carbon"
to say "Cocoa".  Then I started trying to convert it to use MCocoa/MObjC
instead of Carbon.  The changes to existing files consist of adding the
option to use the Cocoa Driver wherever Carbon is explicitly referenced.

The window handles, Hwnd.ClientWindow, and Hwnd.WholeWindow are (NSView*)'s,
pointers to Objective-C View objects (actually, instances of a subclass of
NSView marshaled by MObjC as a wrapper of my class MonoView).  NSEvent's are
taken from the Cocoa event queue and turned into Messages in the Mono
Message Queue, dispatched to the Cocoa event handling, and/or handled
specially.  A top-level "window" is the Content View of a native window. 
Handling of the title bar is left to the native system.  Paint and
window-close "events" are detected by override methods of MonoView.  I tried
to echo the active menu on the Mac menu bar, but there is some kind of
disconnect between it and the mainMenu property of NSApplication.

In System.Drawing, the windowing-system-specific code is not as thoroughly
encapsulated.  I hid much of the Cocoa-specific details behind an interface,
INativeContex, that I hope will (with some extensions) become a model for
encapsulating the windowing-system-specific code in System.Drawing.

I have been working with MObjC 0.7.11.0 and MCocoa 0.6.4.0.  I have just
downloaded and built MObjC 0.8.7.0 and MCocoa 0.7.0.1.  I had to cut out a
few new things because I am still running OS X 10.5.

My Cocoa driver will be used instead of the Carbon driver if the environment
variable MONO_MWF_MAC_USE_COCOA_BACKEND is defined at runtime.

Here are some of the bugs I already know about: Pop-up or pull-down menus do
not display properly until you drag the pointer along them.  The alpha
implementation of drag-and-drop is not finished.  Several "events" that the
Carbon driver handles are ignored.  You cannot cut and paste between Mono
and non-Mono applications because, (like the Carbon driver) the only data
type handled by the Clipboard is the Mono Object class.  I have tried to add
support for serializing of ISerializable objects to the Clipboard, but have
yet to prove it works.  Pasting, cutting or typing text and using shortcut
keys are suspect.  Building on ANY system requires the MObjC and MCocoa
DLLs.
-- 
View this message in context: http://old.nabble.com/Mono-2.6-and-Windows.Forms-on-MacOSX-tp24047606p27156597.html
Sent from the Mono - OSX mailing list archive at Nabble.com.