I'll start off by saying I'm new to the Filemaker universe, but so far it's been treating me well. I have a feeling that I'll get a slap on the wrist for asking this question, but I can't seem to find the answer via the search feature or perusal of the manual so here it goes:

I would like to run a script whenever a radio button choice is selected initially or changed. For example let's say I have a field named "First Field" whose contents are a radio button set with values '1', '2', or '3'. If value 1 is selected I would like it to perform a script entitled "Data has been selected". Additionally if the user goes back and changes from value '1' to '2' I would like it to either

a) Perform the script "Data has been selected"

Perform another script "Data has been modified"

Either one of these would suffice. I feel like this should be a very standard feature but as of yet I haven't come across the best way to do this. My current thought process involves creating hidden fields that save the last known value of the field and constantly checks for differences between the current and last known value. If there is a difference it will execute the script and modify the last known value. However this essentially doubles the size of my database and increases processing time I don't even know how many fold.

Thanks for your time and help in this matter.

~Chris

Hi Chris and welcome to the forum.

Have a look at eventscript here

http://www.softs4humans.com/FMPro_Plugins.html

That will enable you to do what you want

Phil

I completely agree w/you...this should be standard!!! Unfortunately, FMP is not event driven (still ).

One workaround is to create invisible buttons on top of each radio button. When a user clicks the radio button, she really clicks the invisible button. Use a script parameter to pass along the selected value & retrieve the existing value from the field. Finally, have your script select the value the user chose. This way, you have both existing & new values.

Hope this helps.

And if you select the circle tool to make those invisible buttons and place them precisely sized over your radio, they will properly display perfect black circles when clicked. It looks much more professional than a rectangle turning black when clicked.

LaRetta

The "invisible buttons" is a very time consuming solution. At the moment you will change something in the value list that populates your radio button set, you will have to go on every single layout to make the appropriate button adjustments.

Our tiny and free plug-in can easily be used to create dynamic buttons where each item in the value list became his own button. If you add something in the value list, then the button is added automatically. If you remove something in the value list, then the button is erased automatically. There is no question of

"precisely sized over your radio"

The alignement task is managed by FileMaker.

These "built-in buttons" are adjusted automatically because the script trigger is actually on the field itself. So this method is a one-stop fix for every layouts of your FileMaker solution.

We created a demo of this technique some months ago and it is available for download here http://softs4humans.com/FMPro_Plugins.html

Look for the file named S4H_QuickJumpMenus

HTH

It's an inadequate filestructure that leeds to the urge to event script - Amen!. Most task ought to be with manipulation of keyfields and not something the user should trig upon completion.

If say you wish to evaluate the entry by this script, could you probably fare better by utilizing internal validation. Often is it ignored that you can Count(field1;field2;field3...) to establish if a null entry exists.

