"ShortDate" format is not recognized in Gui.Add options for DateTime controls Topic is solved

[william_ahk]

Code: Select all

MyGui := Gui()
MyGui.Add("DateTime", , "ShortDate")
MyGui.Add("DateTime").SetFormat("ShortDate")
MyGui.Show()

It is only recognized in SetFormat.

[boiler]

The default is ShortDate, so leave it out and it works fine. There is no reason to have it as an option with only the Add for that reason. It’s in the format options for SetFormat in case you want to switch to it from something else. The documentation could be made more clear on this. Moved thread from “Bug Reports” to “Suggestions on Documentation Improvements”.

My suggested change to the DateTime documentation:

From:

The last parameter is a format string, as described in the SetFormat method below.

To:

The last parameter is a format string, as described in the SetFormat method below, except for ShortDate since it is the default and is indicated by leaving the option blank.

[just me]

I think it's a bug if you cannot set the default value explicitely. This thread should be moved back to the "Bug Reports" section.

[boiler]

That hasn’t been the case generally in AHK. As a couple examples, the is no U option in KeyWait, and there is no BGR for v1’s PixelGetColor Mode parameter. But I’ll move it back to Bug Reports so that lexikos is more likely to see it.

[william_ahk]

Well, apparently that is not the same thing because the default option is not "U" or "BGR", and they're not available as options anywhere for these commands.

[boiler]

They are the default state, which is why they don’t need to be available as arguments because they only set the initial state and are never used to change it back, similar to .Add and unlike .SetFormat. That’s why .Add doesn’t need ShortDate but .SetFormat does. The documentation is just misleading in indicating that all the options for .SetFormat are available in .Add, which would be handled by my suggestion.

[william_ahk]

I read the docs again. I think, since the Text parameter of the Add method is Depending on the specified control type, a string, number or an array., and also under the DateTime control type it says The last parameter is a format string, as described below., which is that of SetFormat. It is intended to accept the same format strings. And of course there is practical reason for it to be able set the default option explicitly in cases where the option is to be determined at runtime.

[boiler]

The format string can be determined at runtime to just as easily be left blank if the default option is desired. And .Add would never be called again to later change it back from some other format string. Only .SetFormat would do that.

[william_ahk]

That would work, but it's kinda weird to have blank as a value in the array of options and inconsistent to have the explicit "ShortDate" option available at the same time. I think that was unintended.

[boiler]

You very well could be right, and I’m fine with it being added to it as one of the available options. Just pointing out some parallels to other parts of the language that may be a reason why it is that way. In any case, it is good that you pointed it out because it seems something should change, one way or another.

[joefiesta]

I heartily agree this is a bug.
One thing about writing code is to make it easier to decipher 10 or 20 years after you write it, or when someone else reads it. That one should have to have remembered the default should not be necessary. I believe--and it is true is all other languages I have worked with--that one should ALWAYS be able to code a default.

I've been writing code for 50 years, and I will until I can no longer do so. It is, in a very big way, one's OWN documentation of a line of code.

[boiler]

So is your position that KeyWait also has a bug because “U” isn’t an option even though the default is for the key to be in the up state, while “D” is an option, because you have to remember what the default is? Does PixelGetColor for v1 have a bug because you can specify “RGB” but not “BGR” and you have to remember “BGR” is the default?

One’s philosophy on how a language should be structured does not constitute whether something is a bug. If it doesn’t follow the documentation (including causing crashes or other undocumented behavior), then it can be considered a bug. I have yet to see the definition of a bug anywhere state that a bug is not allowing code to be written per a certain programming philosophy, no matter how widely held. If you know of a bug being defined as such anywhere, please provide a link.

Otherwise, this issue can be addressed either by changing the language or the documentation. I have provided two examples that don’t meet your expectations of a language as you have stated them, yet their behavior is fully documented and therefore are not bugs and have not been called out as bugs.

Also, these types of debates aren’t settled by comparing who has coded the longest, but thank you for sharing.

[just me]

In v1 there is no ShortDate option for DateTime controls at all.
In v2 it's defined for the SetFormat() method so the code needed to handle it does already exist. I see no reason to prohibit its use in Add. Otherwise it should be removed completely.

[boiler]

Why should it be removed completely in that case? The case for leaving it as-is (other than a documentation change), is this: It isn’t needed in Add since it is the default. And Add isn’t called more than once for the same control, so it is not the mechanism for switching it back to the default after switching it to something else, if desired. It is needed in SetFormat because that is where that can and would be done.

[william_ahk]

Indeed. ShortDate is added probably because it felt weird to call SetFormat with omitted/blank parameter for the locale's short date format; and presumably SetFormat is added because it felt confusing to change the format of a DateTime control by setting its Text.

@boiler, consider this simple practical example:

Code: Select all

#Requires AutoHotkey v2.0
#SingleInstance Force

DateFormats := ["ShortDate", "LongDate"]
ChosenFormat := 1

MyGui := Gui()
MyGui.Add("DateTime", "vMyDateTime", DateFormats[ChosenFormat])
MyGui.Add("Text", , "Choose Format: ")
For DateFormat in DateFormats
	MyGui.Add("Button", "x+10 vFormat" A_Index, DateFormat).OnEvent("Click", ChangeFormat)
MyGui.Show()

ChangeFormat(GuiCtl, *) {
	ChosenFormat := Number(SubStr(GuiCtl.Name, StrLen("Format")+1))
	MyGui["MyDateTime"].SetFormat(DateFormats[ChosenFormat])
}

At Gui creation, the format is read from the format array by the user's chosen option. When the chosen option is changed later on, the array of date formats should be the same one. It would be unwieldy to define two separate arrays.

Now of course we can define DateFormats as ["", "LongDate"] for consistency, but we might as well remove the "ShortDate" option for safety as one method supports it and the other one doesn't. Also the blank format is unintelligible as a value in the formats array.

[boiler]

Yes, that is a good example and makes sense.

[lexikos]

In v2 it's defined for the SetFormat() method so the code needed to handle it does already exist. I see no reason to prohibit its use in Add. Otherwise it should be removed completely.

The code needed to handle it in SetFormat already exists. It is not prohibited in Add; it is simply not implemented.

Given the limited reasoning given in the commit which added ShortDate to SetFormat, it would seem correct to implement the option in Add as well.

[lexikos]

Actually, the default is DTS_SHORTDATECENTURYFORMAT (as documented), not ShortDate (DTS_SHORTDATEFORMAT).

// DTS_SHORTDATECENTURYFORMAT is applied by default because it should make results more consistent
// across old and new systems. This is because new systems display a 4-digit year even without
// this style, but older ones might display a two digit year. This should make any system capable
// of displaying a 4-digit year display it in the locale's customary format. On systems that don't
// support DTS_SHORTDATECENTURYFORMAT, it should be ignored, resulting in DTS_SHORTDATEFORMAT taking
// effect automatically (untested).

DTS_SHORTDATEFORMAT shows the century only if the format selected in the system's regional settings includes the century, whereas DTS_SHORTDATECENTURYFORMAT always shows the century but otherwise matches the system setting.

The default can currently be overridden with -0x0C to use DTS_SHORTDATEFORMAT (which has the value 0).

[lexikos]

v2.0.11 fixes the ShortDate option in Gui.Add.