Automatic script trigger?

[John Chamberlain]

I have a file that executes one of two scripts (depending on a test) in a related file. At the moment I have to begin this process with a button to execute one or the other of these scripts, then return to the file I am working in.

What I would like to be able to do is have these scripts run automatically whenever a new record is initiated. Anyone know how?

[dazlunn]

You can easily do this with a plug-in..

http://www.dacons.net/fmplugins/scriptfire/

[Genx]

A better choice might be one of 3 free plug-ins EventScript by Soft4Humans, DoScript by myFMButler or ZippScript uhh, i forget this guys name...

Anyway, do a google search for any of those and you'll get what you want (though scriptfire has other uses).

[gbrown]

Ok, so we have Scriptfire from Dacons, Events 4.0 from Waves In Motion, and the three free plug-ins listed above. Obviously one difference is price and from the little I have read on each the paid versions have more features. i.e. Events 4.0 can also send emails, event scheduler's, etc. I am building a distributed solution so dependability is very important. Anybody have any thoughts as to the best choice here? Both from dependability and features?

Thanks

Greg

[John Chamberlain]

Well, it appears that Events 4.0 and all of the free plug-ins only work on FMP7 & up. I am running FMP5, but could upgrade to FMP6.

Because I am doing this as a volunteer for a non-prof, and my file is developed on a Mac then run on Windows XP, the Scriptfire solution would cost $78 (one for each platform).

Guess I will just stick with a button script.

[Genx]

Ah right, sorry ... Missed your version

[Genx]

"Anybody have any thoughts as to the best choice here? Both from dependability and features?"

I've used all of the 3 free ones, they all offer similar functions and are all dependable so... If you want a company that isn't going anywhere i suggest either DoScript or EventScript.

Re the sending email... Ah, 1) Fm has a built in feature for that remember? 2) I highly doubt you'll be able to send anything beyond plain and possibly rich text emails.

Oh and by the way, I looked at the feature list for Dacon's script fire and it offers nothing that DoScript can't achieve in different ways.

Edited January 16, 2007 by Guest

[gbrown]

Yes, FM can send email - but not without the help of the users email client. And since Outlook is going to throw a security pop-up whenever you try to auto send an email from another program - there is not much since in automating it. Yes, you can override the security setting in Outlook but many people won't want to disable this feature. I suppose you could use the Smartpill plug-in in conjunction with one of the free trigger plug-ins but from what I've read developing a distributed solution with a lot (some people say any at all) of plug-ins is a serious no-no.

[dazlunn]

Quote...plug-ins are a serious no-no

You are right that multiple plug-ins are a serious no-no but single plug-ins when accompanied with adequate and measured testing should be fine... I have always found that post release issues could have been prevented if the test process had been more adequate/comprehensive.

However, I totally agree that multiple plug-ins are something to be avoided. a plug-in should be used only when you have exhausted all other avenues, and never used as a short-cut to proper coding! No matter how much learning you are 'in essence' trying to avoid...

[Genx]

RE: Developing without Plug-ins... Rubbish that it's a serious "no-no". People who try to distribute them by saying "Here's a filemaker file, install it by copying and pasting it on your computer" will advise you that it's a serious no no because then the user is expected to also copy and paste plug-ins to the FileMaker folder and then update them...

This can all be done with an install package, and they can be auto-updated with scripts. FileMaker has been plug-in enabled for a reason.

Further if you look carefully, FileMaker itself ships with two plugins - Web.fmx and xDBC.fmx -- both of which it rely's on to perform functions it wouldn't be able to perform without them.

Then of course there's the IWP group who says don't develop with plugins but in all truth, IWP has very limited uses in the first place and no one developing a real app would consider using IWP to facilitate the sole - client-server interaction.

[dazlunn]

I think you're agreeing with my statement except that you are talking about distributed systems on mass, and I'm referring to the context of stand alone systems tested on a customer's site when I ,as the developer/installer, will do the 'Donkey Work' such as loading plug-ins etc...

In essence, I am trying to explain that plug-ins should not be used as lazy short-cuts... although this probably did not expose itself in my original post?

[LaRetta]

Script the new record creation (as it should be anyway) and then the plug-in here is moot.

[John Chamberlain]

OK LaRetta, but that leads back to execution of the script with a button, which was what I was trying to avoid.

Man! I sure never thought my simple minded question could stir up this much interest! Thanks to all!

[dazlunn]

Ouch!

You are right, but FM5 was before my time, what if someone creates a new record using the menu and not a button.

I know nothing about FM5!

[LaRetta]

John,

How would you determine the action to fire it if not by User action? Does the computer say, "Gee, I think I'll make a new record?" SOMETHING must happen by a human to start it, no? If you wish to fire a script when a calculation changes then that is another matter (and plugin WOULD be required). But you asked to have the script fire when a new record is created.

Are you instead wanting to create a new record when something else happens? Maybe clarity on your needs would help here. It is a waste of time to discuss a solution when the problem isn't clearly known. MOST times, a plugin isn't needed. MOST times, it simply takes getting clarity on the best approach. ALWAYS, record creation and deletion should be controlled and the status area removed (and privileges restricted). If you don't do this, they will be surprised when a User executes Delete All Records from Menu and that CAN'T be undone.

[gbrown]