Back to keying, since jointables in Filemaker easily can be a return delimited field or a repeating field, are there plenty of ways to change a many2many relation dynamicly ...here are custom functions or repeating fields using Get(CalculationRepe... extremely handy.

Further more shouldn't you forget to utilize multicriterias in the realtions def. allthough hashing algorithms such as:

http://www.onegasoft.com/tools/smartranges/

...have saved a lot on the plugin budget, for the entire developer community.

I do hardly ever touch a plugin, but felt a craving thirst for them as newbee in filemaker. I've learned the hard way that dependency on them stems from not quite catching the gist of filemaker development.

David Kaschel backs me up on this one - take a look at what at present appears on page 11(10) of this:

http://www.codemastersworkshop.com/Downloads/WhitePaperForFMPNovices.pdf

Avoid plugins like the plague. There will be rare occurrences when you absolutely, positively have to use one. Otherwise don’t. If you can do the same thing with hours of tedious programming, do the programming. Don’t use the plugin.

Alright let's instead debate the task at hand, than say that it's absolutely manditory to use event trigging when leaving a field.

One should also observe that mac users accidentally might be opening your stuff expecting "regrettability" to thier actions - read about forgiveness at the very top of this:

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGHIDesign/chapter_5_section_2.html#//apple_ref/doc/uid/TP30000353-TPXREF107

--sd

Well I think that's a very regressive point of view Soren, but I'm respecting your thoughts. Unfortunately, I know thousands of developers who dont' share them.

If I need to go from London to Paris quickly, why I am supposed to fly to Antartica, then have a boat to China and finally drive to London in a car ? Because I think this is actually what you are saying when you propose these "tricky workarounds".

Script trigger IS the key to many concerns and event-based programming is widely used in almost every other development platforms. Currently FileMaker is not natively providing the ability to trigger a script when the user makes a specific action. So please, don't blame me for this weakness and don't blame me for having to program and support an external free plug-in !

Many people saw the paper by Mr. Kachel since he's making announcements every weeks when a new comma were added or removed to his document. And I didn't send any feedback to Mr. Kachel but I guess the plug-in vendors should contact him... Stigmatas and crucifixion seems to be the "mood" in the plug-in section.

So if I understand your point of view, if the functionality is not built in FileMaker, then we should simply forget about the missing functionality or use another complex method to accomplish a workaround. Or actually use another database software that provides this functionality ?

Hi Homer

Let's not lose sight in this debate of the fact that "plug-in" technology is part and parcel of modern computing. Hardware plug-ins were a design feature of the AppleII and were then incorporated by IBM into its PC and is still part of the design in most PCs. The majority of current computer programming languages use plug-in's to add extra features (except they call them extensions or components) Photoshop and numerous other graphics manipulation programs use plug-in filters to add extra features. I and no doubt many others use a "plug-in" which pretends to be a printer in order to produce pdf files. The arguments against plug-ins are just as cogent in these areas as in FileMaker - incompatibilities when upgrading seems to be the major one and yes it will happen and when it does you have to deal with it.

No let not loose it, lets get the script that need triggering pasted up here, so I can be shaken in my beleifs - Of course isn't it larger or better "art" if you like King Crimson desides to play tunes missing a vital instrument here and there, say a Ride Cymbal or string on the bass.

--sd

I know thousands of developers who dont' share them.

I've met the type of developers en masse at Devcon, which in my humble opinion is labelled slightly wrong, shouldn't "Devcon" rather be "The resurection of Willy Lohman"??? The target is overwhelmingly to assure the salesmen that it's the right horse the've betted on - and not the bolstering of skills, such as the labelling suggests. It's done by demonstration of a certain through-put from the pipelines af new snassy ways to make stuff in a jif.

My concern is that it makes developers sloppy in thier ER'ing of getting the relations right. Most of us are migrators from other trades where a strong foundation on the mathematical diciplines like set theory and first-order predicate logic, is either not present or weak to say the least.

This fact - makes Filemaker a charming product to use where you can get away with no planning in a lot of the services we provide - giving us a lot of time learn the intutive art of tweaking operatingsystems oddities, instead of making rock solid relational designs.

But when it comes to it, is it just as mathematical functional illiteracy as going to the betting shop on regular basis.

--sd

Basically my philosophy is don't use a plug-in unless you need to. If you need to, do. Now, whether you really need to is probably subjective. There are a few cases where you do. For example, I've found Troi File to be indespensible in some cross-platform operations dealing with external files. Similarly SMTPit for some email needs.

As far as the "event-driven scripts" plug-ins in question, it is true that there are few times you'd really need it. I think we should keep in mind that FileMaker distributes such a plug-in themselves, the "example" plug-in. I think they don't want to incorporate it because they don't want, at this time, to support it fully. I don't think I would either if I was in their shoes. It could and would be misused by beginners, perhaps dangerously. But that doesn't mean it's a bad thing.

As FileMaker evolves it incorporates more powerful tools. We are just now in 8 being given a few tools to dynamically address external files, using script Variables and functions like Get (DesktopPath). In my opinion this was a long time coming, and rather limited in its reach; though what is there is very well done (as it almost always is).

Plug-ins have stepped in to fill that need (and others) for years. I'm grateful to plug-in creators for extending FileMaker ahead of time. Especially those like Gaston, who, like earlier David McKee, make (made) wonderful tools available for free (or donations, or low cost).

Yes, there could be compatibility and installation problems. But if it needs it, then the business you are working with will understand. People are usually happy to be able to solve a previously intractable problem. They understand (for the most part) that maintenance is necessary for complex projects.

I use eventscript with no problems whatsoever.

I do not understand the generalisation that one should do a long winded workaround when functionality can be added that is both reliable and economical.

Would the people who propose this approach still do the workaround if an event driven facility was available in native FM. I think not.

I would like to take this opportunity to thank Homer for his product and for enriching my FM experience

Phil

But event-scripts isn't just event-scripts ...the tough part to cope with is the ownership of the record in a multiuser scenario!

Is a change in one users fields likely to execute scripts on several other users machines, while at it ...making an extra layer of record locking of data already owned by someone else.

Not to mention if you regret the changes you thought were appropriate initially ...making all sorts of rollbacks in records other users are in ...which accidentally should depend on the record you're in.

As it is now do you work in a sort of scratchpad, to which you finally can commit the changes ...but if you continuously change something and commits behind the screens will the burden on the hardware be much much larger.

Let us get some ways you cope with these issues with your event scripting plugin, that follows changes in a calcfield live regardless of how far in committing the records details has proceeded???

Perhaps you can pinpoint the very text in MigrationFoundation's chapter on multiuser environments that makes what you DO perfectly alright.

http://www.filemaker.com/downloads/pdf/techbrief_fm7_migration.pdf

--sd

Soren, I'm building databases since 1988 and I never heard as many empty arguments. Unless you have true cases or true examples, I'm not gonna talk database concepts with a sound engineer...

Honestly, I don't understand your point because the articles that you suggest don't really have a link with the current topic. Sorry!

Two things to consider:

The informal fallacies considered here are patterns of reasoning that are obviously incorrect. The fallacies of relevance, for example, clearly fail to provide adequate reason for believing the truth of their conclusions. Although they are often used in attempts to persuade people by non-logical means, only the unwary, the predisposed, and the gullible are apt to be fooled by their illegitimate appeals.

From: http://www.philosophypages.com/lg/e06a.htm

Rules for a critical discussion

Rule 1: Parties must not prevent each other from advancing or casting doubt on

standpoints (p. 284).

Rule 2: Whoever advances a standpoint is obliged to defend it if asked to do so

(p. 285).

Rule 3: An attack on a standpoint must relate to the standpoint that has really

been advanced by the protagonist (p. 286).

Rule 4: A standpoint may be defended only by advancing argumentation relating

to that standpoint (p. 286).

Rule 5: A person can be held to the premises he leaves implicit (p. 287).

Rule 6: A standpoint must be regarded as conclusively defended if the defense

takes place by means of the common starting points (p. 288).

Rule 7: A standpoint must be regarded as conclusively defended if the defense

takes place by means of arguments in which a commonly accepted scheme of argu-

mentation is correctly applied (p. 289).

Rule 8: The arguments used in a discursive text must be valid or capable of being

validated by the explicitization of one or more unexpressed premises (p. 290).

Rule 9: A failed defense must result in the protagonist withdrawing his standpoint

and a successful defense must result in the antagonist withdrawing his doubt about

the standpoint (p. 291).

Rule 10: Formulations must be neither puzzlingly vague nor confusingly ambig-

uous and must be interpreted as accurately as possible

From: http://scholar.google.com/url?sa=U&q=http://io.uwinnipeg.ca/~walton/papers%2520in%2520pdf/03interrogationdialogue.pdf

In other words, which of my questions will you have clarified?:

--sd

So if I understand your point of view, if the functionality is not built in FileMaker, then we should simply forget about the missing functionality or use another complex method to accomplish a workaround

This is not correctly interpreted, I suggests making a more normalized design which usually cures the dire need for event trigging!!! I'm not speaking of adding complexity but instead avoiding to add fixes or remedies to inadequate structures.

--sd

Way back in September I posted my discovery that, at least on MacOS X, it is trivially easy to modify a field without triggering an attached event script. Just close the window or quit the application. Not one comment has been posted about this, which I find distressing as it seems that a lot of people are using this script to enforce business rules.

Invisible buttons aren't always reliable either, since the field can often be tabbed into. What's really needed is a "mode" to force the user into following the procedure, possibly with initial data entry into global fields to ensure integrity.

Mode-ism -- especially modal dialogs -- have fallen quite out of favor recently, but there are times when some kind of modality is needed, though not necessarily through a dialog.

This is where the design of a good interface becomes challenging, because it has nothing to do with fancy faux-metallic graphics or colour harmony. It's about process anddata integrity, and it requires a great deal of thought and experimentation and user testing.

http://www.fmforums.com/forum/showtopic.php?tid/169561/

Homer,

You do not have to debate anyone. Participation here is strictly voluntary. If you disagree with a given response, post a better one, and include your reasoning. Even a new-bee understands very quickly that there are usually more than one way to skin the preverbal cat in FileMaker. If you have a problem in how a fellow member posts, you are NOT required to respond to their posts, in fact, you can skip their posts, or put them on your Ignore List.

Members of this Forum have agreed to abide by a few simple rules. These can be reviewed by going to the Menu, and clicking on HELP.

As a reminder, no one likes to be attacked publicly, and I'm sure that others were as offended as I was with your response "I'm not gonna talk database concepts with a sound engineer...", which implies that you are in someway superior to anyone who list their occupation as something other than Developer. As far as I'm concerned, what a person does for a living, isn't relevant to their skills, knowledge, or ability in FileMaker, and we have several members that have listed their Occupation as something different than Developer, it certainly has nothing to do with their support.

Speaking of Support. I check your previous posts, because none of them stood out in my mind. I found that curious considering your credentials reflected in your profile. I noted from that review, that all of your post have the underlying theme of your plugin, except the maybe tip on tabs.

Soren on the other hand, has posted over 1100 times, offering his assistance when ever he could. Most of his post are Right On, although you do have to read through a meandering post on occasion to find the pearl. No offense intended Soren, I have learned a lot from you.

Lee

As a rule, I never get into philosophical arguments with a person whose name I cannot pronounce. :

"Rule 5: A person can be held to the premises he leaves implicit (p. 287)."

Elvis has just left the building?

BTW Homer has gived us ( the FileMaker community) a [color:red]gift...

and I can't understand why someone has to critic him or his product !

An italian proverb say: " A caval donato, non si guarda in bocca" something like: "To donated horse, it is not to watch in mouth".

So many people likes EventScript... and not only in Canada !

It's neither a critic of him nor his product, but instead the use of it - which in my opinion is iffy.

Danielle you are apparently a keen user of the product, then shouldn't it be too difficult to reasure me when i sounds like an old woman. I have given sevaral questions which isn't real arguments since it's a line of interrogation. Could you help me??

--sd

BTW Another proverb says: "Beware of greeks bearing gifts"

Hi Soren

i wish to point to this:

Rule 9: A failed defense must result in the protagonist withdrawing his standpoint

and a successful defense must result in the antagonist withdrawing his doubt about

the standpoint (p. 291).

I simple don't agree with this rule...

We aren't in war, but we are in cooperation to solve problems and, may be, to advance our knowledge.

I can understand your point of view, however I'm not so contrary, as you are, to the use of plugins.

May be you are right and I'm wrong, but why we have to argue ?

"CUI PRODEST"

We have to go on and raise !

You said:

Could you help me??

Yes, be less drastic ! (in the use of plugin as in the use of repeating filelds : )

And no, for me, EventScript isn't a Troian Horse !

P.S.: what is the meaning of "iffy" ?

Unless Chris, the original poster, has some additional followup questions on this topic, it is time to put this topic to bed.

Lee

I think there are strong points both in favor of using an event plug-in, in some possibly rare circumstances, but there are also serious dangers in using them casually.

Vaughn pointed out that it is easy to bypass the script. Which, if you're counting on it for serious data entry, such as updating transactions, could be a disaster.

It is also very easy to run the script on the wrong record. So, the challenge is, who can post an example file which safely uses an event plug-in (any of the free ones); let's say an "after event"; one which cannot be easily broken or bypassed; or at least restores data to what it was if it fails; or with documentation on how to safeguard. This is what is really needed.

Hey guys, I'm gonna be polite! I promise.

I didn't have the intention to be rude against non-developer people and I sincerely want to apologize if my sentence can wound someone! :

(by the way, my sentence is beginning by "Unless you have true cases or true examples, ...")

Mr. Jones! I'm please to suggest an answer to your objective question.

On the 4th tab named "Reactions" of our file named "EventScript Samples.fp7" I think you will find a persuasive demonstration of what you are looking for.

This demo-file were created about 15 months ago and it is provided into the downloadable who includes the EventScript plug-in itself (free for everything).

Actually, the script triggered on this Reaction-demo (4th tab) is more an "assistive process" because the real reaction locking is insured by a FileMaker validation rule in the field called "SomeContainerField_RVX". The rule in this case is "not empty" (with a 'strict validation' option) but I guess any clever validation rule can be handle as well.

You will notice that after-update events can be reproduces in the Auto-enter option OR in the validation option for a non-calculation field.

I will be very happy to know how someone can quit this reaction process without having to respect the validation rule. I think this is almost impossible!?

Of course, making a "force quit" on the FileMaker processID OR closing your computer is going beyond the scope of this demo. :

I know there's some caveats with the event-based programming. And I'm not saying that triggered scripts are the answer to every problems. But yes, there is awesome things we can do with event-based programming.

As Daniele said, there is no witches under EventScript, just clean and kind C++ code intended to help the community. Another promise!

P.S.: what is the meaning of "iffy" ?

I would use 'iffy' to infer that some quality or other of a process or product at best needs careful consideration and at worst is potentially unreliable

HTH

Phil

Edited November 22, 200520 yr by Guest
Trying to help while treading on eggshells

Thanks, Phil

so this topic, as it is right that it would be, is now in the Main page of the Forum.

Hot Topic:

Most recent hot topic is "Triggering a Script Upon Data Entry" with 27 replies.

is going beyond the scope

This was actually the only thing that needed to be established ...the premissses within which your thing behaves as expected. You can't take the discourse for granted when a tool has such a flat learningcurve.

Unfortunately, I know thousands of developers who dont' share them.

http://www.nizkor.org/features/fallacies/bandwagon.html

So please, don't blame me for this weakness and don't blame me for having to program and support an external free plug-in !

http://www.nizkor.org/features/fallacies/appeal-to-popularity.html

by the way, my sentence is beginning by "Unless you have true cases or true examples, ..."

http://www.nizkor.org/features/fallacies/burden-of-proof.html

You could have started off this way instead: Following document argues against methaphoric interfaces http://www.acm.org/pubs/cacm/AUG96/antimac.htm

The GUIs of contemporary applications are generally well designed for ease of learning, but there often is a trade-off between ease of learning on one hand, and ease of use, power, and flexibility on the other hand. Although you could imagine a society where language was easy to learn because people communicated by pointing to words and icons on large menus they carried about, humans have instead chosen to invest many years in mastering a rich and complex language. Today's children will spend a large fraction of their lives communicating with computers. We should think about the trade-offs between ease of learning and power in computer-human interfaces. If there were a compensating return in increased power, it would not be unreasonable to expect a person to spend several years learning to communicate with computers, just as we now expect children to spend 20 years mastering their native language.

The only problem here is that the question was raised by a newbe!

--sd

Unless you have true cases or true examples

I think I have one - actually! Take it that the modification of a field trigs a script that creates a new record by duplication in the same table ...how will you prevent this recursion from looping endlessly???

--sd

Edited November 22, 200520 yr by Guest
Forgot "duplication"

I don't want to interrupt the current thought process that this post has evolved into, but at the same time I did want to give my thanks to Phil for pointing me in the direction of the EventScript plugin. I liked the idea of the invisible buttons as well, but it just seemed that they would be easy to "lose" or misplace sort of speak. Additionally, I'd just like to say that what I am using FMDev for was definitely not what it was intended to do. My project is more making an interactive program than a database solution.

~Chris

P.S. That last part was in response to:

lets get the script that need triggering pasted up here, so I can be shaken in my beleifs

My project is more making an interactive program than a database solution.

So it's way out of the database realm, where constency in storage of data is the big issue ...in my opinion is there other far more obvious products to use for such a purpose:

http://dreamcard.runrev.com/

...comes to mind, or if you wish to fire on all 8 cylinders - Runtime Revolution from the same company.

--sd

Ideally I'd program everything from the bottom-up in some form of C or Java, but

a) that would take way too long for the timeline

