by BRUFolio » Wed Apr 05, 2006 1:29 pm
WONDERFUL!
one hour difference
At this point it behaves much better with only one bug that i can determine:
when i select a file, it shows the new timestamp is going to be one hour ahead of where i have the time set for in the dialog.
however, after the action is performed, BRU does properly set the timestamp to what the dialog says and it correctly displays it in the date columns correctly after this action.
it is only in the "preview" stage that the times in the columns are showing to be one hour ahead.
IF i turn off "daylight savings time" in Windows, making my computer on normal Eastern Standard Time, then, it displays and works as expected.
THE BAD PART of this is, that, when on Daylight Savings Time, the Auto-Date that is inserted into the filename is the timestamp that is displayed in the preview, the one that is one hour ahead. So, I end up with a file that is dated as i wished, but the date inserted into the filename is one hour faster than the timestamp of the file...:
Like so:
I start with this file:
filename.............................timestamp
filename.txt........................7am
i wish to rename to:
filename_2am.txt 2am
I set the dialog to fix timestamp to 2am
i use autodate to insert the created (new) into the filename as a suffix.
I am previewed this:
filename_3am.txt 3am
and when I do the rename i get a file that displays like this in both BRU and Win Explorer:
filename_3am.txt 2am
"access to an unnamed file was denied" error
I get this under this circumstance:
I am setting the filedate dialog to set all dates to "current"
I am setting the attributes to set R/O and no change to the other two.
the file's attribute is already set to R/O
I get this error: "access to an unnamed file was denied" error
The filedatetimestamp was NOT changed but the filename was renamed as specified.
But, if i do this to a file that is NOT set to R/O already, it works setting the attribute to R/O and the filedatetimestamp correctly -- with no error message.
So, it would appear that if BRU encounters a request from a user to change an attribute that is identical to what the file currently has, that it would do so.
In Win Explorer I often select many files, some are R/O and some R/W and i want to set them all to R/O, I find the box having a shaded check and i click it twice to indicate to change them all to R/O........
perhaps BRU would need to do something twice?
That's all i have found with an initial few minutes,,,
i need to reboot so i am posting this now and will post any other findings later,,,