System different from mine

[Ugo DI LUCA]

I downloaded a lot of attachment from that forum. Often I have a dialog box SAYING "System set up different than yours" (I try to transmate it as I am french).

The problem is that this dialog box appears now even with my own DB. Do I have to change my settings ?

Thanks

[andygaunt]

When you download items from the internet, they have the system settings of that country (mainly the date format, but also the seperator in calculations can be different from country to country like , in the UK to ; in the US)

If you wish to have them use your system formats then save a copy of the database as a clone with no records.

This will then set the copy to your system formats.

It shouldn't have changed your databases settings as you created them on your machine.

[Ugo DI LUCA]

This message only appears when I open my Client DB. Strange.

[Vaughan]

I stick the "Set User System Formats [on]" step in the startup script for each file. Kills it straight away.

[andygaunt]

Ah, but Vaughan. That doesnt solve the problem, does it.

That is just putting a rug over it, sweeping it under the carpet, burying it where you hope no-one will see. Hoping to get away without anyone noticing.

Sneaking away from the party before giving someone a present!!!

Am I getting carried away....

Oh, how is your keyboard!!!!

[Anatoli]

Shouldn

[Tintagel]

If you are getting the message now even with dbs you created yourself, that means something in your system set-up has been changed since those db's were created. Maybe you changed the date formats? Or the default language or other regional settings.

Either way save as clone like Andy says will work. Or just put settings back the way they were.

[Vaughan]

Andy -- disagree with you there, I must.

If I make a database on my machine here in Astralia the date format will be dd/mm/yy (or dd/mm/yyyy as I prefer on my Mac). That's how I assume I'll enter dates into it, and I'm used to doing it that way I am.

When you open my file on your machine you'll be prompted that the formats are different. You say yes to change them and you enter the dates in the format that you prefer, mm/dd/yy (or whatever). If you chose to click no then you'll have to type the dates in my format, which to you will be awkward.

So all the "Set User System Formats [on]" step does is click the yes button for you, so you can enter dates into the file the way you are used to. I think that should be the default behaviour.

Where is the problem with that? From an interface design perspective I think the user should not even have to know that their machine's format is different from mine, FMP should just adapt *unless* there is a reason not to. And I cannot think of a reason not to. There may be one, and it can be adequately accounted for with the script step "Set User System Formats [off]".

FMP can and will adapt... I think its date handling features are truely inspired: transparent and seamless to the user.

[SandraDaintree]

I think its date handling features are truely inspired: transparent and seamless

Not always seamless. "Set User System Formats [On]" only works for data entry, but not for data editing. you enter the dd/mm/yyyy down there in Oz on a database that was made in an mm/dd/yy format (and it is accepted because you have "Set User System Formats [On]"). But if you click into the field you see it in the file format, not the format you just typed it in.

This is ***incredibly*** confusing.

You type in 11/12/2002. Then you click back into the field and it says 12/11/2002. You think it is an error so you edit it to say 11/12/2002 like you were sure you entered. Then you find that the date is being interpreted as 12 November.

Andy's solution is the only really satisfactory one. The database has to be **converted** to work with local formats. "Set User System Formats [On]" is a temporary fix. Awkward and clumsy, it is.

[andygaunt]

You want to know another problem I have with Set Use System Formats.

If I create a database here in dd/mm/yyyy and want to use the ScriptIT scheduler to run a script at a preset time. It works fine in the dd/mm/yyyy regions but if I send the database to somewhere that has mm/dd/yyyy formats and they schedule something to run, it doesnt work!!!.

Aaaaaaggghhh. Pain in my posterior it is.

[CobaltSky]

Hi Andy,

I've encountered this little show-stopper (not with SCRIPTit, as it happends, but with other like products). I found you can get around it.

The way to make the plug-in accept the date correctly regardless of the regional settings, system formats etc, is to force-format the date component of the parameter, with a parameter string along the lines of:

Day(ScheduledDate) & "/" Month(ScheduledDate) & "/" Year(ScheduledDate)

instead of the more usual TextToDate(ScheduledDate) which is the typical vendor-recommended method.

The force formatting has the advantage that it maintains the integrity of the scripts regardless of the regional settings, the status of the 'Use System Formats' option and even after the file has been saved as a clone. I'd hazard a guess that this approach could be adapted to work with SCRIPTit in a similar way to the way as I've been able to deploy it with several other plug-ins that accept date parameters in text form.

[jasonwood]

Why can't the whole world just learn to enter dates the RIGHT way!

