antp.be forum

The time format depends on Windows regional settings I suppose?

Yes, it does.

When I change regional settings to 'English (USA)', I get the same directory format as Thermal Ions. But I am surprised that noone mentioned that misbehaviour yet

That brings me to the question if Vista shows the same behaviour .. so it would be nice to get an UPDATE_CHECK.txt file from a Vista user with regional settings for USA or similar (12 hours AM/PM)

Yes, it seems that Regional settings is the culprit. For example playing around with them shows the following defaults for certain countries:
English (Australian) - 12 Hr time (home for me)
English (UK) - 24 Hr time
English (US) - 12 Hr time
French (France) - 24 Hr time

It's getting a little complicated

The 12/24 hour problem can be solved within a few minutes, but while testing different regional settings I found another problem .. the fact, that date format can differ from Day/Month/Year.

For example 03.04.2007 would be 03/04/2007 with regional settings set to English (Australia) but 04/03/2007 set to English (US).

At this moment I have only two ideas to solve this problem:
Either I add a script option to switch the date format manually - would be easy to do, but the user will have to take care that he has chosen correct settings or script's autodetection will fail.
Or I will have to find some kind of 'standard date' that can be used to find out which date format the region settings use. This could be a single file with a known date, so that it could be compared to its appearance on a directory listing - or I will have to fetch the current date from internet and then compare it to the date of latest UPDATE_CHECK.TXT file - but both methods will need some extra time when running the script.

@antp: Maybe there is any variable that I can use to get the current date into the script ? 'FieldDate' does not work for this, because it is dependent on the chosen film.

Any other ideas ?

Would it be viable to export to a text file the registry key that contains the information and then read this in to test the necessary regional settings?

On XP the export can be done with
regedit /E regional.txt "HKEY_CURRENT_USER\Control Panel\International"

Should be able to check out later today if the key is the same for Win98.

{edit}
PS. I think you should keep away from testing current date from net and comparing against the file. This test would fail at least 12 days of the year when the day and month are identical, and you then also need to consider timezones - thus you're back to trying to establish the regional settings on the system.

Checked out Windows 98SE and discovered that although the same registry key is used to store the regional settings, only the locale code is stored unless you have overridden any of the date / time setting defaults for that locale. So it seems that in Win98 you would need a lookup table containing all locale codes, along with the date and time defaults for each one.

WinXP seems to store all the individual date / time / number formats in the registry even if defaults are not overridden.

Actually, this may not really be a big problem as on Win98 at the moment you're not testing the dates are you?

On my PC the date format is yyyy-mm-dd

In command line / batch file, to know current date in a batch you have the %date% variable.

Maybe that only the file size should be checked, instead of file date ? There is really little chance that the size is the same but the contents not. Though that it would not indicate if the script is newer or older.

Personally, my preference would be that if autodetecting the date/time format becomes too difficult, then switch to using options where the user chooses the format they use on their system.

In command line / batch file, to know current date in a batch you have the %date% variable.

But this variable shows the same behaviour as the directory listing does, so it's not useful. For comparison of the format it has to be system independent

Personally, my preference would be that if autodetecting the date/time format becomes too difficult, then switch to using options where the user chooses the format they use on their system.

I agree. I will need more time to find a better (automated) solution for that and I don't know if it is really necessary. Maybe I'll have a closer look on the registry export idea when I have some more free time.


So here's a new version (1.4.0) :
http://bad4u.saveitfree.com/scripts/UPDATE_SCRIPTS.ifs

This version works with dd-mm-yyyy, mm-dd-yyyy and yyyy-mm-dd date format (selectable via option). Some more 'exotic' formats are still missing and will be added if someone asks for it. Updates without autodetection are still and always have been possible.

It would be nice if someone could test the new version on Vista, as I had to rewrite this part of the script completly and cannot test it.

@antp: Could you upload version 1.4.0 then, please ? Thanks

Sure

