Difference between revisions of "Cocoa Internals/Extensions"
From Lazarus wiki
Jump to navigationJump to searchLine 44: | Line 44: | ||
|Returns true if the instance of the class can be considered a LCL handle | |Returns true if the instance of the class can be considered a LCL handle | ||
|false | |false | ||
− | | | + | | |
|} | |} | ||
Revision as of 19:30, 23 December 2017
Extensions are used to add additional lcl-friendly methods to all Cocoa classes. The default implementation of each method should:
- either indicate that a class is not a LCL-specific class (it's Cocoa native) thus should be handled with care
- provide a basic functionality for LCL types (for example setting a control bounds using TRect type. Where cocoa is using float-point NSRect)
Extensions
LCLObjectExtension
The extensions adds additional methods to NSObject class of cocoa. (This is TObject counterpart, where (almost) all classes in Cocoa inherit from).
A lot of the methods below are control specific methods, thus it might be a good idea to elevate the extension from NSObject to NSView or NSControl. However, this might impact other control-like objects (i.w. NSWindow?)
LCLObjectExtensions methods are:
Method | Description | Default behavior | |
---|---|---|---|
LCLObjectExtension | LCLViewExtensions | ||
lclIsEnabled | Returns true/false if control is enabled | false | |
lclSetEnable | Enables or disables the control | does nothing | |
lclisVisible | Returns true/false if control is visible | false | not hidden() |
lclSetVisible | shows or hides a control | does nothing | setHidden() (where is the method in the documentation? deprecated?) |
lclisHandle | Returns true if the instance of the class can be considered a LCL handle | false |
Convention
- All lcl extension methods should start with "lcl" to distinguish them Cocoa native methods.