[Mono-osx] Mono 2.6 and Windows.Forms on MacOSX
Lee V. Andrus
landrus2 at by-rite.net
Wed Dec 30 17:31:35 EST 2009
Andrew Brehm wrote:
> I am not so good with the advanced anything, but I can send some money if
> you tell me where.
I am not sure of the safest way to receive donations or what legal
ramifications there may be. Maybe someone who has dealt with these issues
is watching this forum and can advise me.
> I can also test.
> I am familiar enough with .NET but only on the write-applications level,
> not the extend-framework level.
At this point, I do not need extensive testing to find something I must fix
before proceeding. But sometimes I am not sure if the fault is in my DLL or
my test program. I am attaching a zip file with my latest DLLs and the
source to my test program. See what you can discern.
They are based on Mono 4.7 from the subversion repository. Define the
environment variable MONO_MWF_MAC_USE_COCOA_BACKEND when testing to use my
Cocoa driver instead of the Carbon driver. If you use MonoDevelop to build
and test, add references to my System.Windows.Forms.dll and
System.Drawing.dll instead of the standard versions in your project and use
the Run/General section of the Project Options to set the environment
variable. Oterwise, copy all the enclosed DLL and MDB files into the folder
with the executable.
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 or typing text, using shortcut keys, and
display of text in a TextBox are suspect.
> Delphi Prism comes with Monobjc. Perhaps Novell should include all three
> Cocoa bridges in Mono or set up a meeting with all the people involved so
> that everyone can come up with a decision.
> I don't think it's good that we have three (technically two) bridges to
> choose from.
Apparently, each bridge was built by a different person working
independently. Other calls for collaboration have gone unheeded. At last
count there were 5: Cocoa#, Monobjc, NObjective, ObjC#, and MObjc/MCocoa.
> Aren't the people of the Qt framework dealing with a similar problem at
> the moment? I think they are still porting Qt to Cocoa after having
> finished a Carbon port and then finding out that Carbon doesn't support 64
> bit code.
> Anyway, I'll happily test and support in any way I can!
I am not familiar with that framework, but another response to my post (
http://go-mono.com/forums/#nabble-p26966443 ) has pointed me to another
example of a framework handling Cocoa events.
View this message in context: http://old.nabble.com/Mono-2.6-and-Windows.Forms-on-MacOSX-tp24047606p26973035.html
Sent from the Mono - OSX mailing list archive at Nabble.com.
More information about the Mono-osx