Except the Width=102 Setting, every other Setting is beeing ignored.
What am i doing wrong here, please?
But if i drag a DateTimePicker into the Navigator to create a CustomDateTimePicker, it respects my default Settings. This is not what i expected.
I expected that ALL new DateTimePickers i add, would respect my defaults.
Forget what i wrote in Edit 1. If i deselect a CustomDateTimePicker and select it again, it’s back to Xojo default values.
Never learned about it and already hate it as a half designed feature.
It overrides Classes GLOBALLY, that means it breaks other projects that you don’t want such behavior, e.g. a sample someone sent you will behave wrongly.
Better have it PER PROJECT, like having a folder called “classes_overrides” near to the project file, AND definition files PER TARGET. Files as <ClassName>.defaults for ANY OS, or <ClassName>_<OS>.defaults where <OS> could be windows, macos, linux (lowercase in case sensitive file systems). <ClassName>.defaults overrides the hardcoded defaults, and <ClassName>_<OS>.defaults overrides both hardcoded and the “any OS” override.
So a project carries its settings with it when you zip its files and sub-folders containing other resources, and does not produce side effects in other projects.
You think you need this way, but this way is totally wrong.
Xojo could create a setting pointing to a folder where classes overrides could be found. Default to “./classes_overrides” but you could change it to whatever as “~/Documents/Xojo_classes_overrides” (such value and few others could be ready in a combobox to be easily changed for such cases) and have a checkbox nearby “Set as default for new projects”.
Then if you choose “Collect Project items”, Xojo would create the “classes_overrides” folder near to the project, and copy the settings found there (if any, and not the being already the local “./classes_overrides”) to the project settings, now fixed and ready to be exported correctly.
Tell you what you think would be redundant, I was just clarifying a possible way to make the broken feature you brought to table (thank you for that), that should never exist in the current incomplete and bad form, a functional one.
I hope so. I was expecting the values being overridden affecting instances using default values so you could change in one spot per platform and the project would behave as you wished for such platform without the need to adjust one by one, and that override being transported with the project. If it’s not, it’s just a question of better documentation and fixing the possible glitches you found.
Is only a feature that helps you add controls to your project with different defaults than the Xojo defaults. For example: the default Window width/height in Xojo is 600x400 but maybe you always resize that to 800x600, you then set the override to 800x600 and all new windows added to a project will be 800x600. If you change a window to 1024x768 it will be saved as that and will not save the override to the project in any way.