UI/ini inconsistencies with CustomSeparators

[funkymonk]

Hello!

In TC's configuration dialog (Tabstops/Data Formats), one can define four different separators (for date, time, thousands, decimal) via drop down menus. For each one, there is a <default> and some "common" options. In addition one can also specify an arbitrary character by just typing it.

Inconsistency 1 (dialog / file list):
When entering such an arbitrary character, Apply will keep that character visible in the dropdown menu but still use the <default> in the file list.

Inconsistency 2 (UI / ini):
When changing the CustomSeparators in the ini file, any character is accepted and finally used in the file list.

--> Suggestion: Since TC obviously accepts any character when specified via CustomSeparators (ini), the config dialog should not make limitations here (especially since the dropdown menus do allow to enter arbitrary characters).
[If this limitation in the config dialog is intended by the author, there should be no option to enter arbitrary values at all.]

[ghisler(Author)]

1 that's how comboboxes work. They have a listbox part for fixed values, and an edit box part for values entered by the user. There are comboboxes where the edit box is read only, like the drive dropdown list. But in general, when you enter something by hand, it doesn't magically appear in the listbox part. You can see this for example in the command line of Total Commander: When you enter a command and then open the dropdown list, the command isn't there. Total Commander only adds it by itself when you execute the command.

2. There is no difference to 1. The custom separator doesn't appear in the list, it just shows up in the edit part.

[funkymonk]

That's not what I have meant.
How comboboxes work is one thing. How the data is further processed is a different thing.

Here is an example:

1) Open the config dialog
2) For the date separator, enter an arbitrary char that is not listed anyways. E.g., "a"
3) Press Apply.
--> The combobox still shows "a" but the file list switches to the default char --> Inconsistency.

Or this one:

1) Put CustomSeparators=a:', into the ini file
2) restart TC
--> TC uses "a" as a separator --> Correct
3) Open the config dialog
--> The combobox shows "a" --> Correct
4) Change "a" to "b"
5) Press Apply
--> The combobox still shows "b" but the file list switches to the default char and the ini shows CustomSeparators=0:', --> Inconsistency.

The point is:
If arbitrary chars can be entered, they should also be respected.
If arbitrary chars are not respected, then the combobox should be read only.
Anyway, showing a char in the config dialog (after apply) but using another one in the file list and the ini is certainly an inconsistency.

[ghisler(Author)]

I see - currently A-Z, a-z and 0-9 are filtered out in the dialog only to prevent the user from doing stupid changes. Experts can still set CustomSeparators=a if they really want that.

I will revert the displayed value to <Default> when the user clicks on Apply and one of the filtered characters was entered.

[funkymonk]

I will revert the displayed value to <Default> when the user clicks on Apply and one of the filtered characters was entered.

Sounds good. At least it's consistent then.

Though I don't see why exactly these chars are considered "stupid" (2022ß06ß01 also looks a bit "stupid").
And why are other seemingly stupid things (like starting the deletion of the windows directory) not prevented? (Ok, I haven't tried, but I guess it's not prevented by TC. And no, I don't want to discuss this. )


[@ghisler only: Vielleicht wäre es gut, solche Dinge nur Mathematikern zu erlauben, den Laien aber nicht ]

[ghisler(Author)]

Please try with beta 8.

[funkymonk]

Works with 10.50RC1 x32 @ Win10x64.

TC returns to <default> when applying a non-supported separator.

Suggestion: Maybe it's more intuitive/convenient to return to the previously active separator...?

[ghisler(Author)]

Thanks for confirming the fix! I prefer to switch to <default> because the long text is more obvious to the user that it was changed.

Moderator message

Moved to fixed bugs