Board index » delphi » Design-Time Manipulation Of Custom Component NOT In Component Palette

Design-Time Manipulation Of Custom Component NOT In Component Palette

Is it possible to create a custom component derived from an existing
component (TListBox) and then manipulate it during design time WITHOUT
creating a package and installing it in the component palette?

It's easy enough to instantiate the component at runtime and set the
properties before the form shows, but I'd rather manipulate it in the
IDE if possible.

 

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


Quote
Sonny Grunter wrote:
> Is it possible to create a custom component derived from an existing
> component (TListBox) and then manipulate it during design time WITHOUT
> creating a package and installing it in the component palette?

No. But you don't need to create a package - just add your component
to an existing package and rebuild.

--
jc

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


On Tue, 25 Mar 2003 13:20:00 +0000, Jeremy Collins

Quote
<jd.coll...@ntlworld.com> wrote:
>Sonny Grunter wrote:
>> Is it possible to create a custom component derived from an existing
>> component (TListBox) and then manipulate it during design time WITHOUT
>> creating a package and installing it in the component palette?

>No. But you don't need to create a package - just add your component
>to an existing package and rebuild.

An interesting question, and one I have been thinking of asking, but I
suspected JC's answer would be correct.

It really is a pain in the {*word*82}to create a 'really useful variation'
of say a TListbox, and have to install it in the components pallete
for everything to see.

Of course creating the thing on the fly is the 'real' way to do
things, and mostly I'll buy that, but not always.

Something is making me wonder - components are active at design time,
what happens if one writes just one component that sits in the
Pallette and it then creates whatever it is told to ...

IMO Delphi Apps should have their own 'Private Pallete' that one can
shove things into without disturbing one's overall setup.

Ha - something that VB does have ... and very useful it is

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


Quote
J French wrote:
> On Tue, 25 Mar 2003 13:20:00 +0000, Jeremy Collins
> <jd.coll...@ntlworld.com> wrote:

>>Sonny Grunter wrote:

>>>Is it possible to create a custom component derived from an existing
>>>component (TListBox) and then manipulate it during design time WITHOUT
>>>creating a package and installing it in the component palette?

>>No. But you don't need to create a package - just add your component
>>to an existing package and rebuild.

> An interesting question, and one I have been thinking of asking, but I
> suspected JC's answer would be correct.

> It really is a pain in the {*word*82}to create a 'really useful variation'
> of say a TListbox, and have to install it in the components pallete
> for everything to see.

> Of course creating the thing on the fly is the 'real' way to do
> things, and mostly I'll buy that, but not always.

> Something is making me wonder - components are active at design time,
> what happens if one writes just one component that sits in the
> Pallette and it then creates whatever it is told to ...

> IMO Delphi Apps should have their own 'Private Pallete' that one can
> shove things into without disturbing one's overall setup.

You *can* load packages on a per-project basis, (Project | Options), so
for larger projects you could probably create a dedicated set of
components (I haven't tried this, so don't shoot the messenger).

I just put all my components in one big personal package, and live with
the (minor) pain of finding the one I want on the component palette tab.
This way, when reinstalling Delphi I can be up & running as quickly as
possible.

--
jc

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


Just holding the post - saves paper

On Tue, 25 Mar 2003 14:45:37 +0000, Jeremy Collins

Quote
<jd.coll...@ntlworld.com> wrote:
>J French wrote:
>> On Tue, 25 Mar 2003 13:20:00 +0000, Jeremy Collins
>> <jd.coll...@ntlworld.com> wrote:

>>>Sonny Grunter wrote:

>>>>Is it possible to create a custom component derived from an existing
>>>>component (TListBox) and then manipulate it during design time WITHOUT
>>>>creating a package and installing it in the component palette?

>>>No. But you don't need to create a package - just add your component
>>>to an existing package and rebuild.

>> An interesting question, and one I have been thinking of asking, but I
>> suspected JC's answer would be correct.

>> It really is a pain in the {*word*82}to create a 'really useful variation'
>> of say a TListbox, and have to install it in the components pallete
>> for everything to see.

>> Of course creating the thing on the fly is the 'real' way to do
>> things, and mostly I'll buy that, but not always.

>> Something is making me wonder - components are active at design time,
>> what happens if one writes just one component that sits in the
>> Pallette and it then creates whatever it is told to ...

>> IMO Delphi Apps should have their own 'Private Pallete' that one can
>> shove things into without disturbing one's overall setup.

>You *can* load packages on a per-project basis, (Project | Options), so
>for larger projects you could probably create a dedicated set of
>components (I haven't tried this, so don't shoot the messenger).

>I just put all my components in one big personal package, and live with
>the (minor) pain of finding the one I want on the component palette tab.
>This way, when reinstalling Delphi I can be up & running as quickly as
>possible.

>--
>jc

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


Im Artikel <lYZfa.1282$wi1....@newsfep4-winn.server.ntli.net>, Jeremy Collins
<jd.coll...@ntlworld.com> schreibt:

Quote
>You *can* load packages on a per-project basis, (Project | Options), so
>for larger projects you could probably create a dedicated set of
>components (I haven't tried this, so don't shoot the messenger).

