- move procedure PrepareTaskDialogConfig to Execute, since it refrences variables on the stack
- move function DialogBaseUnits
- in callbackfunction only test if dwRefData is correct if a button is clicked, and only if assertions are enabled
- rename some nested procedures and variables
- less debug output
- TWin32WSTaskDialog.Execute now properly returns the result of TaskDialogIndirect
- use CommCtrl.TaskDialogIndirect, change the mechanisme of detecting wether this is supported.
- first attempt to get Win32 WS code working (currently littered with writeln() statements, so crashes if no console!)
- fix ModalResult in OnButtonClicked for emulated dialog.
- Change signature of TWSTaskDialog.Execute and related functions/methods so we can set ParentWnd and retrieve RadioRes.
The TLCLTaskDialog now should act the same as the old emulated version (unit LCLTaskDialog).
- Use meaningfull names for private vars of TLCLTaskDialog
- Factor out SetupPanel
- Consistent capitalization of "Result" ,"True" and "False"
- Remove property VerifyChecked, set appropriate flag instead
- More debugln statements
- Add some comments
The emulated dialog is now more or less functional (we don't return RadioResult yet).
- Fix not displaying common buttons in TLCLTaskDialog.SetupControls
- Assign TLCLDialog.FDlg in the CreateNew() constructor.
- Free LDefaultFont
- Start comparing the new form vs the old form
Still not functional.
- expose Dialogs.TTaskDialog.ParentWindow as reado only property (needed in TLCLTaskDialog.Execute)
- furhter implement adding controls at runtime to TLCLTaskDialog
- it compiles, but still not functional.
- Deprecated unit LCLTaskDialog.
- Unit TaskDlgEmulation: work in progress.
- Start implementing TLCLTaskDialog class. Not functional yet (but at least it should compile).
- Code copied and adapted from the now deprecated LCLTaskDialog unit.
- Temporarily exposed a private variable of Dialogs.TTaskDialog
Eventually we need to cast the parameter to TCustomTaskDialog in the Win32 implementation.
Because of the (Delhi compatible) signature of TTaskDialog.DoExcute, it seems that TCustomTaskDialog cannot
inherit from TCommonDialog, since this method (TCustomTaskDialog.DoExecute) must be dynamic, so it cannot
also be "override" as well.
the issue fixed:
1. run your app, open Modal Form
2. switch to other apps
3. in the dock, right click your app ico and select "Show All Window", and select a window
4. the Modal Form is disappear (actually ordered behind the selected Form)
in TCocoaCustomControl, such as Form, Grid, ListView, after inputting text, another control may be focused.
in insertText_replacementRange(), Cocoa/InputContext doesn't like it, so calling InputClientInsertText() asynchronously.
Decisions on "fold-block-type" (or open/close) can not be based on "ScanAhead".
If one of the "ahead scanned" lines changes, the fold structure (type/depth) for the above node will be wrong.
E.g., TLazSynEditNestedFoldsList will trigger a temp-scan and get non-matching results. This means "node info" may not be found (due to incorrect fold-level), and code can crash. (observed with MarkupFoldColoring, triggers "assert" in TLazSynEditNestedFoldsList)