Sorry John - didn't mean to start a thread within a thread and mess up the focus. Although this plug-in discussion is a good education. I have some questions based on the above but I'll move it over to the plug-ins thread.

[LaRetta]

Nah, we're still determining the focus. An event-trigger plugin MAY be required here but in most cases there are native alternate solutions. Plugins are NOT a no no; but they need to be used prudently. And I felt options should be pointed out and considered. :wink2:

[dazlunn]

Actually I think it may have been me that wandered off the focus... Sorry for that.. (I'm new so spare the thrashes!)

LaRetta seems to be coming at this from the same standpoint as me, just with more clarity!

Genx also has a good point in that often the difference between 'Good' solutions and 'Great' solutions can simply be a well deployed plug-in (at least I think this is what you meant - and I agree!)

I am not anti plug-in, quite the contrary in fact, but I do believe in 'horses for courses' and 'not putting square pegs in round holes'...

Simply my logic was:

This is one guy enquiring about one solution, needing auto-scripting, on a FM5 solution (likely it's stand alone), and me expecting that FM5 functionality is probably limited (admittedly without knowledge!)

Therefore I suggested Scriptfire in my first post...

By the way, it's a good plug-in I have used with no issues so far..

[Genx]

Despite my little tirade above, I use plug-ins very sparingly. All i normally include is an event-trigger and dacon's mail.it plugin. The event-trigger is used sparingly - frankly because I almost never need it unless I have to implement something that really just isn't possible with FM by itself.

So I just agree with everyone :

Anyway back to the point, why are we executing a script on record creation -- do you not have a script that you can attach to a button to say... Add New Record & Do something else??

[Søren Dyhr]

I have a file that executes one of two scripts (depending on a test) in a related file.

I wondered if we could get the mentioned scripts to scrutinize here, to get a more calc'field'ish approach to the same task???

If say it's in the vicinity of the creation or deletion of join table records, would it be urgent to point at this:

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

Which BTW is in fm5 format!!!

--sd

[John Chamberlain]

Maybe an explanation is in order. There are four files involved.

The Bio file contains data regarding both Employees and volunteers for a hospice organization (the one I volunteer for)

The Bereavement Letters file generates weekly letters, and other reports, regarding survivors of a deceased hospice client

The Contacts file is a history of contacts (either phone calls or face-to-face visits, to the survivors

This ZIP file is used to auto enter City and State data in both the bereavement and Bio files

The Bereavement Letters file has two fields, Recent Volunteer Contact & Recent Staff Contact – these fields are used for three different reports. Up to now, I have been copy/pasting these from the portal on a every other day basis. I grew tired of this, and knew that it was subject to error, so I wrote the script solutions named

Enter Contact in Bereavement File (in the Contacts file) – Call this script A

Paste Volunteer Contact (in the Letters file) – Call this script B

Paste Staff Contact (in the Letters file) – Call this script C

Script A determines whether the name of the Contactor is a Volunteer or is a Staff member – it then goes to the related record and triggers either script B or C, then returns to the Contacts file. Button X in the contacts file initiates the process. What I would like is to automatically generate Script A when the MRECNUM (the deceased Patients ID number) field is exited.

Attached are reduced copies two of the files,I will attach the other two in the next post.

[John Chamberlain]

Here are the other two files

[LaRetta]

No files attached. You are using copy/paste, John? The field MUST be present on the layout for copy/paste to work (which may or may not contribute to your problems). The first thing you need to do is ditch using copy/paste and instead use Set Field [ ] but we'll know more once we go through your files. Hang in there. :wink2:

[Søren Dyhr]

This isn't hardly a scripted matter at all, but instead a structural problem, although fm5 is a little crincled when it comes to tunneling, but a lot of this is down to the layouting and reporting methods used.

Having various copies of the same data, in several locations is wrong!!!

--sd

[John Chamberlain]

I agree that cut/paste is no way to do this, which is why I wanted a scripted solution. I am admittedly self-taught, and I know there are many things I don't understand that you guys take for granted.

The two fields are needed in the Letters file to generate some reports that depend on knowing the most recent Staff and Volunteer contact names.

Is there any chance using Lookup fields might work?

Did you get any of the files from either of my previous two posts? Since they upgraded the site, I have not been sure how to attach files.

[LaRetta]

John, your files didn't attach. Be sure they are zip format. Select Manage Files (inside your post at bottom). Once you select the file, click ADD and then you must also click FINISHED then finishing your post by also saving it.

[John Chamberlain]

Forgot to ZIP the files! Here are the first two

Bereavement_Letters.zip

Bereavement_Contacts.zip

[Søren Dyhr]

Well the two files are not related? They should be, and each letters text should be a new related record seen from the file containing all involved persons.

The way you have made it are you eagerly trying to avoid a many2many relation, and jumps a lot of hoops to make statisitical records of which or the standard letters which have been send.

I suggests you make one file with all the persons and one with all the kind of letters each in it's own record, and you then start to link those joinrecords in yet another file, that beyond the two foreign keys have a date when the letter was sent.

In the join-records are unstored calc'fields taking care of pulling both the text as well as the recievers data from their repective files via opposite pointing relations (since you're on fm5). The letters layout is then done entirely in the jointable.

--sd

[LaRetta]

I agree with Soren, John, otherwise you will continue to jump through hoops to make your solution work for you. With a proper structure, FileMaker is FUN. Without one, you will be pulling your hair out constantly.