: this is a basically my first job out of college and I do what they tell me.

Thus I use the program they want me to and have purchased already.

~Chris

OK Soren

I have attached a sample file of my current development project.

I have hesitated to do this so far because you guys are so advanced compared with me that I am frightened of looking a little silly however I think it gives a perfect example (to me anyway) of where event scripting maintains the integrity of the data that the user sees.

Here goes:

If you select prepare a quote and then single sheet you will be taken to my central layout.

Press the calculate button and some data will be revealed in the panel above. This data is a series of calculations that are prepared based on the data entered in the rest of the layout.

If you change any field on the layout that materially affects the calculation, on leaving the field the resulting calculation disappears (try changing any field in the finishing section then click out of it). This is because the calculated results now are not representative of the data entered.

I realise that, by the use of calc fields, I could make the calcs change as the data changed but I need the user to press a button because I need to check that the change that they have just made makes sense.

I do this through my calculate button. I want to force them to reveal the answer so that I can check one entry to any number of other entries in an effort to guide them through any potential mistakes they might have made. It is my equivelant of being stood over their shoulder checking their work as they go along.(change the entry for 'folds' under 'finishing' to anything greater than 0 and press calc for an example of this)

I also realise that I could probably achieve the same result through validation at field level but how complex would that be for anyone to follow.

