TTaskDialog musings

[Arioch]

The test was done in Delphi XE2, as some of the properties tested do not exist in LCL.

1. Footer text is word-wrapped and height grows. The long strings in the footer do not increase the dialog's width.

2. Command Buttons height is calculated to fit both Caption and Hint. Different buttons can have different height.

3. Notice, how part of Caption was "downgraded" to the Hint. It seems like either inside Windows ComCtl or inside VCL both caption and hint are merged into "array of string", then first string is considered the caption, and all the rest - multi-line hint.

4. The long caption gets word-wrapped, but at the same time it causes some limited expansion of the dialog's width

[Arioch]

It seems Microsoft Win7 TaskDialog has some rather narrow constraints upon the dialog width.
It varies, but in some very strict margins. i'd estimate width varyation 20-40%

The dialog width does not seem dependent upon screen resolution ( as in Max(X), Max(Y) )

Not sure about screne resolution as in DPI/PPI - this requires logout...
UPD.  Did test with 150% DPI, can't aatch as it is 550 KB

With 150% PPI the dialog size is 1050 x 1030 px
Original size at 100% PPI was 560 x 760 px  ( minimal width was about 500 px )
The proportions changed, but the area is scaled almost exactly 1.5^2 times

The dialog window, i speculate, was squeezed by reduced screen height ( in typographic units, not pixels ) and forced Windows to make the dialog wider.

The window caption is not taken into account w.r.t. the width.

[Martin_fr]

It seems Microsoft Win7 TaskDialog has some rather narrow constraints upon the dialog width.
It varies, but in some very strict margins. i'd estimate width varyation 20-40%

From the docs
https://learn.microsoft.com/en-us/windows/win32/api/commctrl/ns-commctrl-taskdialogconfig
Flags:

TDF_SIZE_TO_CONTENT

   Indicates that the width of the task dialog is determined by the width of its content area. This flag is ignored if cxWidth is not set to 0.

cxWidth
Type: UINT

The width of the task dialog's client area, in dialog units. If 0, the task dialog manager will calculate the ideal width.

"dialog units"
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/bb226789(v=vs.85)

About DLUs: In unmanaged code, the system measures the placement of controls on a surface in dialog units (DLUs), not pixels. A dialog unit is the device-independent measure to use for layout. One horizontal dialog unit is equal to one-fourth of the average character width for the current system font. One vertical dialog unit is equal to one-eighth of an average character height for the current system font. The default height for most single-line controls is 14 DLUs. Be careful if you use a pixel-based drawing program, because it might not provide an accurate representation when you translate your design into dialog units. If you do use a pixel-based drawing tool, you may want to take screen snapshots from a development tool that supports dialog units and use those images. Your application can retrieve the number of pixels per base unit for the current display by using the GetDialogBaseUnits function.

[Arioch]

TDF_SIZE_TO_CONTENT

ATM i am trying to jsut observe VCL XE2 behavior clean-room style. I can look into VCL sources, but don't want to.

It also is not that much important as long as Lazarus goal is compatibility to Delphi, not to Win32 as it can be.

Auto-size in LCL seems to work more reliably than in VCL XE2 (almost all my attempts to set TForm.AutoSize to True failed miserably), so hopefully replacing mORMot's "pixel calculation" implementation with some auto-sizing window built of auto-sizing panels with different Align would be possible.

Meanwhile, three last screenshots.

The captions of radiobuttons get word-wrapped, but do effect the dialog's width.
So do TTaskDialog.Text and TTaskDialog.Title

However, the width in my FullHD (1920x1200) screen varies between 500 and 560, until would be squeeezed by Screen.ActiveMonitor.Height.

I start thinking that LCL implementaiton could strive at some fixed width in physical inches and only change height. Until some developer would pushes the boundaries that seems to be good enouth. And if the boundaries are pushed - then imperfect behaviour would be acceptable.

[Arioch]

3. Notice, how part of Caption was "downgraded" to the Hint. It seems like either inside Windows ComCtl or inside VCL both caption and hint are merged into "array of string", then first string is considered the caption, and all the rest - multi-line hint.

And documented so. https://learn.microsoft.com/en-us/windows/win32/api/commctrl/ns-commctrl-taskdialog_button

When using Command Links, you delineate the command from the note by placing a new line character in the string.

Interested, how it deviates from usual Microsoft API pattern of have strings separated by #0 and terminated by #0#0