The package is intended to provide additional macOS Cocoa specific features.
Note: It's expected that those features will not work on any other system or as well as for deprecated Carbon API on macOS. However, it's expected that a project using the package would still succeffully compile and run on any other target.
Author: Dmitry 'skalogryz' Boyarintsev
After installation a new "macOS" tab is added to the components palette. All additional components are available in this tab:
The component is introduced to control MacOS NSWindow specific attributes and features, not available via LCL API.
NSAppearance class was introduced in macOS 10.9 for the first time. It controls window appearance options. The fact that it's per window configuration makes it different from Themes - that's system wide configuration.
Appearance property of TmacOSFormProp component is used to adjust the appearance.
Apple suggests that there are 3 appearance styles currently available in the system:
* NSAppearanceNameAqua * NSAppearanceNameVibrantDark * NSAppearanceNameVibrantLight
The property itself is a string. It is not restricted to these 3 options only. It's case-sensitive name of the appearance as provided by macOS.
The value of the property can be changed in design time as well as run-time. As soon as the value is changed, it's expected that the appearance of the form, is changed.
Note: if the form that's hosts TmacOSFormProp is embedded into another form, then the behavior is not defined. However, it's expected the parent form appearance would change.
Using TmacOSFormProp is not desired on any component other than form. I.e. it's possible to use it on a frame, but in that case, the appearance of the hosting would be changed.
In case multiple TmacOSFormProp are used, the later action would be used as preference. Multiple TmacOSFormProp are not desired for use, and might forbidden in future versions.
The implementation is checking for the presence of NSAppearance class dynamically. Thus, if the code is launched on an earlier version of macOS, it would still be able to run, even though will not do anything.
This is how the default Aqua style might look like:
This is how the Dark style might look like:
(Note that some controls are not affected by Appearance - TMemo. This is macOS default behavior and expected result)
The actual style look as well style availability depends on a certain macOS version, and might change overtime at Apple's decision
You can refer to appearance sample application.
The property indicates if the window should reflect the document as "edited" (true) or not (false).
In systems other than macOS, a change in a document is typically indicated by adding asterisk character to the end of the window caption.
macOS provides a special UI behavior in this case.
The unit provides additional macOS UI utilities.
The function shows a simple user dialog as a sheet (sheets are modal to a window, not to the entire application). Does nothing on any other platform. (todo - it's possible to implement it as modal forms). Parameters are similar (while not identical) to PromptUser function:
- DialogCaption: string
- DialogMessage: string
- DialogType - type of the dialog. idDialogXXX (declared at LCLType)
- Buttons - array of button types that should be shown (refer to idButtonXXX list at LCLType)
- DefaultIndex - default button index
- AParentForm: TCustomForm - a form where the sheet should be shown
To be Implemented
- NSToolbar support - TToolbar doesn't correspond to macOS UI guidelines