Scripts for MAC vc PC

[Dan-A]

Hi all,

I was reading some messages on the forum & find reference to "Quit" application.

That is a script step I don't have in scriptmaker (FM 5.5v2 on PC).

I figure it must be available on MAC?

If that is correct, to design a cross-platform application will I need to

finish the design on MAC to add different script steps that are

platform dependent?

Something like If current system = Mac do Quit else do Exit?

Thanks

--Dan

[SteveB]

Altho I'm not familiar with MACs, I suspect they are talking about 'Exit Application', which I'm sure exists on both platforms.

Steve

[Lee Smith]

Think twice before you use it in your files, as it really pisses me off when a developer closes my FileMaker Application when all I want to do is close there stupid files.

You will find it is the very last script step "Quit Application" in FM 5.0.3 on a Mac.

Lee

[andygaunt]

Lee seems to be having issues over there. <wink!>

What he is trying so eloquently to state is that using this in a solution where yours are not the only files open on a machine can cause a little bit of ....how can we put this....irritancy!.

Better is to create a proper close routine using the Close File command, rather than the Exit, Quit, Leave, 'Get Outta FileMaker command and to hell if you are running other files' command.

And I am sure he is not stating that all developers that have files are stupid, or that the files are stupid. Well, at least not the second option. Not sure on the first!!! <grin!>

[Fitch]

Dan, the Exit command is automatically translated to Quit, so no worries. However, I agree with Lee, unless you are distributing a runtime, just close your files, don't Quit. And FWIW, if you have a lot of files with a lot of data, it's nice to check if the files are open first, so you save the time of opening then closing the file if it's not open to begin with:

If ( Position(DatabaseNames, "Contacts", 1, 1) )

..Close (Contacts.fp5)

End If

Steve, Macs don't Exit, they Quit.

[Lee Smith]

They, the developer and/or his files, only become stupid when the developer [color:"red"] Doesn't provide the options mentioned in your posts. In other words, don't assume that your solutions is the only one that a user will have opened, or that they will [color:"red"] not need FileMaker for something else after they close your files.

Lee

[SteveB]

I concur...there are lots of stupid things developers do...just look at Filemaker for proof.

Steve

[LaRetta]

Yeah! Some Developers are so stupid they put Allow User Abort OFF when they post a demo that's supposed to be xplat (and has pause/resume) but has a Mac problem

Hopefully, they only do something that stupid ONCE!! BTW, if you think I'm being rude, I'm talking about myself

LaRetta

[Dan-A]

Thanks for ALL the colorfull replies!!

I like this forum!

I just chose Quit/Exit as an example!!

But as Tom said the script step gets translated automatically for macs!

Do all script steps get translated that way?

--Dan

[paulage77]

hmmm.. wonder what the 'Perform Applescript' does when executed on windows?

[kenneth2k1]

The step is ignored when executed in Windows.

Ken

[Fitch]

Look in the FileMaker help for "Scriptmaker steps" and you'll see which steps are Mac or Windows only. (If you're on OS X, try <file:///Applications/FileMaker%20Pro%206%20Folder/FileMaker%20Pro.app/Contents/Resources/FileMaker%20Help/FileMaker%20Pro%20Help.htm>.

One thing Windows does differently is that instead of hiding windows, it minimizes them. Surely one of FileMaker's least-loved features.

Also, on a Mac, a Show Message dialog has no close box. On Windows it does, and the effect is as if you clicked the default button. Gotcha.

[LaRetta]

Good God Tom! "Also, on a Mac, a Show Message dialog has no close box. On Windows it does, and the effect is as if you clicked the default button. Gotcha."

Thanks for pointing this out! How could FM have missed this? I just tested and Custom Dialog does the same thing. Ohhhhh, this is very, very BAD

LaRetta

[Leb i Sol]

"Ohhhhh, this is very, very BAD "

-no no no...don't worry.....who cares about Macs....look what happend to poor Adam when he bit into it

...just kidding Apple_Lovers

[Fitch]

Leb, the point is that in this case, it's PCs that are behaving badly. I.e. it's not bad that Macs have no close box in their Show Message dialogs. It IS bad that you might get a very unexpected result on a PC if you didn't know about this "feature." At the very least, it will make you think twice about your default behavior. Wouldn't you expect clicking the close box to be the same as Cancel? Well then you better make Cancel always the default button. Doh!

