Triggering a Script Upon Data Entry

[New to FM]

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

[Inky Phil]

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

[kam]

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.

[LaRetta]

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

[Homer]

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

[Søren Dyhr]

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

[Homer]

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 ?

[Raybaudi]

Hi Homer

[SlimJim]

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.

[Søren Dyhr]

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

[Søren Dyhr]

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

[Fenton]

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.

[Inky Phil]

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

[Søren Dyhr]

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

[Homer]

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!

[Søren Dyhr]

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

[Søren Dyhr]

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

[Vaughan]

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/

[Lee Smith]

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

[Vaughan]

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?

[Raybaudi]

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 !

[Søren Dyhr]

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"

[Raybaudi]

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" ?

[Lee Smith]

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

Lee

[Fenton]

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.

[Homer]

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!

[Inky Phil]

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, 2005 by Guest
Trying to help while treading on eggshells

[Raybaudi]

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.

[Søren Dyhr]

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

[Søren Dyhr]

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, 2005 by Guest
Forgot "duplication"

[New to FM]

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

[Søren Dyhr]

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

[New to FM]

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

[Inky Phil]

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

[FMDuck]

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]