Jump to content
Sign in to follow this  
frigante

Plug-in makes layout design almost fun!

Recommended Posts

frigante

Hey, I just wanted to let everyone in on this amazing plug-in that comes with FM Developer.

 

It's pretty simple - it allows you to invoke a script when a field is modified.

 

Pretty simple, eh? But think of the possibilities..

 

If anyone is interested in learning more, let me know and I'll post it on my web site.

 

pc

Share this post


Link to post
Share on other sites
Maureen

Hello, that does sound great? What version of FM Pro is it for?

Share this post


Link to post
Share on other sites
frigante

Hi Maureen,

 

Yes, the sky's the limit with this one..

It's only for FM7 as far as I know - hope that doesn't disappoint, but having used FM since version 5, I'd say go to 7 asap not just so that you can use the plug-in, but because it really is a quantum leap for Filemaker users...

Share this post


Link to post
Share on other sites
Maureen

Thanks, that's what I was afraid of, I'd love to go to 7, I dream of it, I've put it on my wish list, but unfortunately, I work for a big coop, where everything takes 10 years to go through budger frown.gif

 

 

Thanks for the enthusiasm for 7 though, just makes me more sure I want to buy it for my own personal use.

Share this post


Link to post
Share on other sites
ew

I have FileMaker Developer, and I have taken a look at this plugin, but I can't get the sytax down for making it work.

 

Where did you find that part?

Share this post


Link to post
Share on other sites
FileMakin' Tom
Originally posted by frigante:

[qb] Hey, I just wanted to let everyone in on this amazing plug-in that comes with FM Developer.

 

It's pretty simple - it allows you to invoke a script when a field is modified.

 

Pretty simple, eh? But think of the possibilities..

 

pc [/qb]

Does this come with the purchase of FMP Developer 7 or must one order it from FMI?

 

Tom

Share this post


Link to post
Share on other sites
andygaunt

It comes on the CD with Developer.

 

Now, I know that prior to 7.0v2 if you used this plugin you could not use IWP.

 

Not sure if that has been fixed yet.

 

As to syntax, check good ol' reliable Databasepros.com in their resources section.

 

Click the new link at the bottom and you will see an example of this.

Share this post


Link to post
Share on other sites
frigante

If anyone is still looking for the plugins, I've posted them on my site: http://caira.ca - look for the "XMpl Plugins" link ...

 

As for syntax, I haven't really explored anything except for the StartScript function. It works in the field definition for whatever field you want it to work with.

 

You need to:

 

a) decide which field you want to have trigger a script.

b) go to the field definition, auto enter tab and choose to have a calculated value auto entered, make sure you uncheck the "Do not replace existing value of field" option.

c) enter the following syntax as the auto-enter calculation:

 

Case(not IsEmpty(FIELD); XMpl_StartScript(Get(FileName); "SCRIPT") & FIELD)

 

Where FIELD is the name of the field you're applying this to and SCRIPT is the name of the script you want triggered when FIELD is modified.

 

Note the following:

 

The Text field is concatenated to the end so it the data is not removed from the field. The Case statement is used to prevent the auto-enter function from evaluating when a new record is created.

 

 

Have fun!

pc

Share this post


Link to post
Share on other sites
CobaltSky

After reading this thread I have to say I'm still none the wiser as to how the plug-in has a bearing on designing layouts?!

 

But notwithsrtanding that - and before everyone gets too excited about using the example plug-in in their solutions - you might want to visit my comments at:

 

http://www.maclane.com/cgi-bin/ultimatebb.cgi?/topic/16/658.html

 

and perhaps avoid a mishap or two... wink.gif

Share this post


Link to post
Share on other sites
frigante

Hi Ray, and again, thanks for the warning. You'll see why I never thought of that pitfall in a sec..

 

You asked how this plugin has any bearing on designing layouts - think about this:

 

Any solution requiring anything more than simple data entry can take advantage of the plugin by assigning it to trigger error or entry checking scripts for each data entry field - if an error is detected, a message is displayed, etc...

 

Now think about a process where the data entry op is entering data and one or more pieces of data will determine which remaining fields need to be filled in - as soon as that deciding field has data and is tabbed out of, your script can determine what the next set of fields should be and can either 'grey out' the fields that don't need data or present a whole new layout with appropriate fields to fill out.

 

This is just one example, but I'm sure you can see that there are lots of other applications that this plugin can help out with.

 

pc

Share this post


Link to post
Share on other sites
CobaltSky

Hi pc,

Thanks for making the layout connection clear.

 

However if a user enters a value into a field and then (without first exiting the field) navigates to a different record, the script will fire and the user may end up viewing a layout which makes no sense at all for the data in the record that they are now on - possibly leading them to draw wrong conclusions or to make changes to the data which are not appropriate. Or they may be presented with a dialog which instructs them to make changes to values in certain fields, but (unknown to them) referring to a different record. The user may not even recall exactly which record they came from. :rolleyes:

 

If you are using the example plug-in to do this, you will have no contrivance by which to have the script identify which record its warning, layout switch or other action relates to, so you will have no way to prevent all sorts of bizarre, misleading and potentially hazardous events from occurring. Depending on the habits of the individual user, unintended outcomes may happen with greater frequency than you might suppose, and with consequences that are difficult to predict. :eek:

 

See my recent comments on the other thread for an alternative that may provide you with a way forward that is less of a leap into the unknown. wink.gif

Share this post


Link to post
Share on other sites
frigante

Okay, I know where our thinking differs.

 

I never clarified that when I write a data entry interface I never EVER have the operator work on live records. I've seen other people call this the "separation method" ... you know, any fields that hold entered data have a companion global field where the actual data entry takes place.

 

In fact, all of my data entry interface work starts with a script that omits all records from the layout the user will be working on. Furthermore, I make a point of giving as low a level of access for data entry level users thus preventing them from making mistakes of the data-corrupting variety.

 

Also remember that I am and always have been a Perl programmer (I still prefer db interface design and programming with EmbPerl/MySQL/Apache on any UNIX/Linux OS) before I ever delved into Filemaker so I'm already used to checking EVERYTHING before doing anything.

 

I appreciate your concern though, and it's probably good that someone out there isn't assuming everyone is as cautious as they should be.

 

Oh, I just wanted to add that the example plugin works best when used with a boolean-type field formatted as a checkbox - either 0 (not checked) or non-zero (checked) - that way you never have to tab out of the field! I used this technique to have a list of items in one portal disappear from the first portal and appear in another portal when 'checked' - no potential for disaster, no tabbing, just clicking!

 

I guess what I'm getting at is that the plugin, whether it be the example plugin or the zipp script plugin really helps overcome some serious design roadblocks from the past - you just have to be creative. And for those of you who are already creative, it'll be one more tool in your arsenal.

 

pc

Share this post


Link to post
Share on other sites
frigante

Okay again...

 

I've been playing with the zipp script plugin for the last while and found a weird catch to the record identification issue.

 

If I pass Get(RecordID) as a script parameter to the script I've triggered from a field in a record, then go to other records, collect info or whatever, then want to go back to the original record I came from using the Go to Record/Request/Page function by Calculation (=Get(ScriptParameter) which would be the value returned by Get(RecordID) originally passed in the trigger) it'll take me to the corresponding Record NUMBER.

 

So just pass the originating record number instead, right?

 

Well, what if my found set changes? All of the sudden that record number becomes meaningless...

 

Is there any way to go to a record by its FM assigned record id?

 

pc

Share this post


Link to post
Share on other sites
Sign in to follow this  



×
×
  • Create New...

Important Information

Terms of Use