yyyy/mm/dd

It makes so much more sense because everybody understands it!

Here in Canada I never know what to make of 3/5/2002. Canada is supposed to be dd/mm/yy but we are so influenced by the US that many people use mm/dd/yy... so you never know what it is!

[Anatoli]

Yup, yyyy/mm/dd is far the best AND universal.

The European is just the opposite reading.

The US is the most illogical format from all.

Lets present this to the UN now, so our grandchildren will have chance to discuss that and maybe in year 2555 the World will have unified date format. Let's be optimistic

[Ugo DI LUCA]

Thank you everybody for the discussion on date.

I use two computers, both IMac 8.6, one at home and one at work.

The Problem occurs only for my Client DB and only at work.

I backup my files every evening and usually brings a disk at home to update my Home Computer, to work on it. But as I gave priority for a work on a new Db structure, I didn't update my Home computer for one week, so I can tell. I'll see tomorrow if this problem will persist after having updated the actual DB I keep in my Home Imac.

But here is another problem I noticed :

In layout mode, a same file do not have the same color palette at home than at work. One is RGB, the other is CMJN, the other TLS. When I want my Work Computer to switch to RGB, I have to reboot my computer. But I do not have any prob with it at Home. Why ?

What I did is changing the Monitor Setting in my Home Computer respect from my Work Computer, but I don't think this could be system setting ?

[Vaughan]

Sandra wrote:

"Not always seamless. "Set User System Formats [On]" only works for data entry, but not for data editing. you enter the dd/mm/yyyy down there in Oz on a database that was made in an mm/dd/yy format (and it is accepted because you have "Set User System Formats [On]"). But if you click into the field you see it in the file format, not the format you just typed it in."

That's because you see the data *as it was entered* whenever you click into the field. To do with system formats, that one is not.

[andygaunt]

Lets to get back to bigger picture we shall.

To speak in tongue of Jedi is strong, for then power of the force influence the date it shall.

hmmm, strong the force in forum it is, and date be controlled by power we have.

Date agree we shall controlled it can be, by Use system set formats or clone we shall make. Agree we shall yes, that both correct can be.

Glad discuss topics in here we are, and answers those who seek shall find. For strength in number of answers there is, even when answer obvious is not , find it we shall.

Weird this topic now is, and off topic agree we shall. But always to turkey shall thanks we give, on today, the giving of thanks our American friends have.

[Natalie]

Well, at least I understood the bit about turkey!

You're offering us tur(n)key solution, right??!

[Ugo DI LUCA]

andygaunt said:

You want to know another problem I have with Set Use System Formats.

If I create a database here in dd/mm/yyyy and want to use the ScriptIT scheduler to run a script at a preset time. It works fine in the dd/mm/yyyy regions but if I send the database to somewhere that has mm/dd/yyyy formats and they schedule something to run, it doesnt work!!!.

Aaaaaaggghhh. Pain in my posterior it is.

Andy,

Sorry to reboud on this after a year or so. I'm just trying to save my posterior from future pains

As I pointed it on another thread, the way FM interprets the ":" seems not the same with French settings that the way it is with the US.

As a cruel example :

US Settings :

Text field 1 : Andy:Gaunt:eBullet ---> WordsCount = 3

Text field 2 : 11:12:00 -----------------> WordsCount = 3

French Settings :

Text field 1 : Andy:Gaunt:eBullet ---> WordsCount = 3

Text field 2 : 11:12:00 -----------------> WordsCount = 1

Could it be it your problem ?

Now, another thing weird.

I've attached a file on another thread to show the differences from both settings on the time fields calcs.

I'm seeing weird things here, all US calcs I had pasted in the calculations giving bad results.

But Lee (SMITH) opened it and it was working fine for him.

1. In this instance, how someone could open the file and see it the way it was on my desk.

2. How did you solved your problem, if it was "time" related rather than date related ?

3. Does anyone know what the f...k is happening here, and why this wouldn't have been pointed before. I just can't believe it ....

Thanks as usual.

Here's a link to the thread I was referring to. I'll attach the screeshots of my files to this thread (as the results are way different from what you are seeing when you download them) in a minute.

Link to the other thread

[andygaunt]

Hi Ugo --

My issue was with dates and the differences of dd/mm/yyyy to mm/dd/yyyy. This was solved with the TextToDate function in the ScriptIt plugin

As to the times, I never had an issue with these. eBullet creates schedules to run in the future for its emailers if required, and the times always came through fine, be they in UK or US format.

Sorry about that.