Hi Antoine, a short question about the scripts.ini file from the program's folder : The "Infos.Date" value seems to use YYYY-MM-DD format always, independent from local Windows regional settings. Is that right ?

Indeed, I forced that format

There will be a new version (v.2.0) of UPDATE_SCRIPTS released soon. Almost the complete code has been rewritten to make the script more userfriendly, more reliable and faster.

The new script does not need to set local date format, it is independent from Windows regional settings and does not need extra changes for running on Vista (I hope so ) ! To make it faster and more reliable there's an option to use Windows Scripting Host instead of cmd.exe - you can use it if WSH is enabled on the computer (as far as I know it is enabled by default on XP/2000, but might be disabled by some security software like XP-Antispy).

You can download an early version here : ****** (copy the link into a new browser window !)
Remember: This is a forum-release only for testing purposes. Please report problems here (Can someone test it on Vista, please ?)

Known bugs:
- the automatic update function to update the script itself is still missing *FIXED*
- the loop for updating more than one script is still missing *FIXED*
- when option autodetect_new_scripts is set to "1" the *.pas script files will be listed under "Additional Scripts", even if they are present in local folder
- when option autodetect_new_Scripts is set to "1" an updated script will remain on the list until you left AMC and restarted it

Hello,

I shortly tested it on Vista 64 to update the Allocine script, and it has worked (very well :-)).

Thanks
Didier

dku wrote:Hello,

I shortly tested it on Vista 64 to update the Allocine script, and it has worked (very well :-)).

Thanks
Didier

Thanks. Could you please test the script on Vista with option "autodetect_new_Scripts" set to "2" , because then it uses Windows Scripting Host - and I don't know yet if Vista supports WSH.

@Antoine: I'm a little bit confused about scripts.ini - when exactly is it updated/saved (I suppose it's when you close the scripting window, right?) and what exactly is then being updated in the file - data for all scripts found in the scripts folder or only for some of them ? (What I know is that it keeps data for all scripts that have ever been installed, even if they have been deleted. Sometimes it seems that all scripts from the folder are updated in scripts.ini, but sometimes it seems some recently updated scripts keep the older date in scripts.ini until they have been opened/used ?)

From what I see from my own code I think (:D) that it is indeed when the window is closed that the file is updated.
The whole file contents is stored in memory and is rewritten actually (using the TMemIniFile object from Borland, much faster than Windows' functions for handling ini).
A script entry of the ini is updated if the file date is different from the date stored in the ini.
Info from deleted scripts are not deleted from the file, indeed.

New version 2.0.0 released :
http://www.bad4u.741.com/UPDATE_SCRIPTS.ifs (copy link into a new browser window)

- new release, almost 90% of script has been rewritten
- change: no need to set local date format, independent from regional Windows settings
- change: new UPDATE_CHECK.sav file to improve search results when using autodetection
- new function: optional use of Windows Scripting Host, faster and more reliable (Recommended!)
- new function: in autodetect mode - full automatic update of UPDATE_SCRIPTS.ifs
- new function: in autodetect mode - autoupdate on first start for scripts with unidentified date (i.e. *.pas is not listed on scripts.ini)
- new function: possibility to show AMC related informations from the script server

Please test the new script and report any bugs here on this topic !

This release should be stable, but I would prefer to wait a few days for bugreports before uploading to scripts server.

New version 2.1.0 released :
http://www.bad4u.741.com/UPDATE_SCRIPTS.ifs (copy link into a new browser window)

- change: improved autodetection when option 'autodetect_new_scripts' is set to '1'
- change: faster automatic update for scripts with unidentified date on first run

New version 2.1.1 released:
http://www.bad4u.741.com/UPDATE_SCRIPTS.ifs (copy link into a new browser window)

- bugfix: IMDB.ifs appeared on results list again after downloading latest version

I did it on the previous version and I made the same mistake again now. IMDB.ifs got a wrong file date because of the similar filename Culturalia+IMDB.ifs