Here's the patch, which, at least on Linux works as intended. As an extra bonus, I added a better button positioning: Button positions start at the right of the dialog and not at the left, providing the same layout as that of GTK2 and QT.

Kind regards,

Giuliano

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lazdlg.diff
Type: text/x-patch
Size: 3309 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/customdrawn/attachments/20120916/92664a98/attachment.bin>

Sorry, I was first in Greece and than in Switzerland =)

What are those "{$ifdef LCLCustomdrawn}"? The LCL should not have widgetset-specific ifdefs by design.

Thanks, applied in rev 38882.

Felipe Monteiro de Carvalho hat am 28.
September 2012 um 10:36 geschrieben:

Sorry, I was first in Greece and than in Switzerland =) What are those "{$ifdef LCLCustomdrawn}"? The LCL should not have widgetset-specific ifdefs by design.

s/should not/must not/

Thanks, applied in rev 38882.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/customdrawn/attachments/20120928/2e4df06e/attachment.html>

Not to mention that they are useless. LCLCustomDrawn is not defined while compiling the LCL.

And one more issue: This dialog was supposed to be the implementation for which widgetset routine? LCLIntf.MessageBox? If yes, then doesnt it just duplicate the unit Dialogs which already has all these non-native dialogs:

function MessageDlg(const aMsg: string; DlgType: TMsgDlgType;
            Buttons: TMsgDlgButtons; HelpCtx: Longint): TModalResult;
function MessageDlg(const aCaption, aMsg: string; DlgType: TMsgDlgType;
            Buttons: TMsgDlgButtons; HelpCtx: Longint): TModalResult;
function MessageDlg(const aCaption, aMsg: string; DlgType: TMsgDlgType;
            Buttons: TMsgDlgButtons; HelpCtx: Longint; DefaultButton:
TMsgDlgBtn): TModalResult;
function MessageDlg(const aCaption, aMsg: string; DlgType: TMsgDlgType;
            Buttons: TMsgDlgButtons; const HelpKeyword: string): TModalResult;
function MessageDlgPos(const aMsg: string; DlgType: TMsgDlgType;
            Buttons: TMsgDlgButtons; HelpCtx: Longint; X, Y: Integer):
TModalResult;
function MessageDlgPosHelp(const aMsg: string; DlgType: TMsgDlgType;
            Buttons: TMsgDlgButtons; HelpCtx: Longint; X, Y: Integer;
            const HelpFileName: string): TModalResult;
function CreateMessageDialog(const Msg: string; DlgType: TMsgDlgType;
            Buttons: TMsgDlgButtons): TForm;
function QuestionDlg(const aCaption, aMsg: string; DlgType: TMsgDlgType;
            Buttons: array of const; HelpCtx: Longint): TModalResult;
function QuestionDlg(const aCaption, aMsg: string; DlgType: TMsgDlgType;
            Buttons: array of const; const HelpKeyword: string): TModalResult;
procedure ShowMessage(const aMsg: string);
procedure ShowMessageFmt(const aMsg: string; Params: array of const);
procedure ShowMessagePos(const aMsg: string; X, Y: Integer);
function InputQuery(const ACaption, APrompt : String; MaskInput :
Boolean; var Value : String) : Boolean;
function InputQuery(const ACaption, APrompt : String; var Value :
String) : Boolean;
function InputBox(const ACaption, APrompt, ADefault : String) : String;
function PasswordBox(const ACaption, APrompt : String) : String;

?

When I started lazdialogs.pas I was thinking about File Open, Directory Select, File Save, Printer, etc, dialogs. I would say that this is where one should concentrate...

thanks,

Ummm, I think I was wrong, steping into the code it seams that Dialogs does not really implement the dialogs, it just makes some reorganization of the information and in the end it calls TCDWidgetSet.PromptUser

So this would be a implementation for TCDWidgetSet.PromptUser. Sorry for the confusion =)

In this case, maybe the routines in lazdialogs should have the same parameters as TCDWidgetSet.PromptUser

thanks,

Felipe Monteiro de Carvalho ha scritto:

Not to mention that they are useless. LCLCustomDrawn is not defined while compiling the LCL.

They are a residual of my tests, when I was testing the unit as a user unit, so that the ifdef made sense, but I left them in as a reminder that for some obscure reasons if the new dialogs are used with the Customdrawn WS the form release doesn't work, causing subsequent crash (it would appear that what gets released is the main form instead, but I didn't investigate in deep). I mentioned it some time ago. Maybe a comment would have been more appropriate than leaving there useless ifdefs, but I forgot....

Giuliano

Felipe Monteiro de Carvalho ha scritto:

There are two scenarios: CustomDrawn components in a standard WS, and CustomDrawn components for the CD WS.

The current implementation is addressing only the first scenario. In that case LazDialogs should have different names from the equivalent native WS Dialogs, but they should offer an equivalent user interface, to make things easier for our "customers".

CustomDrawn dialogs in CD WS frame are another matter: the user interface is provided by LCL, and they should implement the PromptUser interface, to keep consistency.

The same holds true for other dialogs, such as the FileOpen, but we should first fix be able to release a CD modal form without crashing....

Giuliano

Yes, but the problem is that I think that TCDWidgetSet.PromptUser is more generic then what you currently wrote, so I am not sure if the current routines can be utilized to implemented
TCDWidgetSet.PromptUser. I'd say that the first steps should be implementing a routine with parameters as TCDWidgetSet.PromptUser has, and then make a ShowMessageDlg or whatever other higher end routine which repacks it for easier usage. If you start from the higher level interface, then afterwards the code will need a lot of change to be useful in the lower end routine.

My file open/save/etc dialogs where written thinking on the WS implementation already and are prepared to be useful for WS implementation without much changes.

Il 29/09/2012 08:17, Felipe Monteiro de Carvalho ha scritto:

Ok. I understand your point, you're right.

In place of your Greece and Switzerland, my next trips will be to a couple of times to France and a couple of weeks in Hong Kong. I hope to avoid the trip to Qatar, but not yet sure ;-) . Because of that it may take some time, but as soon as I can I will look into the matter by this point of view, so that integration in WS implementation becomes reasonably smooth.

On the same subject there's another point: currently CDButton still lack some features (proper caption handling, for translation and shortcuts), so that our dialog buttons wouldn't be translated to the appropriate locale, they wouldn't show the underlined character for the shortcut, and they wouldn't react to shortcut key.
That's another point in my TODO list.

Kind regards,

Giuliano