The implementation of this feature is by _excluding_ unwanted packages from a
project. Whenever a new package is registered, it becomes part of all projects,
from which it is not explicitly excluded. That exclude-list seems to be very
fragile, every other day I have to exclude again all the unwanted packages from
some project, which have been added by some mystery :-(

It really would be better to have a positive list, indicating only the required
packages. IMO the negative list, of packages to exclude, is the only way to
have multiple projects with different requirements in a project group.

DoDi

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


On 27 Mar 2003 14:33:50 GMT, vb...@aol.com (VBDis) wrote:

<snip>

Quote
>It really would be better to have a positive list, indicating only the required
>packages. IMO the negative list, of packages to exclude, is the only way to
>have multiple projects with different requirements in a project group.

>DoDi

IMO it would be very nice to have something in the .DPR that states
explicitly whether a component should turn up on the Palette and be a
'design thing'

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


Quote
"J French" <Bounce_It_je...@iss.u-net.com_.bin> wrote in message
> IMO it would be very nice to have something in the .DPR that states
> explicitly whether a component should turn up on the Palette and be a
> 'design thing'

There is RegisterNoIcon if one doesn't want a component to appear on the
palette.

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


On Mon, 31 Mar 2003 13:49:04 -0500, "Bruce Roberts"

Quote
<b...@bounceitattcanada.xnet> wrote:

>"J French" <Bounce_It_je...@iss.u-net.com_.bin> wrote in message

>> IMO it would be very nice to have something in the .DPR that states
>> explicitly whether a component should turn up on the Palette and be a
>> 'design thing'

>There is RegisterNoIcon if one doesn't want a component to appear on the
>palette.

It is not so much the component appearing on the palette, more that it
is annoying having one specific variant of a control exposed to the
rest of the world.

In VB you can add a 'control' so that it appears in the palette of
just that project, but otherwise use it as a 'normal control'

The same would be nice in Delphi

- Project granularity

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


"J French" <Bounce_It_je...@iss.u-net.com_.bin> skrev i melding
news:3e8952fc.1421467@news.u-net.com...

Quote
> On Mon, 31 Mar 2003 13:49:04 -0500, "Bruce Roberts"
> <b...@bounceitattcanada.xnet> wrote:

> >"J French" <Bounce_It_je...@iss.u-net.com_.bin> wrote in message

> >> IMO it would be very nice to have something in the .DPR that states
> >> explicitly whether a component should turn up on the Palette and be a
> >> 'design thing'

> >There is RegisterNoIcon if one doesn't want a component to appear on the
> >palette.

> It is not so much the component appearing on the palette, more that it
> is annoying having one specific variant of a control exposed to the
> rest of the world.

> In VB you can add a 'control' so that it appears in the palette of
> just that project, but otherwise use it as a 'normal control'

> The same would be nice in Delphi

Yes ! The impact of a component model like the one in Delphi is that a)
components live their own lives, and b) They may only exist in one version.
This means that you may accidentially modify a component and as a result,
break another project.
Something should be done about this !
--
Regards,

Bj?rge S?ther
bjorge@haha_itte.no
-------------------------------------
I'll not spend any money on American Software products
until armed forces are out if Iraq.

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


On Tue, 1 Apr 2003 11:54:46 +0200, "Bj?rge S?ther"

Quote
<bjorge@hahaha_itte.no> wrote:

<snip>

Quote
>Yes ! The impact of a component model like the one in Delphi is that a)
>components live their own lives, and b) They may only exist in one version.
>This means that you may accidentially modify a component and as a result,
>break another project.
>Something should be done about this !

Exactly, it is violating the principle of granularity

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


Quote
"Bj?rge S?ther" <bjorge@hahaha_itte.no> wrote in message

news:Mkdia.33$b71.436@news4.e.nsc.no...

Quote
> Yes ! The impact of a component model like the one in Delphi is that a)
> components live their own lives, and b) They may only exist in one
version.
> This means that you may accidentially modify a component and as a result,
> break another project.
> Something should be done about this !

OTH ISTM that allowing this can lead to confusion and ultimately poorer
production. Consider project A with component T and project B with a
different component named T, where T(1) and T(2) are on the design palette
when their respective project is loaded. What if one wants to reuse forms
(that include T) of both A and B in a new project C? Things get especially
confusing when T(1) and T(2) have a common immediate ancestor.

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


On Tue, 1 Apr 2003 13:50:06 -0500, "Bruce Roberts"

Quote
<b...@bounceitattcanada.xnet> wrote:

<snip>

Quote
>OTH ISTM that allowing this can lead to confusion and ultimately poorer
>production. Consider project A with component T and project B with a
>different component named T, where T(1) and T(2) are on the design palette
>when their respective project is loaded. What if one wants to reuse forms
>(that include T) of both A and B in a new project C? Things get especially
>confusing when T(1) and T(2) have a common immediate ancestor.

The situation would probably not arise

- a responsible programmer would be rather careful with their naming
convention

Most likely the programmer would have a 'library' enhanced control and
a local copy that they 'enhance'
- when the 'enhanced version' becomes production, it then replaces the
library version

Re:Design-Time Manipulation Of Custom Component NOT In Component Palette


Im Artikel <3e8952fc.1421...@news.u-net.com>,
Bounce_It_je...@iss.u-net.com_.bin (J French) schreibt:

Quote
>It is not so much the component appearing on the palette, more that it
>is annoying having one specific variant of a control exposed to the
>rest of the world.

The components in the palette are installed by the user, not by projects. When
a project requires a specific component, which is not part of the current
installation, then the user must install that component first.

For conflicting components it may be possible (untested!) to unload the
unwanted version(s) first, and then to add the desired package to the Delphi
installation. Unfortunately this procedure will result in incompatibility
messages with every other project, from which the new conflicting or unwanted
components have not yet been explicitly excluded.

DoDi

Go to page: [1] [2]

Other Threads