<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Like I said, it's a START. If Carbon suffers planned obsolescence, another driver will be needed. This approach would leverage the work put into the Carbon driver to that end. Nobody has a completely quick & easy solution. Given the amount of lead time such a project requires, we better get started before Snow Leopard eats any chance of porting WinForm applications to the Mac.<div><br></div><div>The Cocoa driver should be coded to facilitate building for compatibility with either 32-bit or 64-bit systems. I'm not sure what that requires, but I'm confident C#'s lack of typedefs & macros will make it more difficult.<br><div><br></div><div><blockquote type="cite" class=""><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: Times; "><pre> >Creating XplatUICocoa & CocoaInternal, and converting 2,500 lines
>of Carbon code to Cocoa
>would seem to be less work than competing suggestions found in
>this mailing list.
That's probably a good place to start, but I'm not sure that would
solve all of WinForms' problems on Mac.
These are the kinds of things that would need to be solved if
WinForms is to be "fixed". But would "fixing" it break existing code.
It would seem that _every_ aspect of Mono's WinForms on Mac would
need to be carefully and tediously re-examined with the Mac in mind.
</pre><div><font class="Apple-style-span" face="-webkit-monospace" size="2"><span class="Apple-style-span" style="font-size: 10px; white-space: pre;"><br></span></font></div></span></blockquote><br></div></div></body></html>