[Mono-osx] 3 cross-platform questions

[Joanna Carter]

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 
> WinForms?

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 
> .nib?

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 
interaction code.

> 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 
mixture.

> 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.

Joanna

--
Joanna Carter
Carter Consulting