Cocoa Internals/Extensions

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	true
lclSetEnable	Enables or disables the control	does nothing	traverses child views and passes new enabled status to them
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
lclClientFrame	Returns client rectangle (content of the control) in the control's coordinate system	does nothing
lclFrame	Returns controls position rectangle in the parent's coordinate system	does nothing	frame()
lclContentView	Returns NSView that represents the (drawn) contents. In many NSViews or combination of NSViews the content might be different. For example for NSButton (TButton), the content view is NSButton itself. For NSBox (TGroupBox), the content view is contentView. For a NSTextView sunken in NSScrollView (TMemo) the contentView would be documentView of NSScrollView. Important: lclContentView is also a view where all children controls should be added-to. Important: lclContentView is also a view that should receive focus (become a firstReponder) The problem is that all WidgetAPI calls are made through a control Handle. Handle doesn't always map to a NSView directly (TMemo, TGroupbox) where additional NSViews are in placed. lclContentView is intent to return the view, where the draw methods are called. The method is used by lclInvalidate and lclInvaldateRect. It should be overridden in every composite component to return the actual drawn contents. The alternative to not having this method is to override lclInvalidateRect for each composition control (which is also doable)	nil	returns self

Consideration: if everything is bound to lclContentView. - why is it not used as a Handle anyway? Because Handle needs to match the hierarchy of Cocoa objects. I.e. an actual content residers within a ScrollView. And ScrollView is am immediate child of Form. Not the its contents.

Convention

• All lcl extension methods should start with "lcl" to distinguish them Cocoa native methods.

See Also

• Cocoa Internals