[fixed] [bug 39155] Title of TColorDialog is not shown

[Muso]

I have both a local work around and patch ready for submission to include the Callback hook in the Widget so the title can be assigned..

  Thanks. Can you please post your patch here that even when the admin refuse it, I could use it for my programs?

[jamie]

what I will do is post the local work around as a demo project, you can take it from there.

P.S.
  Be very careful to only make changes in the hook procedure when the WM_InitDialg message comes in, ignore all others. there is lots of traffic that comes through  there you don't want to be playing games.

[wp]

I see the report was closed, no surprise..

What does this mean?

Rather than being pissed off, extract the essentials out of your demo project and put it into the win32 widgetset infrastructure, create a proper patch, reopen Muso's bug report (or create a new one if you are not allowed to), and I dont't see a reason why this should not make it into the LCL.

[jamie]

I am not pissed off, just frustrated with certain situations. If I was pissed off I wouldn't be here any more..

  Appended  is a mod to make it easier to use the same code for  multiple color dialogs using what is already provided by windows for since the beginning of color dialogs.

 Any one is free to do as they wish with this code, even wedge it into the widget if they feel like it.

 I need to review the patch again, I only did with my local copy here which is 2.0.4 .

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

1. Function CCHookProc(H:THandle; msg:Cardinal; W:Wparam; L:Lparam):UintPtr; StdCall;
2. var
3.   S:String;
4. Begin
5.   If (H <> 0) and (Msg = Wm_InitDialog) then
6.    Begin
7.      S := TColorDialog(PchooseColor(L)^.lCustData).Title ;
8.      SetWindowText(H, Pchar(S));
9.    end;
10.   Result := 0;
11. end;
12.  
13. procedure TForm1.ColorDialog1Show(Sender: TObject);
14. Var
15.   C:PChooseColor;
16. begin
17.   With TColorDialog(Sender) do
18.     Begin
19.      C := Pointer(Handle); //This handle is actually a pointer to a ChoseColor record;
20.      C^.lpfnHook := @CCHookPRoc;
21.      C^.lCustData := UintPtr(Sender); //Give the callback the Color dialog instance to play with.
22.      C^.Flags := C^.Flags or CC_ENABLEHOOK;
23.     end;
24.  
25. end;                                                                
26.  

[Muso]

I am not pissed off, just frustrated with certain situations. If I was pissed off I wouldn't be here any more..

Very good to hear. Frustrations go away, and the best way is when a patch is accepted. 

I can confirm that your code fixes the problem and the output is exactly as I expected it.

Can you therefore please make a patch to have it included to the LCL?

[wp]

Integrated jamie's code into the windows widgetset (and fixed the character encoding issue) --> works. Please test from trunk.

[jamie]

@WP
  Did you go by my last mod so that it properly assigns different dialogs when they show ?

  The ChoseColor record has the customData pointer in it that passes it to the call back so you can determine who or which Dialog it is.

 But looking at it, I thought it to be a 2 file process.?

Anyways, I just built the trunk and it looks good but I only did one color dialog.

[wp]

No idea what you mean....

This is the code that I added to/modified in win32wsdialog.pp, and in my tests it is working correctly in both 32bit and 64bit:

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

1. Function CCHookProc(H: THandle; msg: Cardinal; W: WParam; L: LParam): UintPtr; StdCall;  // <--- added
2. var
3.   ws: WideString;
4. begin
5.   if (H <> 0) and (Msg = WM_InitDialog) then
6.   begin
7.     ws := TColorDialog(PChooseColor(L)^.lCustData).Title;
8.     SetWindowTextW(H, PWideChar(ws));
9.   end;
10.   Result := 0;
11. end;
12.  
13. class function TWin32WSColorDialog.CreateHandle(const ACommonDialog: TCommonDialog): THandle;
14. var
15.   CC: PChooseColor;
16.   ColorDialog: TColorDialog absolute ACommonDialog;
17.  
18.   procedure FillCustomColors;
19.   var
20.     i, AIndex: integer;
21.     AColor: TColor;
22.   begin
23.     for i := 0 to ColorDialog.CustomColors.Count - 1 do
24.       if ExtractColorIndexAndColor(ColorDialog.CustomColors, i, AIndex, AColor) then
25.       begin
26.         if AIndex < 16 then
27.           CC^.lpCustColors[AIndex] := AColor;
28.       end;
29.   end;
30.  
31. begin
32.   CC := AllocMem(SizeOf(TChooseColor));
33.   with CC^ Do
34.   begin
35.     LStructSize := sizeof(TChooseColor);
36.     HWndOwner := GetOwnerHandle(ACommonDialog);
37.     RGBResult := ColorToRGB(ColorDialog.Color);
38.     LPCustColors := AllocMem(16 * SizeOf(DWord));
39.     FillCustomColors;
40.     lCustData := LParam(ACommonDialog);      // <--- added
41.     lpfnHook := @CCHookProc;                  // <--- added
42.     Flags := CC_FULLOPEN or CC_RGBINIT or CC_ENABLEHOOK;  // <--- extended
43.   end;
44.   Result := THandle(CC);
45. end;

[jamie]

Perfect..

 yes, I forgot it all up in the widget..

Thanks.

[Muso]

Integrated jamie's code into the windows widgetset (and fixed the character encoding issue) --> works. Please test from trunk.

Many thanks! I can confirm that the bug is now fixed in latest Lazarus trunk.

[Muso]

Concerning Jamie's frustration, maybe the next time bugs are not immediately be closed. We all code in our spare time and thus time is necessary to think about and for users to look at the different forum threads.
 

[jamie]

Glad things worked out

I just came up with an idea that relates to this..

There are three color pick controls. ColorBUtton, ColorListBox and ColorBox. none of which have a property to define the title of the internal TcolorDialog that is used..
 
 Would be nice if these controls had a dialogTitle property 

btw.

 We can all thank WP for pushing this through..

[Bart]

There are three color pick controls. ColorBUtton, ColorListBox and ColorBox. none of which have a property to define the title of the internal TcolorDialog that is used..
 
Would be nice if these controls had a dialogTitle property 

TColorButton has a property ColorDialog, so it is accessible through that.
The other 2 controls could use that in their PickCustomColor function I guess?

Feel free to provide a patch in a (new) bugtracker issue.

Bart

[Bart]

Integrated jamie's code into the windows widgetset (and fixed the character encoding issue) --> works. Please test from trunk.

Many thanks! I can confirm that the bug is now fixed in latest Lazarus trunk.

And it caused a regression, see the associated bugreport.

Bart

[jamie]

Integrated jamie's code into the windows widgetset (and fixed the character encoding issue) --> works. Please test from trunk.

Many thanks! I can confirm that the bug is now fixed in latest Lazarus trunk.

And it caused a regression, see the associated bugreport.

Bart

Bart, Please stop it...

 There is no regression. The fact is that it has been stated it worked in the other widgets and if that is the case then they must of been displaying "Select Color" because that is the default string in the TColorDialog and that never got changed.

 For those that grew up on windows and have used many other tools knows that having an optional display at the top has always been the case. I am sorry that you just can't see it that way. This isn't any hack. its actual documented features of windows and I get the feeling you already know this. Or, maybe you don't?

 I do think I understand the real problem and it has nothing to do with the changes made.. I believe most of us are adults here, aren't we?