Why, when I try to subclass an iOSView do I get the error message above?
Create a new IOS project in the IDE. Add a new view and make View1 its super class. Compile.
Why, when I try to subclass an iOSView do I get the error message above?
Create a new IOS project in the IDE. Add a new view and make View1 its super class. Compile.
what is it you’re trying to accomplish by doing this ?
you definitely cannot inherit UI
I want to be able to add some common properties to a range of views - just like I thought I was able to do in Desktop =- but now find I can’t.
Hm…seems like it would be desirable to do this.
You cant make one window the super class of another either
create a new class that is a subclass of iosView
add your properties there
then make your views subclasses of that
same as you would do for a window that you want a custom super for
That works Norman, but then you’d have to programatically add all your controls too - this iOS thing feels more like Xcode every day - more text than graphics.
I’ve fixed it a different way - using Extends, Assigns and a global dictionary that stores common properties for each of the views. Then I can refer to e.g. dim b as boolean = view1.props.IsDirty and it grabs the value of isDirty for view1 out of a dictionary.
I can now add more properties to all views just by adding a property to the props class.
You’ve never been able to inherit UI in any version of RB / RS / Xojo
This isn’t new to iOS in any way
Making a common superclass that each layout inherits from you can add properties and do not require extends or assigns
You just can’t add any UI to that superclass
(Oh and fwiw this is the same in Xcode too)
No you dont - not sure why you think you would need to
exactly the same as you can do in a desktop app
this seems to me to be exactly what you wanted
[quote=319935:@Norman Palardy]No you dont - not sure why you think you would need to
exactly the same as you can do in a desktop app
this seems to me to be exactly what you wanted[/quote]
you can do the same in a desktop app with Window super classes
Basically you’re inserting your new superclass into the inheritance hierarchy of the Views in your project
Normally the hierarchy is
iosView -> View1
and what we have altered it to is
iosView -> my custom superclass -> View1
You can do this with a LOT of the objects that you add to projects, regardless of project type, and insert a custom superclass
Thanks Norman, that is exactly what I wanted - I just feel like I’ve gone around in a circle today.
So iosView is a class, not a control, on which the View control is based upon. A subtlety I’d not fully appreciated.
I take back my comment about getting more difficult - it was in reference to the thought of having to code in loads of controls - your solution avoids that.
iOS is a different beast since iOSScreen is sort of like a window and iOSViews are sort of a combination of tabs and containers but then again not. If you’ve spent years in desktop and web learning the difference is daunting.
I know I’ve struggled mightily with my first couple of iOS apps just to learn basic functionality. But, once you understand how it works it’s not so bad. There are parts that are harder than it needs to be, IMO, but the forums have been extremely helpful.
I’ve got a project with 13 views that look the same except for the title and have the same controls, differing in the underlying code. It would be nice to inherit the UI controls in case I decide to change them.
For now, I can only option-drag to copy a view and hope I don’t want to change the controls later.
sounds to me like you should have 1 view and a way to alter what code the controls call rather than duplicate the layout just to alter the code
Most of the time I do exactly that, but each of these is a ton of code so I’m trying to keep things understandable.
1 layout
13 implementers of an interface
that still keeps each separate from the others and you dont need to inherit UI or duplicate layouts just to change code
OK, you convinced me. So I can change the view title when I create the view and use Select Case Me.Title in the Activate event handler to select a method for each case?
I wouldn’t even do that
Why not when you create the view use a constructor & pass in the instance of your class that holds the relevant code
Then the view can ask that instance for the title and run whatever methods
The View remains unchanged if you want 1, 10, 100 users of it and you just create instances that implement the interface and off you go
Now you DO need code somewhere that determines which instance to create & pass to this view … that you kind of cant avoid