Question about TCaption-Ttranslation strings used to ColorListBox and ColorBox

[jamie]

I am in the process of submitting a patch for the ColorListbox and colorBox to benefit from the recent change to the TColorDialog where as you can now set the Caption display..

 I have added a property "DialogTitle" for these controls so if not empty the color dialog for custom colors will use this value instead of the default string in the title bar.

 My Question:
   
  Property DialogTitle:TCaption……

 I expect this to be a translation type, is this the proper define to use in this case ?

[Bart]

I would guess TTranslateString (like the Title property of TColorDialog).
Don't forget to initialize it to rsSelectcolorTitle.

Bart

[jamie]

Ok, I can use the Ttranslation directly but as for the setting of the property I was going to leave that empty so that if not set it would use what the TColorDialog already has which is the rsSelectColorTitle and it does display 'Select Color' that way.

 Unless you see something I don't, I don't see a need to set the property for the colorbox and listbox controls?

 
  currently I test for any valid string there, if empty then I just allow the dialog use what it has.

Code: Pascal  [Select][+][-]

1.   with TColorDialog.Create(Self) do
2.   begin
3.     if FDialogTitle <> '' Then
4.      Title := fDialogTitle;          
5.  
6.  

This is what I am doing now..

[lucamar]

I would guess TTranslateString (like the Title property of TColorDialog).

TCaption is derived from TTranslateString so it's the correct type for a "caption" property.

[...]I was going to leave that empty so that if not set it would use what the TColorDialog already has which is the rsSelectColorTitle and it does display 'Select Color' that way. [...]

Yes, IMHO that is the correct way to deal with it. Just remember to set it to the empty string on creation ... as a precaution, if nothing else, even though as a managed type it should be auto-initialized.

[Bart]

That should work as well, since TColorDialog.Create initializes the Title anyway.

It would however be inconsistent with the behaviour in the IDE (OI) of the Title property of TColorDialog: this is always initialized to it's default value rsSelectcolorTitle.

Bart

[jamie]

The idea as for the colorbox, colorlistbox is to leave this field empty for optional use.  The colordialog's defines this field already so there is no need, I simply test for existence of a string there. etc..

I am trying to take the simplest approach with minimum overhead.

 I've just did a test run and it seems ok.

 I am doing this with my local copy atm so haven't yet applied this to the trunk..

[jamie]

I think I have a better solution and its in the naming of the property..

Instead of "DialogTitle" I can call it "AltDialogTitle"

[Bart]

I would think that DialogTitle or ColorDialogTitle would be better.

Another idea: ColorButton exposes the TColorDialog it uses.
Why not the same approch for these 2 controls?

Bart

[jamie]

Yes. I saw that. and yes it could also be done, too.

I can shift my strategy over to that instead.

So I guess maybe that would be a better idea, with that one could assign a descendant of a TcolorDialog

[jamie]

ok, its completed..

I now have ColorDialog properties in both the ColorBox and ColorListBox and it works like charm, that's with the IDE rebuilt and I tested all other features in the IDE that looks like is using those controls, just a guess with that.

I did this with my local copy, the COLORBOX.PAS file..

I need to do this now on the PC that has the trunk on it to create a patch unless someone would like to see this file here ?

[jamie]

I would think that DialogTitle or ColorDialogTitle would be better.

Another idea: ColorButton exposes the TColorDialog it uses.
Why not the same approch for these 2 controls?

Bart

The colorbutton does not actually expose the internal, what it does is allows you to use an external colordialog and does so by testing the field for Nil and if it is nil it will create an internal instance using the same property internally and free's it afterwards. If an external dialog is attached via that property then it simply uses that one instead and does not free it. So it has to be a valid external colordialog.
 
 But this allows you to do just about anything you want with the external dialog and the controls will now use it instead of creating a internal default one.

 I haven't got to the patch yet, but getting ready to create it..

[jamie]

Ok
0039189 at the bug site.

Patch is in. now it needs to be applied to trunk

[Bart]

You posted it in Lazarus-CCR section, I move it to Lazarus 

Bart

[wp]

A bit off-topic, but related: The external ColorDialog is still a TColorDialog. What if I want to show a completely new colordialog, such as the one with the color hexagon of Office97? Or one of the mbColorLib (https://wiki.lazarus.freepascal.org/mbColorLib)? This is not possible because the type of the external ColorDialog is TColorDialog. I think we should extend the color dialog architecture by a TBasicColorDialog (=class TCommonDialog) which is kind of abstract and provides only the basic properties (or introduce a corresponding interface), and TColorDialog descends from TBasicColorDialog, and the ColorDialog of TColorBox and TColorListbox should be a TBasicColorDialog.

I did not think through every detail of this idea, but it would be great to have more flexibility.

[jamie]

You posted it in Lazarus-CCR section, I move it to Lazarus 

Bart

Thanks @bart, I slipped up.

@Wp.
 
 You're welcome to do this, I love enhancements that have worth !

 Btw, the patch I summited went through but please, make changes on that if you wish to allow more flexibility ! 


P.S.
   I got thinking about that, if you place a base structure like that in there then it needs to supply at least the colors property for these controls to function..
   
 The color dialog has features to adjust the display for different options. The LCL fully expands it currently but I don't see much of an issue if you were to design another dialog that is based from the color dialog?