As it is 1 simple script with a series of conditional if's saying if 'a' then you can but if 'b' then you can't and if 'c' then maybe you can or you can't but here's your choice.

All I do know is that this was incredibly easy to achieve with eventscript and my end user cannot see a price that does not reflect the data on the layout.

I would appreciate your comments. If my case is really bad then I will take it on the chin with no problems

Kind Regards

Phil

ps please ignore all other aspects of this file because it is in the very early stages of development and also I had to strip a lot of stuff out of it to get it down to a downloadable size.

ziptest.zip

I have to agree with Soren. When I started with FM I too thought plug-ins were 'the cat's meow' but have come to find that managing them overtime is a nightmare. I probably own 10-15 developer plug-ins and another 5 or so single-user ones. At first everything is easy with them but here's some of what you run into...

- They all license in different quantity price breaks. You never know when you will need to update.

- Some are single-platform and some are cross-platform. If you are developing for only one platform then no problem, but if cross-platform, then that's another thing to manage.

- They all validate licenses in different ways. Some use external text files, some provide a quantity controlled plug-in and some register through a script step.

- They may have a limited life. A plug-in developer may write the plug-in for a certain version then not support the next one. If they update their web site or answer their email (which MOST but not ALL do) then great, otherwise you don't necessarily know what results you will get.

