Settings in "DesktopDateTimePicker.defaults" beeing ignored

I’ve created a DesktopDateTimePicker.defaults file within my Documents/Xojo/Overrides Folder with the following Settings:

Width=102
DisplayMode=1
TodayButtonCaption="Heute"
GraphicalDisplay=True
DisplaySeconds=False

Except the Width=102 Setting, every other Setting is beeing ignored.
What am i doing wrong here, please?

Edit 1:
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.

Edit 2:
Forget what i wrote in Edit 1. If i deselect a CustomDateTimePicker and select it again, it’s back to Xojo default values. :frowning:

#Xojo2022R3.1
#Docs:Setting default values for Xojo framework Class properties — Xojo documentation
#Issue: https://tracker.xojo.com/xojoinc/xojo/-/issues/70721

Never learned about it and already hate it as a half designed feature. :smiley:

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.

Please, Xojo, rethink this feature. @Geoff_Perlman

And that’s EXACTLY what i need :wink:

IIRC this functionality was very broken before I left.

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.

You should make your idea a functional suggestion, but not tell me what I think… :wink:

1 Like

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.

By the way, it should be removed from the docs until designed, implemented, tested, and approved. Then documented and released.

It only affects new controls added to the project. It will not change the settings of the project received from someone or the defaults of controls already set on old projects.

As far as I know, only a limited set of settings can be changed, like height/width.

The DateTimePicker is newer than this feature, maybe Xojo can do something to allow more settings to be changed.

That’s not the concept of “Overriding” values, that the concept of “Default values”. Overriding class values would change all those classes to a new standard at load time.

Well Xojo is overriding the default values.

I use this to have my WebPage default to a different height/width than what Xojo use.

1 Like

And when you save it, the intended values are set in the project, and once your project is sent to someone using different settings, are your values kept as you intended there?

Based on conversation with Alberto, better <Platform> instead of <OS>, so right now we identified windows, macos, linux and web as supported target platforms.

By now it’s pretty clear that you expect a different kind of “Default Settings Feature”. That’s why I would like to advise again to create a function request for this. :slight_smile:

I am trying to use a function as described in the instructions. Because that’s exactly how I want to use it. I didn’t expect it to work differently, I just expected it to work as described. :wink:

1 Like

I just want to know if the current behavior breaks projects. If it breaks, it’s not a question of you or me liking or expecting anything.

No, it’s not. Because as @AlbertoD already wrote:

What’s the answer for this?

Values are kept; because:

Controls already used in the Project, keep their values. New Controls added to such a Project have the default values of the IDE they are created with.

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.

1 Like

No, it doesn’t break projects.

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.

Hope this helps.

1 Like

Ok. :+1:t2: