It’s really great there is such a template in iOS would love to see it for desktop too.
But it seems to me (correct me if I’m wrong) the inspector behavior properties get read too late. They are available in the open event, but this is after the CreateView event was fired so they cannot be read in time for object creation.
I’ve set up a dummy class here that breaks during CreateView and Open Event of an instance creation and tries to read its properties: https://dl.dropboxusercontent.com/u/21200221/Xojo/iosobjectTest.xojo_xml_project.zip
If you can confirm I’d publish a bug report or is one already done for this issue (if it is one)?
I encountered the same problem when I was implementing a few controls like the UIStepper. If you are trying to work with bounds sizes for an initWithFrame or similar auto layout will override any size that you make the control anyway. How exactly are you trying to use the inspector properties in CreateView?
I like the fact that I don’t have to care for the constraints of the added view.
I encountered the problem when I was playing with an UIVisualEffectView class for iOS, created as an iOSUserControl subclass. There’s two properties I have to read BlurType and EffectType but cannot address in the event so I always come out with standard values a Blur Effect in Light only
Ah, I can definitely see why this is a problem. I never created a feedback report because, like you, I wasn’t sure if this might be intended behavior. I wonder if an event could be raised to get the desired values from the CreateView event? That would be a work around for the problem.
Can’t edit.
It seems that an event cannot be raised from inside of the CreateView event, so no workaround like this is possible. I think you have two options for this case: to create a different class for each blur style, or to make a shared property which you can set in app.Open and read in the CreateView event. Of course this will bring about its own problems.
Thanks for your reply, Jason!
I think I’ll chose the third way first: Creating a bug report. UserControls are not half as useful if we cannot address the inspector choices. This isn’t true for everything: The name property is correct in the event. So I hope it won’t be that much for the engineers to move the init methods.
I agree that a bug report is the best option. It is indeed weird that the name property is correct. I’m worried that your case may be closed by design, however, since the CreateView event is called from the constructor and inspector properties have never been available in the constructor of any classes I have written, if I remember correctly.
During Alpha and Beta of 2014r3, I had a few bug reports successfully handled which addressed Inspector properties, especially custom enumerations, so they are working now in desktop projects like intended, as far as I can tell.
And we never had an UserControl object made for easy declares which would be very restricted in its use if we couldn’t read the properties. Let’s just see
Just FYI this is roughly the same issue as trying to create a control with a constructor on the desktop
The sequence of code that is run to create an instance of your subclass on the view is
call constructor // your properties will exist but are initialized to default values for the property type)
-> which ends up calling create view
add control to view
set instance properties // your properties will be initialized to the value you set in the inspector
So your properties exist, but they dont have the values set in the inspector.
At this point in time there’s no opportunity to do otherwise.
HOWEVER, we are making some other changes that may make it possible to do this differently for iOS and desktop controls.
We’re not done with it yet though.
See cases 12014 and 12337
I’m sure there are others
Thanks, Norman! Good to know you are aware of it.
I think there is another problem (but cannot assure yoI made no error):
I subclassed my effectViews now, and they are working. I can subclass the Blurviews too to show a UIVibrancyView. But when the latter tries to add views placed on it in its contentView during its open event, it looks as if he children wouldn’t be there:
I placed an IOSLabel on one of the VibrancyViews and added an
Sub Open()
dim mycount as integer = ControlCount
dim myptr as ptr = contentView
for q as integer = 0 to ControlCount -1
dim myhandle as ptr = me.control(q).handle
iOSControlExtension.addSubview me.contentView, me.Control(q).handle
next
End Sub
to the parent class (the unused properties just for debugging).
But no matter if I place anything on the VibrancyView or not, ControlCount always gives me 0 children. The same if I call this method later. Shouldn’t ControlCount forward the number of iOSControls on an instance of a UserControl subclass?