Re: Why use custom component for class?
From: Raptor (bogus_at_none.com)
Date: 02/14/05
- Next message: Raptor: "Re: Why use custom component for class?"
- Previous message: Raptor: "Re: I'd RTFM if they actually GAVE me a FM!!"
- In reply to: Bruce Roberts: "Re: Why use custom component for class?"
- Next in thread: Bruce Roberts: "Re: Why use custom component for class?"
- Reply: Bruce Roberts: "Re: Why use custom component for class?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 14 Feb 2005 12:54:53 -0800
Bruce Roberts <ber@bounceitattcanada.xnet> wrote in message
news:uE4Qd.1870$dZ.133592@news20.bellglobal.com...
>
> "Raptor" <bogus@none.com> wrote in message
> news:cujm1f1oo4@news2.newsguy.com...
>
> > I didn't want to go to the trouble of making a full-blown visual
component
> > (which I gather would be done by deriving from TRichEdit), not did I
want
> to
> > have to create a TRichEdit dynamically and place it via code and set all
> the
> > stuff in code. I was looking for a middle ground, where I could place a
> > TRichEdit on a form but modify its behavior.
>
> In the IDE, Component | New Component.
>
> Ancestor Type : tRichEdit (or tCustomRichEdit)
> Class Name : tScriptEdit
> Palette Page : { your choice, just type to create new }
> Unit File name : { your choice }
> Search Path : { your choice }
>
> Once you've saved the new unit, Component | Install Component. I'd suggest
> that you use the New Package tab and create a package for your own
controls.
> Once you've added the control to the new package, build the package and
> install it. Its that simple to create a new visual component that you can
> drop onto a form at design time.
Sorry I wasn't clear--that process I understand well enough. Going through
it has regularly been a pain in the ass for me, though, because Delphi
thinks often the thing I'm making-and-modifying already exists but won't
let me remove it because it doesn't exist).
> IIRC the help has a chapter the works through an example of modifying an
> existing visual component. Check Creating Custom Components in the table
of
> contents.
Yes, that's probably the strongest and best-written part of the
documentation. In actual practice it has proved messy and erratic for me,
however, and thus the appeal of using a component as-is, but nevertheless
getting it to do other things.
> > Didn't know how, though. A couple of simple downloads from Torry's had
the
> > general form I was looking for: use a RichEdit as a property of the
class.
> > Cool.
>
> There are times when this approach makes sense but its actually more
> difficult to manage at design time than descending directly from the edit.
Someday when I have more time I'll try the regular component-creation (as
descendant) thing yet again and yelp for group help when Delphi does its
frustrating weirdness. I've done it, but modification-uninstall-reinstall
has been troublesome.
In the meantime this worked OK. I was was just wondering why the TCustomXXX
form would be used, other than property exposure, of which I was aware.
Raptor
- Next message: Raptor: "Re: Why use custom component for class?"
- Previous message: Raptor: "Re: I'd RTFM if they actually GAVE me a FM!!"
- In reply to: Bruce Roberts: "Re: Why use custom component for class?"
- Next in thread: Bruce Roberts: "Re: Why use custom component for class?"
- Reply: Bruce Roberts: "Re: Why use custom component for class?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