- You need to keep them somewhere and manage the plug-in revisions that you do get. Since FM has container fields, this doesn't sound so bad, but over years it may still be difficult to know what's what.

- Even if an older plug-in is still usable, you run the risk of losing the documentation and the plug-in becoming worthless. (Not all of them are 'main stream'.)

- Most plug-in developers never notify you when they update the plug-in. To assure you don't miss a free update, you need to check all the sites for all your plug-ins every 3 months or so.

Of course all of this is overcome by proper documenting and storage, but ask yourself... with the software licenses you have now, do you know exactly what software is on what computer and where the raw download file (or CD) for it is? If your answer is not absolutely Yes, then you will probably come to see the light of avoiding plug-ins.

FileMaker has some short comings, and I still use plug-ins, but the time I spend trying to identify an internal solution to the problem often proves to be more cost effective than purchasing the plug-in (not to mention the time to manage it).[color:yellow]

Guys, I gonna be the happiest man on this planet the day FMI will decide to place this 16k of code (I mean the .fmx under Windows) into the core of their products.

I don't want to be the scapegoat for the plug-in industry because there is actually great PIs on the market fixing weaknesses that FMI doesn't want to be responsible for. Did you realized that some people out there is making a living of PI development !! So please, be careful when you talk about plug-ins and make the necessary distinctions.

