Auto-Enter Calculation doesNOT enter in IWP field

[JamesL]

One of my fields is an auto-enter calcultion (simply autom. copy text from a just entered field).

Creating a new record auto-enter works well in FP7, but creating a new record in IWP and having entered text in the source field, the value never appears in the auto-enter field.

The FM7 help file indicates "For information about auto-entered data and FileMaker Pro web publishing, see the online manual, FileMaker Instant Web Publishing Guide".

However, I can't find anything in there on this subject, nor can I in the IWP Techbriefs.

So I wonder wether it is normal that the auto-enter calculation does not work in IWP, and where in the Guide it is indicated ? Or is there any reason why it does not work in my case ?

[seanc]

Hi Gus,

I can't really help you, but I can tell you that I have noticed the same thing.

I have a field setup to log changes to any of my data entry fields, which works by auto calculation. Works perfectly in Filemaker client, but via IWP its... unpredictable. It generally logs that something has happened, and by who, but tends to create several entries for one field, and no entries for other fields.

Haven't found a workaround yet.

If all you are doing is copying the text from the entry field, could you try using a lookup instead?

Cheers... Sean!

[JamesL]

Hi Sean,

Thank you for confirming me that you (and thus certainly other people as well) noticed the problem. So I followed up your suggestion and tried using a lookup (self join): in the meantime I found out that the result is not better.

Anyway, the lookup would not have been a right alternative for me: in my case the copied text should not change autom. along with changes made in the source (looked-up) field.

Just starting with IWP, I suppose the fields used on IWP layouts should be kept as simple as possible.

I'm still wondering whether the FM IWP Guide really mentions something about the Auto-Enter Calculation (and evt. about the self-join Look-up).

Hope you find the right workaround, of course best would be that FM has noticed this problem and will soon release an updater.

(See also my question about a problem with an Import Option: Splitting repeating fields into seperate records).

Best wishes,

Gus

[JamesL]

Simplest solution: turning the title label of the field into a scripted copy/paste button ...,

but even this workaround automation when executed in IWP works far slower and is visibly more complicated than ... a quick manual copy/paste in every new record.

[seanc]

Not sure that I follow what you are doing there.

So after you have created and commited a new record, you then hit a button to copy/paste the field? Not really automation.

Also, could you not use a set field script instead? Should be a bit faster/more reliable and not require both fields to be on the layout?

Cheers,

Sean.

[JamesL]

If it was not for IWP then the best solution is the Auto-enter Calculation, selecting the option "Do not replace existing value for field" in order to prevent overwriting data already present.

Sean, using the Set Field is indeed the best alternative, a simple script like this:

if destination field is empty, then Set (source) Field ...

But how can this script be auto-entered, I do not see how to avoid the use of a button in order to make it perform.

The scripted button works fine in IWP, but as you say, it is no real automation.

Is there something I'm overlooking ?

Cheers to you !

Guus

[T-Square]

I'm not sure I follow all the circuits in this discussion, but I notice that you are asking about auto-triggering your script. I note that Softwares For Humans has a free plug-in called EventScript which claims to do what you want. They're at: http://www.softs4humans.com/FMPro_Plugins.html

Will it work in IWP? I dunno...

[seanc]

The plug in may be an option, I haven't had anything to do with them so I'm really not sure.

I suspect that the best way to accomplish this might be a rethink of the work flow, considering the application from a web point of view rather than filemaker point of view.

In this case, possibly have a NEW button, which jumps to a data entry layout which has a SUBMIT button. That SUBMIT button could then run your script which commits the record, does the Set Field and then jumps back to the detail page.

You could possibly use the same layout with just some minor changes, having the submit button appear only when its appropriate using a portal.

A little more work on the filemaker side, but that sort of flow is generally how web apps work (such as entering the details at an online store checkout), and what web users would expect.

Consider this: How would you create your page if the status bar didn't exist?

Hope that made sense!

Cheers,

Sean.

[JamesL]

Sean and T-Square, Many thanks !

- If I understand well, the SUBMIT button still requires to hit a button.

- I downloaded the plug-in and will study its use.

I finally chose:

1) to maintain the original lay-out, which includes the field with the auto-enter calculation, this lay-out will be used for sharing files on the network.

2) a duplicate lay-out will be available for IWP use only; as the auto-enter calculation does not work here, I put the "if ... set field ..." button in front of the field.

[seanc]

Yes, the submit button is still a button, but its a button you will be forced (but in a nice way!) to use, rather than a button that you may or may not forget/bother/realise/etc to press.

You are welcome, hope we've helped!

[BobWeaver]

I haven't done very much with IWP so far, but I have had some success with auto-enter fields. The audit trail example (link below) uses auto-enter fields to do the audit trail and works with IWP.

http://www.fmforums.com/threads/showflat.php?Cat=0&Number=153729&an=0&page=0#153729

The original attachments in the top post don't work in IWP, but the one attached in my later post does work.

However, while testing this out, I noted a few things:

1 - First and foremost, the web browser is a static display of the record. You edit multiple fields in the record, and then submit all the data at once. On the other hand, a regular FM session is dynamic, updating auto-enter fields immediately after editing any dependent field. So, you need to take this into account when you have a complex auto-enter formula. You may need to include a case statement in the formula to control when it evaluates. Maybe something like this:

MyAutoEnterField = Case(<< condition needed to calculate >>;<<the formula>>; MyAutoEnterField)

I have successfully used this type of formula to keep the original value of the field unless specific criteria are met. But, it will depend on what you are trying to do.

2 - There is a bug in IWP which causes it to insert linefeed characters (0A hex) after line-breaks in any data on the layout when it's submitted. These characters can seriously interfere with any text calculations you may be doing. To fix this, use the Substitute function to strip out linefeeds.

3 - Because of the possible difference in field update order (item 1 above), I found that if I kept the auto-enter fields off the layout, things worked better. If you need to display the data from the auto-enter field, you could create an unstored calc field to get and display the data from the auto-enter field.