The DateShort and DateLong Style do not follow the Windows system settings. How can I effect this?
I think I found where the problem is after looking at the codes generated by FF3.
1) I found this in the CreateControls Subroutine CODEGEN genarated by FF3 when compiling:
FLY_zTempString = $Tab & FF_GetDate("MMM dd, yyyy")
SendMessage FLY_hStatusBar, %SB_SETTEXT, 1 Or 0, VarPtr(FLY_zTempString)
2) I found this in the Timer Subroutine CODEGEN genarated by FF3 when compiling:
FLY_zTempString = $Tab & FF_GetDate("MMM dd, yyyy")
SendMessage FLY_hStatusBar, %SB_SETTEXT, 1 Or 0, VarPtr(FLY_zTempString)
This format does not match the Short Date settings in my Windows Regional and Language settings, which is "dd-MMM-yy".
Edited: to remove the bold formatting "b" and "/b" I inserted into the codes.
Thanks - I have logged your report into my bug tracker and will work on a fix. I just need to check FF's internal code to see why it is not generating code to honor the local settings.
Thanks very much.
Paul,
Thinking about this further, I think FF3 should not "hard-code" the format according to the development PC, which I think it is doing now(although in error).
The format should follow whatever settings end-users in different locations have in their PCs when they run the end-products.
So, the end-products need to check for the format and apply accordingly at runtime instead of being hard-coded at development time.
I think this need to be done by FF3 since the codes are generated there.
I think I like that idea. That could go for anything showing Date/Time. Perhaps an option for Dynamic or allow the developer to specify a hardcoded Custom format. That way it can be dynamic where needed or specific if the developer expects the control to always show a certain way.
Quote...I think FF3 should not "hard-code" the format according to the development PC, which I think it is doing now(although in error).
The format should follow whatever settings end-users in different locations have in their PCs when they run the end-products.
So, the end-products need to check for the format and apply accordingly at runtime instead of being hard-coded at development time.
While your idea may apply in most situations, there are other situations in which it does not apply at all.
For example, one of my apps involves the presentation and selection of data having dates in particular (required) formats. It meets the design spec and does what was intended. In this situation, I must ignore the user settings completely.
I believe this must remain the developer's choice.
Perhaps date controls could have an option that "follows user format" or not...
Added: after posting this, I see that Roger posted something similar while I was composing my message...only he's more concise!
Hi Roger and John,
I understand your inputs. It is good to know the opinions of fellow programmers. Thanks.
Just for information and to share my input:
In the apps I have written in VB6 (I will be converting them to FF/PB), I have to use the specific yyyymmdd for internal calculation because the industry data format that I have to use, and which I have no control over, put dates in that way. Whatever date format is shown in the DateTimePicker, I convert to yyyymmdd via codes before using.
Having said this, I believe the date format of DateTimePicker and other date-related controls can be changed via codes - I am speaking from the VB6 perspective and I believe the one in FF3 is the same.
The date (and time) display in the StatusBar panel is usually for information purpose only and is a display of the system clock.
FireFly currently makes a call to the FireFly Function FF_GetDate() to get the text to display for the date. The code for FF_GetDate can be found in the Functions Library:
Function FF_GetDate( ByVal DateMask As String ) As String
Local zText As Asciiz * %MAX_PATH
' Return New Formated Date Depending On The Users Selection Date Mask.
GetDateFormat %LOCALE_USER_DEFAULT, 0, ByVal %Null, ByCopy DateMask, zText, SizeOf(zText)
Function = zText
End Function
As you can see, it calls the WinApi function "GetDateFormat" to do the heavy work. The GetDateFormat function can operate one of two ways: (1) It can get the short/long date format from Windows, or (2) Use a specific picture mask and only get the month/day names from Windows. In FF, I chose to use option #2 so that is why you get a different result. In order to get your result, you would need to modify the FF_GetDate function as follows:
Function FF_GetDate( ByVal DateMask As String ) As String
Local zText As Asciiz * %MAX_PATH
' Return New Formated Date Depending On The Users Selection Date Mask.
GetDateFormat %LOCALE_USER_DEFAULT, %DATE_SHORTDATE, _
ByVal %Null, ByVal %Null, zText, SizeOf(zText)
Function = zText
End Function
So, the question becomes "What is the best approach?". When I was written these routines (IIRC), I was trying to model them after Visual Basic. Based on what Cho is saying above then VB uses option #1? If yes, then how would it display the "Date Normal" option (which I current have as MM dd, yyyy e.g 12 31, 2009)?
GetDateFormat: http://msdn.microsoft.com/en-us/library/dd318086(VS.85).aspx
Opinions?
Paul,
IMHO, the "best approach" would be to provide an attribute on the control's property sheet, and let the programmer set the desired format and behavior.
And if I'm reading the code change correctly, it might also make sense to create a wrapper for the FF_GetDate function that would leave the original intact (I don't like having modded versions) while allowing the alternate values to be passed in.
I hope this is helpful...
-JohnM
BTW, I have my system date format set to YYYY-MM-DD
Hi Paul,
In VB6, the Statusbar can only show date in the Short Format based on the system format setting and there is no option for other date format.
In FF, you provided more choices. I do not know what the DateNormal will be used for. But since the options are already there and to avoid backward compatibility issue, maybe a DateCustom option for the developer to decide/override how the date he/she prefers to show.
The DateShort and DateLong should default to follow the system settings. The date display in the statusbar is purely for information and it is always good for end-users to see the date in the way that is presented in their locale.
Yeah, if there is to be an option then we'd need to think of it as Short, Long, Custom where the first 2 are using the system option. Looking back, I never even used the options in the Statusbar (Looking at them now, only the Long date looks like one I'd even use)...I usually run into this in a DateTimePicker and mostly use a custom option so I know how it will look. So, in the statusbar options you'd need a text field to put custom format strings. A dropdown with edit portion editable would be cool too with some default formats able to be quickly selected like Excel does when you format a cell, only a combo instead of a listbox, and still able to type manual in case a weird style is needed. We need to think of Date, Time, and Date/Time too. Perhaps combine them in the Statusbar options and for DTPickers add a dropdown with the 3 options for type and make the Custom String box an editable Combo with some common styles. Statusbar and DTPicker options should be the same. May need to look at time format functions too so it can pull system settings if formatted different or at least pull AM/PM values...could get complex combining.