I have been working on the WineLib implementation of Windows Forms. At this point you can do some simple things (show a message box, draw a form, get form/control events and messages...) but there is still a lot of work to do.
I have put efforts into a Windows Form implementation not because I believe it is the best or most elegant toolkit but because I believe it is needed for compatibility with the Microsoft .NET Framework. I'm not sure I would recommend it for new GUI applications targeted for Mono. In that case I would recommend using either GTK# or Qt# but for developers coming over from Windows I believe Windows Forms will be missed if there is not an implementation. > If P/Invoke of the Win32 functions is not supported, then I think that > Mono's SWF implementation will be, for all intents and purposes, > useless. I have not yet seen a single, less than trivial, .Net Windows > application that did not use several P/Invoke's to the Win32 libraries. > You should have full access to the Win32 API using P/Invoke if running under WineLib. This is actually how the WineLib implementation is proceeding at this point (take a look at Win32.cs in CVS). I'm not sure I would count on this for portability though but yes, you should be able to call native Win32 functions. This is also one of the reasons (among others) I believe WineLib is the best way of getting Windows Forms to run under Mono. Most of the Win32 code I have worked with always requires access to Win32 functions no matter how well wrapped the API library you are using appears to be. > I'd understand not supporting P/Invoke into 3rd party libraries, since > you'd need to translate those. But I'd think that at least the Win32 > DLL's should be supported since most applications already use them. > When running under WineLib on an x86 processor you should even be able to use 3rd party dll's and controls (without recompiling) as long as you install them into the Wine environment. Of course this will not work under non-x86 platforms but if you have the source code you may even be able to build the 3rd party dll's and controls (under WineLib) and use them in these environments. Finally, as far as the native look and feel goes I believe we should be able to handle this without the need to patch Wine. Since we have full access to the WndProc and messages we should be able to override these messages to draw the controls ourselves using C# code. I have developed some custom controls under Windows in the past and I believe the same method would work for the Windows Forms implementation under Mono. I still need to investigate this further though as I have currently concentrated my efforts into the implementation of Windows Forms classes. John _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