[Ugo DI LUCA]

Sure, this is a Windows version "Bug".

The Big question though...WHY this difference from Platform versions ?

Is someone aware of what ewactly is the problem (apart from Applescript) that render this impossible to FMI to release a totally "equivalent" solution ?

[LaRetta]

Hi Tom and Alen,

Yes, it's Windoz that terrifies me! But I don't believe you can switch the default. Button 1 is 'process' no matter what you call it.

To my embarrassment, I've tried. Here's the post in which CobaltSky clarified it for us:

FM Cafe' - Show Custom Dialog

Now what? Change everyone to a Mac? I wish.

LaRetta

[Fitch]

Just to clarify, LaRetta is talking about Custom Dialog, which apparently won't take any text input unless the first button is the one clicked.

Show Message can use any button as the default.

(I never use Custom Dialog because a lot of our clients are on FM 5.x, and we have a dev. license for Troi Dialog. Sorry to take this thread off-topic.)

[LaRetta]

Hi Tom,

You didn't take us off topic! Show Message and Custom Dialog are a very big part of scripting - at least for me! And knowing x-plat is critcal also.

Thanks for the clarificaton that Show Message default can be changed but Custom Dialog can't. The link I listed, "Show Custom Dialog" was the title of the post. I didn't mean to confuse anyone.

The thing is this ... if you can change the default on Show Message (and the two should respond the same), the fact that you can't on Custom Dialog just indicates a big fat design error.

Custom Dialog appears to have been an afterthought with no testing whatsoever. It should have been fixed by now. I'm a bit peeved about it, as I now have to consider whether to undo hours worth of work just completed for a client. I certainly can't charge him for it, either.

I still love FM ... what's a person to do? Go back to using Layouts, I guess

LaRetta

[kenneth2k1]

default behavior = learned response.

Those that work on both platforms on a regular basis are able to cope with the little differences between em, but what matters is what your users would do.

[LaRetta]

Hi Ken,

If my Users were Mac people using a Windoz system, I wouldn't be concerned at all! They probably wouldn't even notice that little 'x' or they'd think it was a fly

Windoz Users however, notoriously close everything that way. I confess, I do it to. This current client is Windoz only. Maybe a learned response can be un-learned, but I'm not betting my Invoicing process on a User who may, in a panic response, try to cancel that way.

LaRetta

[Ugo DI LUCA]

A little out of topic.

The thing is this ... if you can change the default on Show Message (and the two should respond the same), the fact that you can't on Custom Dialog just indicates a big fat design error.

This Custom Dialog apparent "bug" seems to be covered in a lot of recent threads. Checks Giuseppe's answer. I concur with him this is not a bug, if you keep FM Built in logic and also that a Dialog.fp5 is more efficient.

Custom Dialog, is it buggy ?

[-Queue-]

Fitch, what would be the benefit of using 'If [Position(DatabaseNames, "Contacts", 1, 1)]' instead of 'If [PatternCount(DatabaseNames, "Contacts")]'? It seems to use a lot more overhead than is necessary. Just curious as to what your logic is.

[BobWeaver]

This question came up once before. PatternCount has to go through the entire text to count how many times the search text occurs. Position only has to go as far as the first occurence of the search text. So, in theory the Position function would be faster. On the other hand, you have to pass more parameters to the Position function. So that may possibly slow it down a bit. I don't know if anyone has ever run a comparison test to see which one is really faster.

[-Queue-]

Ah, this makes sense. Thank you, Bob. I just tested this with a 31 file solution. It took less than a second for both calculations. So for DatabaseNames, I would think that neither one is really more efficient than the other. Has anyone tested it with a 75+ file solution? I'm going to stick with PatternCount for now. It looks cleaner and more intuitive to me.

[Anatoli]

RE: Has anyone tested it with a 75+ file solution?

HOW?

FM Client can open only 50 databases

Probably you think just about formula with 75+ names.

[-Queue-]

Ah, good point. I was thinking about the server, which can host more than 50 dbs at a time. In that case, the speed difference between PatternCount and Position is negligible, and there is no reason to use Position, unless one prefers typing more characters, correct?