Question about TCaption-Ttranslation strings used to ColorListBox and ColorBox

[jamie]

Here is an example of redirecting the EXECUTE function to use a different Dialog..
Placed here is just code example of going to the existing dialog but you can see how its possible to direct it to something else
and define the color properties of the original dialog box on EXECUTE exit.

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

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, ColorBox;
9.  
10. type
11.   TMyColorDialog = Class(TColorDialog)
12.     Public
13.     Function  Execute:Boolean override;
14.   End;
15.  
16.   { TForm1 }
17.  
18.   TForm1 = class(TForm)
19.     ColorListBox1: TColorListBox;
20.     procedure FormCreate(Sender: TObject);
21.   private
22.  
23.   public
24.     MyDialog:TMyColorDialog;
25.   end;
26.  
27. var
28.   Form1: TForm1;
29.  
30. implementation
31.  
32. {$R *.lfm}
33.  
34. { TForm1 }
35.  
36. procedure TForm1.FormCreate(Sender: TObject);
37. begin
38.   MyDialog := TMyColorDialog.Create(Self); {Note :Enable the custom options in the ColorListBox}
39.   Colorlistbox1.ColorDialog := MyDialog;
40. end;
41.  
42. Function TMyColorDialog.Execute:Boolean;
43.  Begin
44.    Beep;
45.    Title := 'Eddy Lives';
46.    Result := Inherited; {Call this for now as a demo, other wise call a different dialog box }
47.  end;                   {and populate the COLORS property etc..}
48.  
49. end.
50.  
51.  
52.  

You need the Trunk of course for color box and listbox .

[jamie]

I just made up a simple Color dialog as a concept idea of how to use the TcolorDialog as the base and keep things happy with the rest of the LCL

 here I can design the complete color dialog with the OI if I wish and call it anytime anywhere to my liking !..

 you will notice I assign it to an existing control that expects a TColorDialog but works just as well.

 enjoy..
 
 Make sure you select the CUSTOM color in the ListBox so the dialog will open.

[wp]

The problem with deriving from TColorDialog is that you have all the internals of this class on board, e.g. the widgetset architecture ( well- maybe this cannot be avoided), but there are also the CustomColors which are ignored in your special dialog. Inheriting from TColorDialog means that you must implement also the CustomColors although you don't want them for some reason.

[jamie]

All of that can be retrieved in that example. Its all there.

So if you want to bring the custom colors out on a new form you can..

I just didn't do it.. That was just an example of how to do the basics.

Nothing has to be changed this way and its a good thing the  EXECUTE function was a virtual one so that it could be overridden.

 Also, this method allows you to have a property to choose if you want the custom dialog or still use the original.
 
 You can even go as far as offering several different dialogs with that method..

 I can extend the demo to show the custom colors if you wish.. But I am sure you can do that too.. So I don't think I need to do that..

[wp]

In Jamie's patch: FColorDialog: TCommonDialog?
This way you can assign it a TColorDialog, a TColorDialog derivative, or any other custom dialog (derived from TCommonDialog)?

No, it inherits from TColorDialog. TCommonDialog is too general, it does not have the Color property needed by the TColorListbox and the TColorBox. My first thought was of an intermediate, abstract class, something like this:

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

1. type
2.   TBasicColordialog = class(TCommonDialog)
3.   protected
4.     function GetColor: TColor; virtual; abstract;
5.     protected SetColor(const AValue: TColor); virtual; abstract;
6.   public
7.     property Color: TColor read GetColor write SetColor;
8.   end;
9.  
10.   TColorDialog = class(TBasicColorDialog)
11.   private
12.     FColor: TColor;
13.   ...
14.   protected
15.     function GetColor: TColor; override;                // Result := FColor;
16.     procedure SetColor(const AValue: TColor); override;   // FColor := AValue;
17.     ...
18.   published
19.     property Color;
20.   end;
21.  
22.   TColorListbox = class(....)
23.   private
24.     FColorDialog: TBasicColorDialog;
25.     ...
26.   published
27.     property ColorDialog: TBasicColorDialog read FColorDialog write FColorDialog;
28.     ...
29.   end;
30.  

That's one possibility. What I don't like is that the color dialog still must derive from TCommonDialog. There is no way to hook in the mbColorLib color dialogs or any other third-party color dialogs without changing their code - the TmbOfficeColorDialog, for example, inherits from TComponent directly. But isn't this what interfaces are good for? Unfortunately I am not very experienced with them. My question to the experienced users here: When the ColorDialog property of, e.g., TColorListbox inherits only from TComponent, is there some trick with interfaces so that it can be used by TColorListbox?
 

[Bart]

TCommonDialog is too general, it does not have the Color property needed by the TColorListbox and the TColorBox.

I realized this almost immediately after I posted it 
Since I saw no reply I deleted that post.
Obviously you were typing a reply at that moment.

Bart

[jamie]

No, it inherits from TColorDialog. TCommonDialog is too general, it does not have the Color property needed by the TColorListbox and the TColorBox. My first thought was of an intermediate, abstract class, something like this:

 You are beating yourself up in trying to reduce that..  The color property is generally the property most software goes for.

 Have fun 


 P.S.
  The TCOLORBUTTON on the Misc tab also uses the TColorDialog option, too and that too references the COLOR property.