Im new to Xojo and love it! I have been a database developer for 30 years (mostly Visual FoxPro). In FoxPro, I would subclass just about every control (label, textbook, etc.) and create my own customized controls with different fonts (or any number of other properties), as well as methods (validation, behaviours, etc). When you used those customized controls in forms, youd see their customized properties at design-time. WYSIWYG at design-time and runtime.
I can subclass the label object in Xojo and set a different font, or make it bold, but only using code in the Open event handler. The main problem is this - when I drag the subclassed label to a window, it does not show those customized properties at design-time, in the IDE. This can present a challenge if I want to arrange my subclassed objects based on fonts I have chosen and alignment issues occur because what I see in the IDE is different than whats displayed at runtime.
when you create a new class that is a subclass of an existing control (or even a class from scratch)
the properties you want to appear in the IDE need to be computed properties
then RIGHT click on the new class in the Navigator (left side panel) and select INSPECTOR behaviour, there you can make properties visible as well as set default value…
Dave - thank you for your response! I actually did make the changes in Inspector Behaviour as you described, but those changes did not propagate to existing labels that were dropped onto the window. In other words, it seems to only have an effect when the customized class is subsequently dropped onto a window.
For example, lets say I want to have a custom label class that is bold - lets call it lblHeader. I go into the Inspector Behaviour and change Bold to True. I drag that object onto the window and it displays in bold, as expected. However, lets say I want that label control to also be italicized. I change the custom class and set Italic to True. The existing lblHeader object on the window is not italicized.
My goal is to subclass most of the Xojo controls, make them external and share them among various projects, and ensure changes I make to fonts and properties in Inspector Behaviour cascade across all of my projects.
This is a true statement… you must complete the subclass design before those will appear.
Personally I think you are going to be exerting more effort that benefit obtained…
And you do not CHANGE a control by manipulating the Inspector Behaviour, you use that to SET THE DEFAULT, then when you drag your custom control to your project, you can change those defaults in the Property Inspector (RIGHT panel)… The idea is create you subclass control, use Inspector Behaviour to set the default values, and then you would probably never touch Inspector behaviour again.
You realize that Bold and Italic are infact font properties you can set on labels, textfields etc already
I appreciate your opinions/facts/perspective. I just needed to know Xojos methodology. Im not sure if Xojo honours OO principles or not in this case. I only know that FoxPro handled inheritance differently and I preferred their approach. IMO, if you want to subclass a button or label to look a certain way (say with green text) and you drop that onto a number of windows in a project, and the client changes his mind and prefers red text, I should be able to change that in one place - the subclassed object. To me, that is desirable behaviour. In FoxPro, you could override any property in subclasses. For example, lets say I want a subclassed button to look a certain way and I drop that button 10 different places, but if there are customizations I want to make to a few of those buttons, I simply override a property (say font colour) on two individual buttons on a form.
I like that I can change the DEFAULT properties of a subclassed object - I just wish that we could at least change the default at a later time and have the option to propagate that change to objects based on that class everywhere in the project.
Im so excited about diving into Xojo and there is so much you can do with it, and more than I could do in FoxPro. I do think that inheritance of properties in subclassed objects should be implemented differently, but I suppose thats a debate that I cant win if Xojo has fundamentally designed their product this way.
If you drop an instance of a class onto a window then it keeps the properties that it has AT THAT MOMENT even if you change the property value in the class.
If you ADD a new integer property prop and give it a default value of 1 then ALL the instances - even the ones you dropped onto the window BEFORE you added the property - have that property with a default value of 1. (as expected).
If you change the value of prop in the class to 2 and drop a new instance onto the window then it still has a value of 1, as do the existing ones (unexpected)
If you change the value of prop in the inspector behaviour to 3 and drop a new instance onto the window then it has a prop value of 3, but the existing ones still have a value of 1.
[quote=386050:@Markus Winter]I would actually think that is a bug.
If you drop an instance of a class onto a window then it keeps the properties that it has AT THAT MOMENT even if you change the property value in the class.
If you ADD a new integer property prop and give it a default value of 1 then ALL the instances - even the ones you dropped onto the window BEFORE you added the property - have that property with a default value of 1. (as expected).
If you change the value of prop in the class to 2 and drop a new instance onto the window then it still has a value of 1, as do the existing ones (unexpected)
If you change the value of prop in the inspector behaviour to 3 and drop a new instance onto the window then it has a prop value of 3, but the existing ones still have a value of 1.
Seems somewhat borked to me.[/quote]
Blindly updating the properties for existing objects could cause lots of problems. How would the IDE know that it was safe to update the existing objects?
If one of the existing objects had the original default value and that is the value you want to retain after changing the default, it would get overwritten with the new value. I guess it could help if the IDE provided some type of update feature to replace the default values for existing objects (maybe with an option for all objects or objects that were the old default) but even then it could be very dangerous.
Nobody is blindly updating anything. If you have a control with a default value of 1 and you think it would make much more sense for that control to have a default value of 3 then you are not doing this blindly.
I really hate these pseudo-arguments which only aim to denigrate the other opinion.
As for dangerous, the current behaviour of having identical controls with different default values seems much less consistent and therefore more dangerous to me.
I have a library of subclassed Xojo controls I include in each project, and then instantiate only those. I agree the Inspector and control defaults are confusing. Where I want to globally change something, say the textfield.textcolor property, I just explicitly set it in code in the class’ Open event. One simple change. (Actually I have all the controls set the colour to a constant, so it’s an even easier change.)
I originally started this library to deal with visual differences in the various OS’s. It’s been added to over time, adding data handling interfaces, event notifications, custom outputs, preference handling, etc. Couldn’t live without it now.
As I have been able to see, only the plugins can change their apparence in the IDE. all other subclasses appear as the top superclass.
may be this will change when xojo will be able to compile it’s own plugins, as it has been announced … last year ?
I understand and appreciate what you and others are saying in this thread, but I still take exception with how this works because you won’t see the colour change in the IDE. I’d think developers would want to see what their subclassed objects are going to look like at design-time without having to code customizations that affect appearance in the Open event. I guess my main issue with coding changes to properties that affect appearance in the Open event is that those changes may affect positioning or change other attributes that might make where these objects end up on the window unpredictable at runtime.
Bottom line - this is how Xojo works and I will obviously work within the confines of its structure/design. Hopefully there will be some refinements to the design so that these subclassed properties that affect appearance can be applied in one place and cascade throughout the project UNLESS there’s an override to the property.
THANKS to everyone who commented on my post and helped me understand how this part of Xojo works. You guys are wonderful!