REALGetControlBounds of a MobileControl reports the correct width and height, i.e.,the right and bottom values. Meaning that left and top always return zero. This makes it almost impossible to display the control on the MobileScreen in design time. Is there any trick? Feedback?
Actually, it does not work at all. It reports the hard-coded default width and height.
I have not done mobile control but I image you can get its handle and from that you can get the size of the view then.
REALGetControlBounds is the feedback from where the user drops an instance. Getting the view from the handle does not give the feedback you need to place it correctly into the rectangle. Also dynamic access does not work, it causes Xojo to hang. It stalls at its call to REALobjectIsA. Seems like you can only use the REALgraphics to draw some “silly” picture. Haven’t tried that. Since we get a valid CGContextRef you can adjust the width and height, but the translation that is necessary is not possible. You can do something like this:
[transform translateXBy:512-contextWidth yBy:256-contextHeight];
to get the view in the middle of the scrollable IDE layout window. It does not move with the screen instance.
I am not sure if the lack of getting the bounds is intentional. I guess it is not, and it feels like going back to the nineties, yikes.
I reported a similar issue as 63112 since my control didn’t redraw in right size.
Please take a look at the EyeControl project that’s included as a Plugins SDK example. It has a mobile part, which you will need to enable in the EyeControlPlugin.cpp. The example does utilize REALGetControlBounds and seems to be working in that particular example so we’d like to know what your difference/expectations are here. Of course if you could attach an example to your Feedback ticket, that would also help us as well.
I checked, thanks. For both controls the example draws with the REALgraphics instance, so it is Xojo drawing in the REALgraphics. That graphics is zero based, i.e., it is in terms of a frame not the bounds. We know that the graphics height and width change with resizing.
The code:
| REALSetPropValueColor((REALobject)context, “DrawingColor”, 0); | |
|---|---|
| FillOval(context, r.left, r.top, oneEyeWidth, height); | |
| FillOval(context, r.left + oneEyeWidth, r.top, oneEyeWidth, height); |
uses the r.left and r.top obtained from REALGetControlBounds, which always remain zero. The example uses the width and height from the REALgraphics, so it obscures the constant non changing values of the bottom and right field-values of the REALGetControlBounds.
We use the handle of the REALgraphics (handle(5)) to obtain the CGContextRef to draw. That is zero based too. The view associated with the CGContextRef requires the bounds, not the frame, causing a fixed position. And you could easily test the fields of the rect obtained from REALGetControlBounds in your example. They don’t change, really!
The screenshot attached to the feedback report shows the control fixed by hard-coding the left (512) and top (256) of the view and does not change position, while the screen1 instance moves when scrolling.
I didn’t see a notable difference between the project and our code.
Actually, it does not utilize it. The behavior function is EyePaint and not EyePaintOffscreen. Xcode also tells me that EyePaintOffscreen is an unused function. EyePaintOffscreen is the only function that calls REALGetControlBounds and therefore you did not notice.
The bug is still that REALGetControlBounds is broken.
I just saw they query width/height of the graphics context. This is new to me, but I can at least use that workaround for the plugins.
Yup. It is an example of Xojo drawing in the plugin. But if you want to host an existing ObjC view (or a custom view of your liking) then you need the same MacOSX-REALcontrol functionality. As I said, we are in for a long haul, unfortunately. Also, dynamic access to a Mobile control using the REALGetPropValueDouble on the mobile control instance returns 0.00000 for left, top, width and height. So I guess supports the long haul notion. Probably related to Parent.left and Parent.top. Have no idea to access that.
Dynamic access has been our preferred method for obtaining these values for quite some time now. While it’s true that REALGetControlBounds isn’t working, you should be able to obtain the bounds via dynamic access assuming you are retrieving the correct property and type:
RBInteger w, h;
REALGetPropValueInteger(control, "Width", &w);
REALGetPropValueInteger(control, "Height", &h);
Does that even work in the IDE design mode ?? Let us remember that dynamic access to Enabled does not work when in IDE design mode.
It does.
I’ll have to take a closer look at that one, hopefully you’ve already filed a Feedback case about it?
Why do you use integer here and Eye control example uses double there?
Because the Graphics Width/Height is a Double, but the Control Width/Height is an Integer.
Oh, seems like I missed that detail.
But that signature crashed on me. The integer signature
Yes there is old feedback:
63406 - REALGetPropValueBoolean((REALobject)instance, “Enabled”, &enabled) does not work in IDE mode