If you want to discuss about EventScript, then it is OK but please do not pretend very bad thing based on totally empty allegations. In my country, one calls that: slanders. We are not running a suit of intension here.

About your points Jeff, you are right ! It was difficult in the past to maintain and deploy plug-ins over a large network. But now, FMI is providing the PI called 'Auto-update' who is installed by default on every FileMaker Pro and Developer/Advanced. This PI is doing a great job and it makes PI management a real charm. Here's some links to get more details : http://filemaker.com/downloads/pdf/fms7_auto_update.pdf and http://clevelandconsulting.com/support/viewtopic.php?p=959

As I stand before, I'm not speaking for PIs in general but EventScript is a free plug-in so you doesn't have to consider license registrations with ES. You deploy and you start using intelligently, that's it.

I have to go to work now. In theory EventScript is supposed to be my hobby !! :

I realise that, by the use of calc fields, I could make the calcs change as the data changed but I need the user to press a button because I need to check that the change that they have just made makes sense.

Hi Phil

Try to investigate this template, that although it's for a previous version - stille has a lot of bite to it!

http://www.filemakerpros.com/MultiValidate.zip

Next issue I wish to raise is your clearing of fields, not a particuar script"worthy" task - when you take a look on this:

http://www.clevelandconsulting.com/support/viewtopic.php?t=264

