[WEP] Themed Windows message dialogs - #5922
Conversation
WalkthroughThe WEP proposes themed Windows message dialogs through ChangesThemed Windows message dialogs
Estimated code review effort: 1 (Trivial) | ~5 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
v3/wep/proposals/themed-message-dialogs/proposal.md (1)
132-134: 🗄️ Data Integrity & Integration | 🔵 Trivial | 🏗️ Heavy liftTest the serialized ABI, not only the pure builder.
At Lines [132-134] and [149-152], the test plan covers logical configuration but not the hand-packed bytes passed to Win32. Add tests for
cbSize, field offsets, union selection, pointer width, button-array serialization, and pointer lifetimes. Run them forwindows/386,windows/amd64, andwindows/arm64, or compare against checked-in expected layouts. The native contract contains pointer fields in bothTASKDIALOGCONFIGandTASKDIALOG_BUTTON. (learn.microsoft.com)Also applies to: 149-152
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@v3/wep/proposals/themed-message-dialogs/proposal.md` around lines 132 - 134, Extend the test plan for buildTaskDialogConfig and its serialization path to validate the Win32 ABI, including cbSize, field offsets, union selection, pointer width, TASKDIALOG_BUTTON array encoding, and pointer lifetimes. Run these checks for windows/386, windows/amd64, and windows/arm64, or compare serialization against checked-in expected layouts while preserving the existing logical configuration coverage.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@v3/wep/proposals/themed-message-dialogs/proposal.md`:
- Around line 53-55: Update the TaskDialogIndirect result-mapping logic to
explicitly map IDCANCEL from Escape, Alt-F4, or title-bar close to the
configured custom cancel button, preserving its label and OnClick result. When
cancellation is configured without TDCBF_CANCEL_BUTTON, enable
TDF_ALLOW_DIALOG_CANCELLATION, and add a manual test covering a custom cancel
label with Escape and title-bar close.
- Around line 42-46: Update the showModern() failure handling to classify
TaskDialogIndirect errors, using the existing unsupported-dialog/API-unavailable
condition for showLegacy() fallback only. Treat E_INVALIDARG and E_OUTOFMEMORY
as configuration/resource failures that must be surfaced rather than silently
routed through showLegacy(), while preserving the current legacy behavior for
genuinely unsupported dialog paths.
- Around line 64-67: Document the compatibility mapping from the themed Question
icon to one of TaskDialogIndirect’s supported predefined icons, and make
buildTaskDialogConfig apply that mapping consistently. Add unit coverage
verifying the Question icon translation while preserving the existing per-type
icon and app-icon fallback behavior.
- Around line 40-49: Update the themed message dialog proposal to explicitly
address MB_SYSTEMMODAL semantics in showModern(): either define how the modern
TaskDialogIndirect path preserves the legacy topmost/system-modal behavior, or
document that this behavior changes when showModern() succeeds. Keep
showLegacy() unchanged and ensure the fallback contract is stated consistently.
---
Nitpick comments:
In `@v3/wep/proposals/themed-message-dialogs/proposal.md`:
- Around line 132-134: Extend the test plan for buildTaskDialogConfig and its
serialization path to validate the Win32 ABI, including cbSize, field offsets,
union selection, pointer width, TASKDIALOG_BUTTON array encoding, and pointer
lifetimes. Run these checks for windows/386, windows/amd64, and windows/arm64,
or compare serialization against checked-in expected layouts while preserving
the existing logical configuration coverage.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 62f80730-c18b-4a40-a610-4759fe4c5dcb
📒 Files selected for processing (1)
v3/wep/proposals/themed-message-dialogs/proposal.md
| Message dialog display gains a modern path with a graceful fallback: | ||
|
|
||
| - `showModern()` builds and shows a `TaskDialogIndirect` dialog. On **any** | ||
| failure — most importantly when the process has no Common-Controls v6 | ||
| side-by-side assembly, so the API is unavailable — it returns `false`. | ||
| - `showLegacy()` is the existing unchanged `MessageBox` path, used whenever | ||
| `showModern()` returns `false`. | ||
|
|
||
| So the change is additive: environments that can render a task dialog do; | ||
| everything else behaves exactly as today. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== repo files matching dialog/modality/proposal =="
git ls-files | rg '(^|/)(proposal\.md|dialogs_windows\.go|.*dialog.*\.go|.*thread.*\.go)$' || true
echo
echo "== relevant proposal section =="
if [ -f v3/wep/proposals/themed-message-dialogs/proposal.md ]; then
nl -ba v3/wep/proposals/themed-message-dialogs/proposal.md | sed -n '1,120p'
fi
echo
echo "== search MB_SYSTEMMODAL and showModern/showLegacy =="
rg -n "MB_SYSTEMMODAL|showModern|showLegacy|TaskDialogIndirect|TASKDIALOG_FLAGS|TDF" .Repository: wailsapp/wails
Length of output: 3504
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== relevant proposal section =="
sed -n '1,140p' v3/wep/proposals/themed-message-dialogs/proposal.md
echo
echo "== dialogs_windows section around MB_SYSTEMMODAL =="
sed -n '1,130p' v3/pkg/application/dialogs_windows.go
echo
echo "== search MB_SYSTEMMODAL, showModern, showLegacy, task dialog symbols =="
rg -n "MB_SYSTEMMODAL|showModern|showLegacy|TaskDialogIndirect|TASKDIALOG_FLAGS|TDF_SystemModal|SystemModal|TDF_MODAL" v3 v2/pkg/runtime v3/pkg/runtimeRepository: wailsapp/wails
Length of output: 11523
🌐 Web query:
Microsoft MSGBOX_STYLE MB_SYSTEMMODAL TaskDialog TDF_SYSTEM_MODAL TASKDIALOG_FLAGS topmost documentation
💡 Result:
In the Windows API, MB_SYSTEMMODAL and TDF_SYSTEM_MODAL represent different approaches to modality for legacy message boxes and modern task dialogs, respectively [1][2]. MessageBox MB_SYSTEMMODAL The MB_SYSTEMMODAL flag is used with the legacy MessageBox function [1]. When this flag is specified, the message box is created with the WS_EX_TOPMOST window style [1][3]. It is intended for critical, system-wide notifications—such as low-memory warnings—that require the user's immediate attention [1][3]. Notably, while it forces the window to be top-most, it does not inherently suspend all other applications or threads, despite the name; its primary effect is ensuring the dialog remains visible above other windows [1][3]. TaskDialog and TDF_SYSTEM_MODAL There is no TDF_SYSTEM_MODAL flag in the official TaskDialog or TaskDialogIndirect documentation [4]. The Task Dialog API (commctrl.h) does not provide a direct equivalent to the legacy MB_SYSTEMMODAL flag [4]. If you need to make a TaskDialog behave as an "always-on-top" or system-modal window, the official recommendation is to avoid trying to replicate the legacy MB_SYSTEMMODAL behavior, as modern Windows design guidelines discourage its use [5]. However, developers looking to achieve similar behavior have historically used workarounds, such as using the TaskDialogIndirect function with a callback (TDN_DIALOG_CONSTRUCTED) to obtain the dialog's window handle (HWND) and subsequently using SetWindowPos to apply the HWND_TOPMOST flag [6]. Summary Table Feature: MessageBox (MB_SYSTEMMODAL) | TaskDialog Modality Flag: MB_SYSTEMMODAL [1] | None (No TDF_SYSTEM_MODAL exists) [4] Behavior: Applies WS_EX_TOPMOST style [1] | Requires manual intervention (e.g., SetWindowPos) [6] Recommended Use: Rare, critical system errors only [1][3] | Standard modal dialogs [5][7] For standard application-level modality in Task Dialogs, you should use the hwndParent member of the TASKDIALOGCONFIG structure, which ensures the dialog is modal to the specified owner window [4][8]. [1][4][6]
Citations:
- 1: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-messagebox
- 2: https://learn.microsoft.com/en-us/windows/win32/controls/task-dialogs
- 3: https://winapi.freetechsecrets.com/win32/WIN32MessageBox.htm
- 4: https://learn.microsoft.com/en-us/windows/win32/api/commctrl/ns-commctrl-taskdialogconfig
- 5: https://learn.microsoft.com/en-us/windows/win32/api/commctrl/nf-commctrl-taskdialog
- 6: https://stackoverflow.com/questions/1462708/taskdialog-always-on-top-in-visual-c
- 7: https://learn.microsoft.com/en-us/windows/win32/controls/using-task-dialogs
- 8: https://asp-blogs.azurewebsites.net/kennykerr/Windows-Vista-for-Developers-_1320_-Part-2-_1320_-Task-Dialogs-in-Depth
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== calculateMessageDialogFlags implementation =="
sed -n '180,235p' v3/pkg/application/dialogs_windows.go
echo
echo "== references to MB_SYSTEMMODAL outside v3/pkg/application/dialogs_windows.go =="
rg -n "MB_SYSTEMMODAL|MB_INFORMATION|MB_WARNING|MB_ERROR|MB_YESNOCANCEL|MB_YESNO" --glob '*.go' --glob '*.md' .Repository: wailsapp/wails
Length of output: 3627
Preserve the current MB_SYSTEMMODAL behavior or change the current dialog contract.
MB_SYSTEMMODAL gives the legacy MessageBox path an observable topmost effect. TaskDialogIndirect does not expose a direct equivalent (TDF_SYSTEM_MODAL is not in the documented TASKDIALOG_FLAGS), so the modern path can only behave “exactly as today” if the implementation maps this explicitly or if the proposal now documents a behavioral change.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@v3/wep/proposals/themed-message-dialogs/proposal.md` around lines 40 - 49,
Update the themed message dialog proposal to explicitly address MB_SYSTEMMODAL
semantics in showModern(): either define how the modern TaskDialogIndirect path
preserves the legacy topmost/system-modal behavior, or document that this
behavior changes when showModern() succeeds. Keep showLegacy() unchanged and
ensure the fallback contract is stated consistently.
| - `showModern()` builds and shows a `TaskDialogIndirect` dialog. On **any** | ||
| failure — most importantly when the process has no Common-Controls v6 | ||
| side-by-side assembly, so the API is unavailable — it returns `false`. | ||
| - `showLegacy()` is the existing unchanged `MessageBox` path, used whenever | ||
| `showModern()` returns `false`. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Files matching proposal:\n'
fd -a 'proposal.md' | rg 'v3/wep/proposals/themed-message-dialogs/proposal.md' || true
printf '\nRelevant proposal lines:\n'
sed -n '1,80p' v3/wep/proposals/themed-message-dialogs/proposal.md
printf '\nSearch for showModern/showLegacy and TaskDialogIndirect usages:\n'
rg -n "showModern|showLegacy|TaskDialogIndirect|theme|MessageDialog|Common-Controls" .Repository: wailsapp/wails
Length of output: 50371
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'proposal.md lines 1-100:\n'
sed -n '1,100p' v3/wep/proposals/themed-message-dialogs/proposal.md
printf '\nFocused source docs matches (limited):\n'
rg -n "showModern|showLegacy|TaskDialogIndirect|E_INVALIDARG|E_OUTOFMEMORY|Common-Controls" \
--glob '!node_modules' --glob '!vendor' --glob '!dist' --glob '!build' \
. | head -200
printf '\nGit diff stat/name status:\n'
git diff --stat HEAD~1..HEAD 2>/dev/null || git diff --stat || true
git diff --name-only HEAD~1..HEAD 2>/dev/null || trueRepository: wailsapp/wails
Length of output: 30474
🌐 Web query:
Microsoft TaskDialogIndirect returns E_INVALIDARG E_OUTOFMEMORY HRESULT documentation
💡 Result:
The TaskDialogIndirect function is a Win32 API used to create and display a task dialog [1]. When it fails, it returns an HRESULT code indicating the cause of the failure [1][2]. According to official Microsoft documentation, the function can return the following specific HRESULT values: - S_OK: The operation completed successfully [1][2]. - E_OUTOFMEMORY: There is insufficient memory to complete the operation [1][2]. - E_INVALIDARG: One or more arguments are not valid [1][2]. - E_FAIL: The operation failed [1][2]. Understanding E_INVALIDARG and E_OUTOFMEMORY: E_INVALIDARG is often encountered when the structure passed to the function, TASKDIALOGCONFIG, is improperly configured [3][4]. A common cause is incorrect memory alignment or padding [3][5]. The TASKDIALOGCONFIG structure requires specific byte-packing (often 1-byte alignment) to match the internal requirements of the Windows header files [3][5]. If you are calling this function from languages like VBA or Python, ensure the struct layout, including its size (cbSize), matches the expectations of the C++ header files precisely [3][5]. If the cbSize member is not set to the correct size of the structure, or if fields are misaligned due to language-specific structure padding, the system will consider the arguments invalid [3][5]. E_OUTOFMEMORY typically indicates that the system is unable to allocate the resources required to create the dialog [1]. Microsoft documentation advises that if you are displaying a task dialog to inform the user of a low-memory condition, you should avoid loading strings or icons from resource files, as those operations might also fail [1]. In practice, if you receive an error code not listed in the official documentation, or if you encounter generic failures, it may be a symptom of a broader resource exhaustion issue (such as leaked handles or COM state corruption) rather than a direct failure of the TaskDialogIndirect function itself [6].
Citations:
- 1: https://learn.microsoft.com/en-us/windows/win32/api/commctrl/nf-commctrl-taskdialogindirect
- 2: https://github.com/MicrosoftDocs/sdk-api/blob/docs/sdk-api-src/content/commctrl/nf-commctrl-taskdialogindirect.md
- 3: https://stackoverflow.com/questions/61391802/using-taskdialogindirect-in-64-bit-vba
- 4: https://www.vbforums.com/showthread.php?901351-TaskDialogIndirect-in-it-s-simpliest-form-throws-E_INVALIDARG=
- 5: https://stackoverflow.com/questions/60475469/using-taskdialogindirect-in-python
- 6: https://stackoverflow.com/questions/25389384/taskdialogindirect-is-returning-an-unusual-error-code
Limit the legacy fallback to unsupported-dialog failures.
showModern() currently treats TaskDialogIndirect failures as just Common-Controls v6 unavailability. TaskDialogIndirect can instead return E_INVALIDARG for invalid packaging/configuration and E_OUTOFMEMORY for resource allocation failure. Fallback silently drops custom-button behavior and hides those defects; reserve fallback for unsupported dialogs/API paths, or surface classification-specific failures before showing the legacy dialog.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@v3/wep/proposals/themed-message-dialogs/proposal.md` around lines 42 - 46,
Update the showModern() failure handling to classify TaskDialogIndirect errors,
using the existing unsupported-dialog/API-unavailable condition for showLegacy()
fallback only. Treat E_INVALIDARG and E_OUTOFMEMORY as configuration/resource
failures that must be surfaced rather than silently routed through showLegacy(),
while preserving the current legacy behavior for genuinely unsupported dialog
paths.
| Custom buttons are assigned stable IDs and mapped back to their `Button`, so the | ||
| correct `OnClick` handler runs and the result matches the caller's label. The | ||
| `IsDefault`/`IsCancel` flags and Esc / title-bar-close are honoured. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate proposal =="
fd -a 'proposal\.md$' . | sed 's#^\./##' | rg 'v3/wep/proposals/themed-message-dialogs/proposal\.md|themed-message-dialogs' || true
echo "== relevant sections =="
if [ -f v3/wep/proposals/themed-message-dialogs/proposal.md ]; then
wc -l v3/wep/proposals/themed-message-dialogs/proposal.md
sed -n '1,220p' v3/wep/proposals/themed-message-dialogs/proposal.md | cat -n
fi
echo "== search for TaskDialog/custom cancel buttons in repo =="
rg -n "TaskDialogIndirect|TaskDialog|pButtons|IsCancel|cancel button|task\.(dialog|Dialog)|TDCBF_CANCEL_BUTTON|TDF_ALLOW_DIALOG_CANCELLATION|IDCANCEL|Escape|title-bar" -S .Repository: wailsapp/wails
Length of output: 50371
🌐 Web query:
Microsoft TaskDialogIndirect IDCANCEL custom buttons pButtons.nButtonID TDF_ALLOW_DIALOG_CANCELLATION TDCBF_CANCEL_BUTTON documentation
💡 Result:
In the Windows API, TaskDialogIndirect allows for highly customizable dialogs [1][2]. When using custom buttons via the pButtons member of the TASKDIALOGCONFIG structure, you define the button identifier using the nButtonID member of the TASKDIALOG_BUTTON structure [3]. Regarding the specific configuration flags and IDCANCEL behavior: 1. IDCANCEL return value: When the TaskDialogIndirect function returns, the variable pointed to by the pnButton parameter will be set to IDCANCEL if the user closes the dialog via the Escape key, Alt+F4, or the title bar's close button [4]. 2. TDF_ALLOW_DIALOG_CANCELLATION: This flag in the dwFlags member of TASKDIALOGCONFIG explicitly enables the dialog to respond to typical cancel actions (Escape, Alt+F4, and the close button), even if no specific "Cancel" button is included in the dialog's configuration [5][6]. Without this flag, these actions may be ignored unless a specific cancel button is provided [7][6]. 3. TDCBF_CANCEL_BUTTON: This flag, used in the dwCommonButtons member, adds a standard "Cancel" button to the dialog [6]. When this button is included, the dialog automatically handles the typical cancel actions mentioned above [8][6]. If you provide a custom button with nButtonID set to IDCANCEL, the task dialog will treat it as the cancel button, mirroring the behavior of the standard TDCBF_CANCEL_BUTTON [7]. If you do not include a button with that ID, you must set the TDF_ALLOW_DIALOG_CANCELLATION flag if you wish for the dialog to be closable via the standard system cancel actions [7][5][6].
Citations:
- 1: https://learn.microsoft.com/en-us/windows/win32/controls/task-dialogs
- 2: https://learn.microsoft.com/en-us/windows/win32/controls/create-task-dialogs
- 3: https://learn.microsoft.com/en-us/windows/win32/api/commctrl/ns-commctrl-taskdialog_button
- 4: https://learn.microsoft.com/en-us/windows/win32/api/commctrl/nf-commctrl-taskdialogindirect
- 5: https://stackoverflow.com/questions/34481686/messagebox-return-value-when-box-has-no-cancel-button
- 6: https://github.com/MicrosoftDocs/sdk-api/blob/docs/sdk-api-src/content/commctrl/ns-commctrl-taskdialogconfig.md
- 7: https://www.codeproject.com/Articles/16806/Vista-Goodies-in-C-Using-TaskDialogIndirect-to-Bui
- 8: https://learn.microsoft.com/en-us/windows/win32/api/commctrl/nf-commctrl-taskdialog
Map system cancellation to the configured cancel button.
TaskDialogIndirect returns IDCANCEL for Escape, Alt-F4, and title-bar close, while custom buttons return TASKDIALOG_BUTTON.nButtonID. Map IDCANCEL explicitly to the button configured as cancel. Enable TDF_ALLOW_DIALOG_CANCELLATION when showing cancellation actions without a standard TDCBF_CANCEL_BUTTON, and add a manual test for a custom cancel label with Escape and title-bar close.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@v3/wep/proposals/themed-message-dialogs/proposal.md` around lines 53 - 55,
Update the TaskDialogIndirect result-mapping logic to explicitly map IDCANCEL
from Escape, Alt-F4, or title-bar close to the configured custom cancel button,
preserving its label and OnClick result. When cancellation is configured without
TDCBF_CANCEL_BUTTON, enable TDF_ALLOW_DIALOG_CANCELLATION, and add a manual test
covering a custom cancel label with Escape and title-bar close.
| the call with `runtime.KeepAlive`. The config-to-task-dialog translation is | ||
| factored into a pure `buildTaskDialogConfig` function so it can be unit-tested | ||
| (button ID assignment, default/cancel mapping, per-type common buttons and | ||
| icons, app-icon fallback). |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate file =="
fd -a 'proposal.md' . | sed 's#^\./##' | grep 'v3/wep/proposals/themed-message-dialogs/proposal.md' || true
echo "== relevant lines =="
if [ -f v3/wep/proposals/themed-message-dialogs/proposal.md ]; then
nl -ba v3/wep/proposals/themed-message-dialogs/proposal.md | sed -n '55,75p;128,142p'
else
echo "file not found"
fi
echo "== search for TaskDialog/Question implementation references =="
rg -n "buildTaskDialogConfig|TaskDialogIndirect|TD_QUESTION_ICON|MB_ICONQUESTION|HICON|icon" v3/wep/proposals/themed-message-dialogs .github . 2>/dev/null | head -200Repository: wailsapp/wails
Length of output: 302
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== relevant proposal lines =="
awk 'NR>=55 && NR<=75 {printf "%4d\t%s\n", NR, $0} NR>=128 && NR<=142 {printf "%4d\t%s\n", NR, $0}' v3/wep/proposals/themed-message-dialogs/proposal.md
echo "== implementation/proposal references =="
rg -n "buildTaskDialogConfig|TaskDialogIndirect|TD_QUESTION_ICON|MB_ICONQUESTION|HICON|icon" v3/wep/proposals/themed-message-dialogs .github . 2>/dev/null | head -250Repository: wailsapp/wails
Length of output: 29439
🌐 Web query:
Microsoft TaskDialogIndirect TD_ERROR_ICON TD_WARNING_ICON TD_INFORMATION_ICON TD_SHIELD_ICON question constant
💡 Result:
In the context of the Microsoft Windows Task Dialog API, the identifiers TD_ERROR_ICON, TD_WARNING_ICON, TD_INFORMATION_ICON, and TD_SHIELD_ICON are predefined constants used to specify standard system icons for display in a task dialog [1][2]. These constants are used with the TaskDialogIndirect function, specifically when populating the TASKDIALOGCONFIG structure [1][3]. Usage Details: - The constants are assigned to members such as pszMainIcon or pszFooterIcon within the TASKDIALOGCONFIG structure to indicate the desired system icon [1][4]. - They are interpreted as integer resource identifiers and should typically be passed to the MAKEINTRESOURCE macro when used in code [1][2]. - These icons are loaded from the system's resource module (imageres.dll) if an application-specific instance handle (hInstance) is not provided or is set to NULL [2][4]. - These constants must not be used if the TDF_USE_HICON_MAIN or TDF_USE_HICON_FOOTER flags are set in the dwFlags member of the TASKDIALOGCONFIG structure, as those flags indicate that an HICON handle is being provided instead [1][4]. The specific icons represented by these constants are: - TD_ERROR_ICON: A stop-sign icon [1][2]. - TD_WARNING_ICON: An exclamation-point icon [1][2]. - TD_INFORMATION_ICON: An icon consisting of a lowercase letter "i" in a circle [1][2]. - TD_SHIELD_ICON: A security shield icon [1][2].
Citations:
- 1: https://learn.microsoft.com/en-us/windows/win32/api/commctrl/ns-commctrl-taskdialogconfig
- 2: https://learn.microsoft.com/en-us/windows/win32/controls/tdm-update-icon
- 3: https://learn.microsoft.com/en-us/windows/win32/api/commctrl/nf-commctrl-taskdialogindirect
- 4: https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/Controls/tdm-update-icon.md
Define the Question-icon translation.
Lines 64-67 and 132-137 cover per-type icons and themed Question dialogs, but the design does not say how Question maps to TaskDialogIndirect, whose predefined icons are TD_ERROR_ICON, TD_WARNING_ICON, TD_INFORMATION_ICON, and TD_SHIELD_ICON. Document the chosen compatibility behavior and include it in the buildTaskDialogConfig tests.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@v3/wep/proposals/themed-message-dialogs/proposal.md` around lines 64 - 67,
Document the compatibility mapping from the themed Question icon to one of
TaskDialogIndirect’s supported predefined icons, and make buildTaskDialogConfig
apply that mapping consistently. Add unit coverage verifying the Question icon
translation while preserving the existing per-type icon and app-icon fallback
behavior.
github-actions
Bot
added
Documentation
1 participant
Render Windows message dialogs with the modern comctl32 v6
TaskDialogIndirectAPI instead of the legacy Win32MessageBox. This makes dialogs render themed to match the OS, and lets them honour the custom buttons a dialog was built with.Here's my implementation:
feat/windows-themed-taskdialog
Summary by CodeRabbit