I think a MOMA report of your Windows Control, would help in convincing MWF devs on perhaps publicizing a platform-independent middle-level API, for such support.
They may have some things nearly done as MWF also runs on Windows, but it should probably need to be better abstracted to be published as a supported API. That may mean spinning such a thing like a Mono.Windows.UI.dll, what even the thought of it probably will scare them like hell, but would easy the life of the many winforms control coders/porters. It's kind of a culture-problem, in GTK-land less custom widgets are created as some of the most commonly needed extensions are folded back in the core widgets, because they are open-source. In Windows-land (a tradition started a decade ago with old VB, or even earlier with C++ MFC/ATL, and continuing with .NET), you wrap or inherit-and-extend a core control (when possible) or write a custom one from scratch, either way the provided base control and/or framework-API, is normally insufficient, and you end calling windows lower-level APIs (I've coded some dozens of custom controls myself, over the years, so I know the figure isn't pretty), or sending directly specific messages to the assumed windows core control that you think is wrapped in the base control you are extending. Both things are bound to break when run with Mono runtime/libs outside Windows (and even in Windows in some cases). It is a numbers-game: Are there more control coders out there wanting to push for (and help develop, ideally) an extensive published cross-platform API for Windows.UI abstraction? :) On 3/9/07, David Joyner <[EMAIL PROTECTED]> wrote: > Actually, that's exactly my situation: porting a Control derived class over > to MWF. Currently Win32 interop is used to accomplish this and I was > hoping for a platform independent way (without duplicating the code already > available). > > Dave > > > On 3/9/07, Rafael Teixeira <[EMAIL PROTECTED]> wrote: > > AFAIK, it depends on the control you are using. In Textbox, I think > > you have properties like SelectionStart and SelectionCount that > > control the selection and the caret (when SelectionCount == 0). > > > > Unless you are trying to write a custom control, you normally doesn't > > manipulate the caret directly. I would look in the TextBox control > > sources to have the gist of it, if I where you > > > > Good hunting, > > > > On 3/9/07, David Joyner <[EMAIL PROTECTED] > wrote: > > > I have a situation where I would like to control the caret. I noticed > that > > > in the XPlatxxx classes there are methods to handle this but all are > > > internal. > > > > > > Is there a recommended way for applications to show, hide, and position > the > > > caret? > > > > > > Thanks > > > > > > _______________________________________________ > > > Mono-winforms-list maillist - > > > [email protected] > > > > http://lists.ximian.com/mailman/listinfo/mono-winforms-list > > > > > > > > > > > > -- > > Rafael "Monoman" Teixeira > > --------------------------------------- > > "The reasonable man adapts himself to the world; the unreasonable one > > persists in trying to adapt the world to himself. Therefore all > > progress depends on the unreasonable man." George Bernard Shaw > > > > -- Rafael "Monoman" Teixeira --------------------------------------- "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." George Bernard Shaw _______________________________________________ Mono-winforms-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-winforms-list