...now the syntax could even bring big lads to tears, so to prevent the backslashing do I usually instead do it like this:

Evaluate(Case(0;0);triggerfield)

And if you need just one of many fields...

Evaluate(Case(0;0);triggerfield1 & triggerfield2 & triggerfield3)

The reason for Case(0;0) is that it inserts a NULL value in whatever fieldtype you may wish even time or datefields.

--sd

Thanks Soren, I will go have a look when poss

Phil

If you want to discuss about EventScript, then it is OK but please do not pretend very bad thing based on totally empty allegations. In my country, one calls that: slanders.

I raised a question of dealing with cascaded and recursive event trigging, which both can lead to loss of focus. You didn't find anything in Ilyse Kazars part that makes you caution potential users of your product ...But there's a great deal to be learned about the shifting of record ownership during the process of scripting:

http://www.fmforums.com/forum/showtopic.php?tid/171699/post/183953/hl//#183953

I would say such looping controls is not uncommon in your target market. You should take a look at the way Phil uses your plugin and makes native valiations redundant. I'm not saying that in his case some kind of scripting isn't required, but a lot of the dealings does not require scripts at all!

--sd

I'm a bit late Phil but here's some comments about the file you proposed to us. Maybe it could be of some interest for you?

First, I'm commenting your work only on the triggering-script part. I believe it is a solution that promises to be great but the current matter is not on the scripts, on the graphical look and feel or on the structure of your database. You placed a trigger that hides the calculation results as soon a user is changing the quote's details so I'm commenting this part. :

I think every calculation you created to launch the "hiding script" can be simpler. Instead of writing :

