Issue with ImageView

I just downloaded 2015r1 and opened my iOS project. My apps main GUI no longer works. In 2015r1 it appears that controls sitting on top of imageviews no longer work. If I move the controls off of the imageview control they start to work again.

This is easy to reproduce by creating a new iOS project. Drag on a imageview. Then drag another control such as a iOSSwitch control on to the imageview. Run the app. The switch will not respond. In prior version the switch worked as expected.

Is there a new setting for imageview that I need to turn on in order to get controls to work again?

@Michel Bujardet came up with this solution:

I’ve already tried moving the controls until they stop being a child of the imageview and then moving them back, but that hasn’t worked. None of my controls have an h.center setting, before or after moving them, so I can’t remove that offset.

You can add the HCenter auto layout guide if you click on the little plus at the bottom left of the auto layout portion of the inspector for the control.

So I clicked the + and added an HCenter. But no matter what I try I cannot get the button to respond. I did get the button to respond if I leave the button mostly off the screen. But that isn’t really an option. After adding the hcenter, I am not able to get the placement to be the same in the IDE and the iOS simulator. The button will look like its in the right place in the IDE but it will be wrong, or even off the screen in the simulator. Under no circumstance can I get the button to respond if it is completely on the imageview.

The button being a child of the image view causes this
You can tell if its a child if moving the button there’s a red ring on the image view

feedback://showreport?report_id=37969

I reported this yesterday also (oops) feedback://showreport?report_id=38218

In the classic framework, I’d have done a me.parent = nil in the open event of the control but unlike RectControl, iOSControl’s parent property is read-only.

Right - closed as a duplicate of the one I posted :stuck_out_tongue:

Right - making it so the button is NOT a child of the imageview is key here
I posted a workaround in the case I noted - but its a bit of a pain :frowning:
We’re still investigating

[quote=168820:@Norman Palardy]Right - making it so the button is NOT a child of the imageview is key here
I posted a workaround in the case I noted - but its a bit of a pain :([/quote]

Unfortunately I couldn’t get the workaround to work - I had three buttons laid in a vertical fashion on top of an ImageView and I just couldn’t get it working while keeping autolayout happy.

I’ve a related question - if you were to create a hideous UI by placing a button on top of a textarea, you’d see that (just like the ImageView), but the button’s events and tapping are ignored. Until you bring keyboard up and then resign first responder - then the button works. Can you explain why that is? Purely out of curiosity.

sounds like a bug as far as what should be the first responder when the layout is first presented

we’ll have a look but please add this information to the case as that may be VERY relevant

The only way I found to rest buttons on top of a canvas or imageview without making it parent is to set the buttons frankly out of the view, yet vertically set, then patiently use constraints to bring the button relative to the canvas. When moved only through constraints, the button does not become child. But it is neither intuitive, nor convenient.

I would really like being able to set Parent=Nil, as we do in Desktop. I know the new framework is here to prevent us from shooting ourselves in the foot, but this read only parent business looks like an undue prison. The proper alternative if rendering Parent modifiable is out of question, is that controls should not become parent so easily. Maybe they should not become parent, unless one holds shift while dragging the control over ?

[quote=168825:@Norman Palardy]sounds like a bug as far as what should be the first responder when the layout is first presented

we’ll have a look but please add this information to the case as that may be VERY relevant[/quote]
Done.

I really like this idea (although I’d argue that the default should be that the containing control does become parent by default whilst holding a modifier key while dragging makes it not be parent).

I agree

Actually it looks like the ONLY control we SHOULD allow parenting on in the IDE is a Canvas and NOTHING else

Still need to verify that this fixes things but that certainly seems to be the right behavior when checking in Xcode & at runtime

If Canvas could be like desktop a real container, including scroll, that would really be awesome. And indeed, I do not see why other controls should be parents.

Being able to set Parent as nil would be nice, though.

[quote=169524:@Norman Palardy]Actually it looks like the ONLY control we SHOULD allow parenting on in the IDE is a Canvas and NOTHING else

Still need to verify that this fixes things but that certainly seems to be the right behavior when checking in Xcode & at runtime[/quote]

Indeed HTMLViewer for instance should not be parent. It would be nice if Canvas could serve as a container as it does in Desktop and allow scrolling as well.

Same thing for iOSTable : if one could simply stick buttons and stuff over it, that would be great. But I am probably dreaming :wink:

[quote=169524:@Norman Palardy]Actually it looks like the ONLY control we SHOULD allow parenting on in the IDE is a Canvas and NOTHING else

Still need to verify that this fixes things but that certainly seems to be the right behavior when checking in Xcode & at runtime[/quote]
Not sure what you mean. See https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIView_Class/index.html where it says “Views can embed other views and create sophisticated visual hierarchies. This creates a parent-child relationship between the view being embedded (known as the subview) and the parent view doing the embedding (known as the superview).” Views don’t have the same meaning as in Xojo of course, they’re pretty much any containing control.

In a quick text I dropped a UIButton on a UIImageView in Xcode. The button knew that its parent (or superview property in Objective-C terminology) was the UIImageView. And it responded properly when tapped etc.

Right
Not sure if we’re embedding them incorrectly or what
Still looking into whats wrong as its not immediately obvious

You described very well container controls. I was kind of dismayed that this very important feature of iOS was not present in Xojo. I filed a feature request feedback://showreport?report_id=36587 to that effect, and hope it will be coming.

One workaround to ‘unparent’ a control that worked for me was to delete the parent control then undo the delete right away. It feels more like a ‘feature’ than a fix and I would’t want to depend on it but it worked on one layout that had pathological problems without having to rebuild it from scratch.