* Setting a date field stopped working

[JoopvB]

I have these statements in some plugins to set a date:

if f.type == 'Date' then
local dt = fhNewDate()
if dt:SetValueAsText(pField, f.value) then
fhSetValueAsDate(pField,dt)
end

pField is a valid pointer to the field,
f.value is text field containing a valid date e.g. "02-08-1865"

This always worked perfectly, but now, instead of a correct date, it's set to something like 008.

Has something changed or...?

[tatewise]

dt:SetValueAsText(pField, f.value) is invalid.

The syntax is bResult = dt:SetValueAsText(strText [,bAllowPhrase])
i.e.
Your statement should be if dt:SetValueAsText( f.value, true ) then

[JoopvB]

Changed to

if f.type == 'Date' then
local dt = fhNewDate()
if dt:SetValueAsText(f.value, true) then
fhSetValueAsDate(pField,dt)
end

But still no date. I have no idea why.

[JoopvB]

Adding to my previous post: suppose the date is 24-12-1867, the date set by my statements is frm 0024. It's like the part "-12-1867" is kind of ignored?

[JoopvB]

The problem is solved. In preferences the preferred short date format was set to "dd/mm/yyyy". Setting it to "dd-mm-yyyy" solved the problem.

Odd however that the parsing of "dd-mm-yyyy" is dependent on changing the delimiter from "/" to "-". I would expect it to work regardless of.

[tatewise]

It seems the SetValueAsText(...) method is less tolerant of alternative Date formats than the user interface Date fields.

BTW it is not just changing the delimiter ( - / . ) but also the order of dd mm yyyy

[JoopvB]

The problem is that when you restart FH the preference is reset and then SetValueAsText reverts to it's poor parsing. I'll report it to CP.

[tatewise]

Wow!
You are correct, but the problem only applies to the Tools > Preferences > Short Date Format when a hyphen (-) is involved.
The options with a slash (/) or dot (.) are remembered correctly.

[JoopvB]

Yes, and the odd thing is that it must have been introduced during one of the last few updates. I haven't been using FH for some months and my plugins always worked ok. Just recently started entering data again and noticed the odd behaviour.

Anyhow, CP is aware of the problem now.

Thanks for your help.