If ( Get ( ActiveFieldName ) = "GCE_how many out" ;

If ( S4HU_EventScript(Get (FileName ); "set invisible on" ; "" ) = "";

GCE_how many out; GCE_how many out)

; GCE_how many out

I think you can actually use something shorter like :

// Solution 1

If ( Get ( ActiveFieldName ) = "GCE_how many out";

   GCE_how many out & S4HU_EventScript(Get (FileName ); "set invisible on" ; "" );

   GCE_how many out

)

OR another equivalent is :

// Solution 2

GCE_how many out &

If ( Get ( ActiveFieldName ) = "GCE_how many out";

   S4HU_EventScript(Get (FileName ); "set invisible on" ; "" );

   ""

)

You can choose either one.

The idea in an auto-enter option that is used to trigger a script is :

1. Providing to FileMaker the necessary auto-enter value for the current field (here we are using the field itself as the auto-enter result) and

2. to trigger a script by the same opportunity.

In your calc, evaluating if EventScript will return an empty value (your second If (...) = ""; statement) is not required nor useful.

This condition can be used when you need to know right away if the target script was launched correctly. This is an immediate execution feedback in the calc itself but I don't think you need it here.

Another comment is about the fact that changing a value on the quote while the totals are shown then clicking directly (without commiting the record) on your Calculate button will hide these totals. Where I was expecting to see the news totals (refreshed and shown). Of course the user can click twice on the Calculate button but it is a bit strange !?

This phenemenon is caused by the priority in the FileMaker execution stack when multiple scripts are running. If this hiding-concern is a real problem, just tell us and we will be able to find an easy fix for this.

HTH.

Edited November 24, 200520 yr by Guest

Hi Homer and thank you for your advice. The double clicking issue is one that I have just not got round to fixing yet but I should be able to sort it.

Thanks again

Phil

Here is a solution. It does not work with radio buttons but a Pop-Up Menu instead. It uses an invisable button, the optional script parameter, and a script to track entry and changes to a field defined as a pop-up menu. If nothing else, it shows what is possible without the use of a plug-in.

Couple of notes: Entry field must not be in tab order and the script must exit the entry field so the value cannont be changed without running the script.

Sample.zip

Edited November 25, 200520 yr by Guest

Let's not forget the ubiquity of the internet paradigm. Almost every computer user in the word expects a "search" field to actually "search" instantly when they press the Enter button. Show me how to cause an "intelligent" search to occur in the current active set without resorting to a portal. While portals are very good things, they are not good for some things. Yes you can force a portal to look and feel like a list view but it will not really perform like a list view. And setting up a "search" through a filtered portal is a real effort in development involving multikeys and recursive functions to break down the data in such a way that it will at least act like a good scripted find. Why not just have ONE global "Search" field and ONE triggered script to perform the search anywhere within the solution? Why should a user have to grab the mouse and click on a "GO" button when the enter key is already under their little finger?

Why should a user have to grab the mouse and click on a "GO" button when the enter key is already under their little finger?

Perhaps the right response, but havn't landed in the wrong thread? ...wasn't it meant to add perspective to this thread instead?:

http://www.fmforums.com/forum/showtopic.php?tid/171496/post/186673/hl//#186673

Well if my assumtion is right, comes remapping of keyboard shortcuts to mind! Otherwise didn't I get your point!

--sd

On second thoughts, it must be the same a Vaughan says here:

Mode-ism -- especially modal dialogs -- have fallen quite out of favor recently, but there are times when some kind of modality is needed, though not necessarily through a dialog.

This is where the design of a good interface becomes challenging, because it has nothing to do with fancy faux-metallic graphics or colour harmony. It's about process anddata integrity, and it requires a great deal of thought and experimentation and user testing.

I wouldn't deny that the post nitendo generation could easily live with a commandline in $bash frame, as long as a girl in her underwear poses at the wallpaper behind frame where the unix geeking goes on.

...Doing all kinds of filtering a.k.a. curl | sed .... making all the relevant data pop up with the speed of lightning just after pressing enter... But is filemaker not more meant to fall into the methaphoric interface cathegory??? Where mySQL and postGreSql probably better suits the "enter" pressers??

--sd

Edited December 17, 200520 yr by Guest

Would you mind explaining part of your script? Specifically, the Pause followed by a Loop and If statements.

My try, ends up in an endless loop.

the pause is required to let the script the user interact with the layout(without the pause it will loop forever) the If statements have to be carefully to check for a change in value in the field or a change in what the active field is (exiting in either case), a pop-up menu will pause the script when open but the loop is required to allow it time to open.

Hope this helps (the is very limited solution, but usefull for stuff like causeing the screen to refresh after changing a value in a pop-up menu)

Oh, I have tried this with several versions of FM and this behavior is slightly different in each. this example was done in FM8.

Edited July 25, 200619 yr by Guest