SetFDateTime() is missing

[Karl-Heinz]

Guys,

without changing the SetFDateTime() sources it´s not possible to set the timeStamp of a file to "00:00:00". When you run this sample in VO the Filedate is as expected the current date - 2 , but the Filetime is set to the current system time.

Code: Select all

SetFDateTime ( "C:xyzxyz.txt" , Today() - 2 , "00:00:00" ) 

That´s what VO does if a "00:00:00" timestamp is passed:

Code: Select all

IF Secs ( cTimeStamp ) == 0
 cTimeStamp := Time()
ENDIF 

- To be compatible with VO i created two overloads.

Code: Select all

FUNCTION SetFDateTime ( cFile AS STRING , dStamp AS DATE , cTimeStamp AS STRING ) AS LOGIC     
	RETURN SetFDateTime ( cFile , dStamp , cTimeStamp , FALSE  )  

FUNCTION SetFDateTime ( cFile AS STRING , dStamp AS DATE , cTimeStamp AS STRING , lAllowZeroTimeStamp AS LOGIC ) AS LOGIC 
LOCAL lOk AS LOGIC 	 
	
	
TRY 
	
	
	lOk := TRUE

	// VO behaviour	if a NULL_DATE is passed 
	
	IF dStamp == NULL_DATE
		dStamp := Today()
		
	ENDIF

	
	IF ! lAllowZeroTimeStamp 

		// VO behaviour	if the TimeStamp "00:00:00" is passed 
		
		IF Secs ( cTimeStamp ) == 0
			cTimeStamp := Time()	

		ENDIF 	 
		
	ENDIF 		

		 
    VAR ts := TimeSpan.Parse( cTimeStamp )
    
	File.SetLastWriteTime( cFile ,;
		DateTime { (INT) Year ( dStamp )  , (INT) Month ( dStamp ) , (INT) Day( dStamp ) ,;
		ts:hours , ts:minutes , ts:Seconds } ) 
	
CATCH 
	
	lOk := FALSE 	
	
END TRY 			
		
		
RETURN lOk 

- Another option is to use a single func with an optional param instead. If this param is set to TRUE a "00:00:00" timestamp is not changed to the current system time.

Code: Select all

FUNCTION SetFDateTime ( cFile AS STRING , dStamp AS DATE , cTimeStamp AS STRING , lAllowZeroTimeStamp := FALSE AS LOGIC ) AS LOGIC

What do you think is the best solution ?

regards
Karl-Heinz

[Chris]

Hi Karl-Heinz,

Thanks for looking into that! I've also had a look, unfortunately as always it is way more complicated with VO...First of all, VO allows omitting the date and/or the time parameter, so the function declaration needs to reflect this.

Furthermore, apparently VO allows any separator for hours:minutes, so "10:00, "10,20", " 10 40" etc need to be supported. Also, from what I see, it ignores the seconds that may exist in the string, and, even stranger, when you pass a string "10:00:30", it simply just fails and does not update the time stamp ("10:00:29" is ok!!!)...

So I think the function needs to be implemented in a VO-compatible way, with one overload only and really let it rest in peace, same way that it needs to be done with so many other functions in VO that have such strange behavior. We do not want to encourage people to use such functions in X#, they are included only for compatibility with existing code. For new code, I think it's always better to use one of the many powerful methods of the System.IO.File class.

[Karl-Heinz]

Hi Chris,

it makes no sense to emulate all the pitfalls the func offers. SetFDateTime() even eats a time like "11:99:12", while TimeSpan.Parse( "11:99:12" ) throws - of course - an exception.

i´m using SetFDateTime() in a update exe where embedded ressources are extracted at runtime. Finally
the files get the DateTime stamp "dd.mm.yyyy 00:00:00". Because i have a solution, there´s no problem if you don´t add such a func to the runtime.

regards
Karl-Heinz

[Chris]

Hi KArl-Heinz,

No, no, didn't say we will not add it, on the contrary, will do it now, based on your code, thanks! But you would be surprised to see how VERY often users have complained that functions do not behave EXACTLY like in VO, including many of the quirks of VO. That goes for both X# and Vulcan.NET in the previous years...

[wriedmann]

Hi Karl-Heinz, hi Chris,
supporting even strange behaviors of VO runtime functions is very important for porting applications from VO to X#.
Moving my (only) Vulcan.NET WinForms application I had a few cases where I lost hours of searching only because some function does not behaved like the Vulcan version.
When moving large VO applications it could be a nightmare if some basic functionality makes the application behave strangely.
Therefore the approach of the development team to build even strange behaviors into the runtime is very important.
Wolfgang

[FFF]

To add a bit of advocatus diaboli:
as long, as any "changed" (i.e., "correct") behaviour is clearly documented, i'd propose to drop wrong behaviour. Yes, it is additional work to control/adapt the old code, but, OTOH, you had to code around "wrong" behaviour anyway, so it should be fairly easy to spot
Compatibility is a high goal, but it should stop where it forces rebuilding of downright "wrongs".
Fortunately, we are not "doomed" by market forces as e.g. the makers of Office clones, which have to imitate Excel follies, as sheer numbers are against them...
As usual, YMMV...

[lumberjack]

Compatibility is a high goal, but it should stop where it forces rebuilding of downright "wrongs".

I have to second that...