[Mono-osx] 3 cross-platform questions
cocoasharp at carterconsulting.org.uk
Wed Feb 25 04:55:04 EST 2009
Mac Programmer a écrit :
> (1) How does one create a true cross-platform custom control, meaning
> a control that functions both with WinForms and Cocoa?
As others have tried and discovered, you really can't.
> It appears as though in the .Net world most custom controls are
> UserControl descendants, which would apparently mean that the custom
> control is WinForms-only. Is there some other way?
Since UserControl relies entirely on the Win32 APIs to draw themselves,
and Cocoa has its own way of "talking to the metal", I would say that it
is highly unlikely.
If you then consider that the Cocoa UI is so much more sophisticated in
the facilities it provides, with things like Core Animation, you would
have to ask how would you include the functionality of one framework in
a control based on the other?
> The custom control I have in mind is in a nice fat 1.5MB assembly far
> to big to consider rewriting from scratch and it's a UserControl
> descendant. It works perfectly on Mac with Mono, although the
> resulting WinForms app it's used in is ugly. On most days of the week
> I'll go ugly rather than nothing, but is there any other way?
> For example, is there some way to drop a Cocoa-simulated UserControl
> below the custom control or would you have to simulate the entire
As I said, WinForms controls rely on a totally different API to Cocoa.
> (2) Is there a way to create a Cocoa app in Mono without using a
No, I think you need to understand the fundamental difference between
the Cocoa framework and WinForms:
From the start, Windows RAD design tools have always "encouraged" the
writing of all your code in the form class. The only real exception to
this was in the days of products like Borland C++ 4.5, where you used a
Dialog Editor to create the visual side of the UI, then you had to use
the numeric identifiers thus generated in a code unit to link up the
controls to something useful.
On the other hand, Cocoa comes from the Taligent project, where the MVC
(Model View Controller) and MVP (Model View Controller) design patterns
where first used in anger. Thus, the Cocoa model relies on a strong
separation between the UI side of things and business logic.
Also, Mac UIs were written to behave, not only on Intel platforms but,
also, on the older PowerPCs, thus there is no common code heritage
between them and the Windows APIs.
> I've been able to get it down basically to an empty .nib,
> without a main window or main menu, and then create the main window
> and its controls and event handlers in code, but it seems as though
> some kind of application controller class that's linked to a minimal
> .nib is required.
This is down to Cocoa's use of the MVC design pattern; you *must* use a
Controller because the UI components are never intended to have any user
> I've only done this with Prism and Cocoa# so far,
> but it should work with C# and the other Cocoa wrappers too.
But why would you want to?
> I find that creating the UI in code is more satisfying at this point
> than working with IB, which strikes me as sub-RAD. This also
> eliminates the need for [Export] and [Connect] attributes (meaning
> the application controller class is starting to resemble a WinForms
> Form class).
The Controller class will only resemble Winforms classes if you are used
to writing your event handlers on the form class. We have been using the
MVP pattern, in C#, for a number of years now and our forms are purely
visual design, there is absolutely no interaction code in the form
classes; that is taken care of by the Presenter and Interactor classes
that are part of our frameworks.
> (3) Is it possible to mix and match the GUI's? For example a
> System.Windows.Forms.Form with a Cocoa main menu. WinForms on the Mac
> is apparently implemented using the Carbon framework, which should
> co- exist okay with the Cocoa framework, but maybe WinForms itself
> won't co-exist with anything else.
In a word, no. Once again, I will repeat that WinForms and Cocoa
controls have absolutely no basis in code that would facilitate such a
> I appreciate the challenges of cross-platform GUI development, but
> the suggested solution (VM, VS, IB, etc.) sounds like a 12-step
> program designed to wean frustrated Mac developers from their Macs.
If you had been used to using MVP or MVC in C#, then you would not be
doing anything really different to using Cocoa.
Yes, it is a nuisance having to use VS in a VM for the code side of
things but, if you are intending to write multi-platform code, you will
need to realise that, for the proper "native" look and feel for Mac, you
will need to design the UI in IB; there really is no other way, since
the Cocoa controls rely on the Mac OS for full functionality.
Delphi Prism is, so far, the best solution for minimising the effort
involved in creating a true multi-platform application. I have
successfully created a Mac UI to interact with a C# code library,
written against the Microsoft FCL, and, once I had found out how to use
Delphi Prism to hook the two together, it was a relativel easy job.
More information about the Mono-osx