The auto layout to which the plugin is exposed drives me nuts. For example, when launching the build on the iPhone, the initial hard-coded size of the REALmobileControl (266,133) is maintained during construction and initialization of the plugin. First we get the following messages in the console:
PluginEntry of the Lexing plugin
InstallMobilePlugin called for the LexingControl Plugin
Registering of the color classes
Creating service facility connection with <private>
Activating service facility
Creating iPhone screen: iPhoneLayout
Then follows the construction callback of the plugin:
Service facility connection activation received.
Got dynamically the App_App
com.vanhoekplugins "Mobile Application"
Lexing_Construct Callback: instance = 3d16b80
in Lexing_InitProperties
out Lexing_InitProperties
in Lexing_EditorConstructor
leaving Lexing_EditorConstructor
leaving Lexing_Construct Callback: instance = 3d16b80
Init properties sets the default properties of the plugin and is followed by the creation of the subclassed UIView, which is called the editor. The editor functions as a superView that has embedded the UIScrollView containing the contentView. The plugin implements the handle getter
LexingIOS Lexing_HandleGetter: handle (3e0c9c0)
So now the plugin depends on what Xojo is going to do. Xojo starts with calling the OpeningEvent that the plugin has subclassed. Note that Xojo will call this event twice, which as far as I can tell is a bug: see <https://xojo.com/issue/64201>. We circumvent that by a counter. This event is used to implement a ViewController like:
#if XOJO_TARGET_IOS
@interface ViewController ()
{
BOOL keyboardShown;
CGSize keyboardSize;
CGSize offset;
UIDeviceOrientation orientationAtShown;
@public
ScintillaView *editor;
REALmobileControl *mobileControl;
REALcontrolInstance mobileInstance;
}
@end
In the subclassed OpenEvent we call this:
void initViewController(REALcontrolInstance me, REALmobileControl *mc, ScintillaView *editor) {
ViewController *controller = [[ViewController alloc] initWithNibName:nil bundle:nil];
if(controller) {
controller->mobileInstance = me;
controller->mobileControl = mc;
Data(me, data);
data->controller = controller;
controller->editor = editor;
[controller loadView];
// [controller viewDidLoad];
}
NSLog(@"leaving initViewController");
}
So the messages in the console become
counter = 1 of the Lexing_OpenEvent 1
loadView
leaving initViewController
REALGetControlBounds in origin and size: {{0, 0}, {266, 133}}
OpenEvent does not trigger -Open
leaving Lexing_OpenEvent
Lexing_SetText
After the call to the subclassed OpenEvent you should note that the setter properties of the plugin are being called by Xojo (not by the plugin). One such a setter is the Lexing_SetText. This Text property of the plugin was assigned with a long text in the IDE inspector pane. Note that load view is just doing:
- (void)loadView {
NSLog(@"ViewController: loadView");
[super loadView];
self.view = editor;
editor.scrollView.keyboardDismissMode =UIScrollViewKeyboardDismissModeInteractive;// UIScrollViewKeyboardDismissModeOnDrag;
editor.scrollView.automaticallyAdjustsScrollIndicatorInsets = YES;
}
and also implements
- (void)updateViewConstraints {
NSLog(@"updateViewConstraints");
[super updateViewConstraints];
[self interrogatedimensions];
}
“interrogatedimensions” simply spits out
updateViewConstraints
editor.hasAmbiguousLayout 0
[self.view bounds] {{0, 0}, {266, 133}}
[self.view frame] {{0, 0}, {266, 133}}
REALGetControlBounds {{0, 0}, {266, 133}}
count of layoutGuides = 0
editor.scrollView.contentOffset {0, 0}
editor.scrollView.contentSize {100, 218}
editor.scrollView.visibleSize {100, 10}
This still indicates that the updateViewConstraints does not show that text was taken into account, that the actual size of the View is not represented by the size set in the IDE. Only later when layoutViews is being called we get
layoutSubViews
[editor frame] {{54.666666666666657, 206.66666666666663}, {266, 399}}|
editor.scrollView.contentOffset {0, 0}|
editor.scrollView.contentSize {266, 399}|
But, the content view should be larger in size, given the text size. So what is going on? A whole lot because setting up the widget in the IDE is a pain. For example, sometimes you have width, height edging to none, then you also have top and right that can switch to left and bottom (if you drag along), but you cannot set top or right to edge nothing. “Nothing” in the popupmenu of Edge is not present. I want to set the edges to none just to be able to test what’s going on. Going on means that what should be text is completely black or part of it is black.
So my take on it is that without knowing the bounds of the widget in design-time, everything becomes a trial and error without logic. Xojo should provide better tools to let a developer figuring what is going on in how Xojo sets the constraints and how it might affect the 3-layer widget this plugin represents (On macOS everything just looks good). Am about to give up. Isn’t there any good example plugin? EyePlugin does not cut it because it draws with Xojo API’s and therefore does not define a UIView and NSView.
And another problem is when the hard-coded size of the plugin is changed. The change is effective in MacOS (desktop), but it does not affect the mobileControl when in runtime and debug-runtime. Both the REALcontrol and REALmobileControl were changed to 300, 500, but the messages like above (in IOS) gave 266,133. Tried to clear caches, but without avail.
Yikes