Difference between revisions of "Cocoa Internals/Widgetset"

From Lazarus wiki
Jump to navigationJump to search
(Created page with "==Handles== THANDLE - an opaque reference value that's being generated during .CreateHandle() call of a particular Widgetset class. THANDLE is the value that's used to interfa...")
 
Line 14: Line 14:
 
* if bounds changes are required (moving, resizing) then the sizes are changed directly for the NSView referenced by HANDLE. (It's assumed that the view would automatically resize its controls. In case of TMemo, NSScrollView would adjust size of NSTextView, if wordwrapping is off).
 
* if bounds changes are required (moving, resizing) then the sizes are changed directly for the NSView referenced by HANDLE. (It's assumed that the view would automatically resize its controls. In case of TMemo, NSScrollView would adjust size of NSTextView, if wordwrapping is off).
 
* Forms (TForm), that generally correspond to NSWindow, also return its handle as NSView. That view represents the root NSView of a form. However, CocoaWS API's know that and are calling necessary NSWindow methods where applicable.
 
* Forms (TForm), that generally correspond to NSWindow, also return its handle as NSView. That view represents the root NSView of a form. However, CocoaWS API's know that and are calling necessary NSWindow methods where applicable.
 +
 +
===Focusing===
 +
That has important impact of FOCUS-ing. Cocoa doesn't operate the term "focused" instead it's using terms "firstRepsonder" and "key" view/window. Generally focused control corresponds to Cocoa's "firstResponder". The NSResponder object (typically NSView) is the first object that would handle key or mouse events.
 +
However, this is not the case for composed controls. TMemo is a combination of NSScrollView and NSTextField. NSScrollView is used as a handle. If, NSTextField would be the firstRepsonder, CocoaWS needs to return NSScrollView as focused HANDLE.
  
 
[[Category:Cocoa]]
 
[[Category:Cocoa]]

Revision as of 20:18, 23 October 2018

Handles

THANDLE - an opaque reference value that's being generated during .CreateHandle() call of a particular Widgetset class. THANDLE is the value that's used to interface with a control. Using the value a widgetset recognizes a particular control.

Most of Widget interface methods are accepting TWinControl as a parameter. It's assumed that Handle property of the control would be used to back reference the actual control. The property stores the value received from CreateHandle() call made earlier. HandleAllocated property can be checked in order to know, if handle has been previously created or not. If handle was not created it's expected that the method can fail (returning the proper failure information. Exceptions are not expected?).

Overall LCL Handles refer to a complex controls. For example HANDLE can refer to a Memo control, that's capable of editing AND scrolling text as needed.

Cocoa's composite engine operates controls on a lower level scope. With MEMO example, there's not a single control that does both: text editing and scrolling.

Instead there are two separate controls: NSTextView and NSScrollView. (Both are descendant of NSView). But LCL expects only 1 value to be returned as a handle.

The common rule is the following: the outter bounds (aka container) control is returned as the handle. Thus in case of Memo, two NSViews are allocated: NSTextView and NSScrollView. But the outter NSScrollView is returned as HANDLE. All TCustomMemoWSControl methods are aware of that and treat handle as such. For example:

  • if paste action is required, the handle would be used as NSScrollView and then it's documentview would be used to get NSTextView to call for paste.
  • if bounds changes are required (moving, resizing) then the sizes are changed directly for the NSView referenced by HANDLE. (It's assumed that the view would automatically resize its controls. In case of TMemo, NSScrollView would adjust size of NSTextView, if wordwrapping is off).
  • Forms (TForm), that generally correspond to NSWindow, also return its handle as NSView. That view represents the root NSView of a form. However, CocoaWS API's know that and are calling necessary NSWindow methods where applicable.

Focusing

That has important impact of FOCUS-ing. Cocoa doesn't operate the term "focused" instead it's using terms "firstRepsonder" and "key" view/window. Generally focused control corresponds to Cocoa's "firstResponder". The NSResponder object (typically NSView) is the first object that would handle key or mouse events. However, this is not the case for composed controls. TMemo is a combination of NSScrollView and NSTextField. NSScrollView is used as a handle. If, NSTextField would be the firstRepsonder, CocoaWS needs to return NSScrollView as focused HANDLE.