fbpx
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: SetFDateTime() is missing

SetFDateTime() is missing 3 weeks 3 days ago #9104

  Karl-Heinz's Avatar Topic Author Karl-Heinz Offline Posts: 262
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.
SetFDateTime ( "C:\xyz\xyz.txt" , Today() - 2 , "00:00:00" ) 

That´s what VO does if a "00:00:00" timestamp is passed:
IF Secs ( cTimeStamp ) == 0
 cTimeStamp := Time()
ENDIF 

- To be compatible with VO i created two overloads.
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.
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

Please Log in or Create an account to join the conversation.

SetFDateTime() is missing 3 weeks 2 days ago #9122

  Chris's Avatar Chris Offline Posts: 1163
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.
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

SetFDateTime() is missing 3 weeks 13 hours ago #9149

  Karl-Heinz's Avatar Topic Author Karl-Heinz Offline Posts: 262
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

Please Log in or Create an account to join the conversation.

SetFDateTime() is missing 3 weeks 6 hours ago #9155

  Chris's Avatar Chris Offline Posts: 1163
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...
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

SetFDateTime() is missing 3 weeks 5 hours ago #9156

  wriedmann's Avatar wriedmann Offline Posts: 1567
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
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

SetFDateTime() is missing 3 weeks 3 hours ago #9157

  FFF's Avatar FFF Offline Posts: 573
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...

Please Log in or Create an account to join the conversation.

SetFDateTime() is missing 3 weeks 2 hours ago #9158

  lumberjack's Avatar lumberjack Offline Posts: 457

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

I have to second that...
______________________
Johan Nel
George, South Africa

Please Log in or Create an account to join the conversation.

  • Page:
  • 1