[Mono-winforms-list] Caret

[Rafael Teixeira]

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 <d4ljoyn at gmail.com> 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 <monoman at gmail.com> 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 <d4ljoyn at gmail.com > 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  -
> > > Mono-winforms-list at lists.ximian.com
> > >
> 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