delayed calclulation

[lsmall]

I need to have a calculation performed after a delay. About 5-10sec once the new record is created.

I can't use "pause" in the Scripts because it must work over IWP.

Is there a way to incorporate a delay into the calculation? It doesn't have to be a precise delay. It just have to give the web viewer enough time to load a page before the calculation is performed.

Thanks

[Colin Keefe]

Can you be a bit more specific about why you need the delay? What's the usage and scenario here?

[lsmall]

I'll try to be concise.

This is a medical billing database that "scrapes" patient information from an html based electronic medical record on the hospital intranet. This loads into the filemaker web viewer. As it is now I have a script that uses getlayoutobjectattribute (web viewer;content) to extract the source from the web page. From that I parse the information to the appropriate fields.

The problem is that when used over IWP (which I need it to do so that I can use it throughout the hospital), it doesn't work. From what I have pieced together is that anytime a field is accessed, or a button and script are activated via IWP, the whole page including the web viewer reloads and getlayoutobjectattribute is performed when the web viewer is still empty. I can't use a pause, because script pauses don't work over IWP unless they are indefinite. With an indefinite pause, clicking continue over IWP, causes the page to reload again.

So basically I need the web viewer to load first, then to perform getlayoutobjectattribute WITHOUT the webviewer reloading. The only way I can think to get this to work is by incorporating a delay in the calculation itself.

Thanks

[comment]

I don't know of a way to delay evaluating a calculation. Can't you switch the order of things around a bit? For example, create a new record, fill it up and when committing check that the page has loaded. If yes, scrape the data and commit the record. If not, tell the user to wait a bit and try again.

Even better would be to import the data directly from the database where it lives, instead of going through HTML.

[Fitch]

The problem is that in IWP, GetLayoutObjectAttribute( "webViewer" ; "content" ) doesn't work: it will give you the source, not the content.

I've submitted it as a bug; you should too. The more people who submit a bug, the higher priority it gets (in theory).

[lsmall]

I think it actually might work and the problem is that the webviewer always reloads whenever any function is performed over IWP. I think the URL that is returned as "content" occurs because getlayoutobjectattribute is always executed too early so there is effectively no webviewer "content". The only way to test this is to create a calculation that executes getlayoutobjectattribute after a delay and avoids a reload. The delay calculation before getlayoutobjectattribute could be anything that would occupy the program for a few seconds. I'm just not saavy to know what kind of calculation that would be.

As for importing the data from where it lives--I have found where it lives and it looks as though it is XML, but I don't have access to it. I'm a doctor not an IT dude or software engineer. There is very little chance that the administrator would allow me to access this data directly, but I am planning to try for future use, but for now I am will continue doing it the inelegant way.

[Fitch]

If anyone has gotten the function to work I'd like to know. I tested it this way:

- make a web viewer with object name "webViewer"

- set the URL of the web viewer to a simple, fast-loading page

- put a field on the layout

- make a button that sets the field to GetLayoutObjectAttribute( "webViewer" ; "content" )

Now open the file via IWP. Wait as long as you want for the web viewer to load.

Click the button: your field will show the source of the web viewer (i.e. the URL), not the content.

How did you determine that "the webviewer always reloads whenever any function is performed over IWP"? That hasn't been my experience as far as I can tell, but I'm trying to learn more about IWP.

[Cabinetman]

I find the same thing..... and am looking into it further.

I set up 2 fields.

1 - a straight calc

2 - a set field by the GetLayoutObjectAttribute( "Web Viewer" ; "content" )

field 1 doesn't seem to recalc.

field 2 using the script only gives the url.

HHHuuuummmmmmmmmmmmm

I happen to use this myself but within the standard database mode. I strip a page and import to update records.

This my be a long workaround until an answer is found - but does it have to be accessed by IWP?

Can you log into the host computer using a program like 'LogMeIn' ?

An idea until one is found... maybe.

[comment]

How did you determine that "the webviewer always reloads whenever any function is performed over IWP"? That hasn't been my experience as far as I can tell, but I'm trying to learn more about IWP.

I don't know much about IWP either, so I fired it up - and I am seeing the same thing as lsmall does: clicking a button causes the entire page to reload, and the "web viewer" along with it. It doesn't seem to matter what the button does - even Exit Script or Set Variable behave the same way.

However, it's NOT the reload that causes the calculation to fail. I am not sure it can be even called a bug. Filemaker Help says:

The hasFocus, containsFocus, source, and content attributes behave differently in Instant Web Publishing. For more information, see the FileMaker Instant Web Publishing Guide

And the FileMaker Instant Web Publishing Guide says:

In Instant Web Publishing, the GetLayoutObjectAttribute function works as in FileMaker Pro, except for the following differences:

...

• When this function acts on a web viewer, the content and source attributes return the same value, a URL.

I don't think it's reasonable to expect more than that. After all, it's not a "real" web viewer - you cannot run a browser inside another browser. It's just an iframe element embedded in the page. It provides a nice visual simulation of the "real" layout, but that's where the similarity ends.

[Cabinetman]

I read that also after I posted last....

I think something like the TRIO URL plug-in will be needed to get the web pages until an XML file can be downloaded.

http://www.troi.com

I use it some as well.

[comment]

Plug into what?

[Cabinetman]

Plug into what?

:qwery:

... a little confused by your question....

Setting plug-in preferences

You can use plug-in preferences to enable and configure FileMaker Pro plug-ins. Plug-ins provide optional extra features to FileMaker Pro. Plug-ins may be available from FileMaker..... etc

Get the TROI URL plug-in for FMP.

Use it to get the content from the URL and download into a field.

Strip out what you need and import.

Or did I miss something in what he was trying to do?

(Which could be......... and if so.... )

[comment]

IWP?

[Cabinetman]

I guess it's me....

Isn't IWP = Instant Web Publishing?

He accesses an FMP database over the internet throughout the hospital.

So isn't there somewhere that the FMP program is installed on a PC with whatever database up and running?

[comment]

As I said, I don't know much about IWP (or plugins, for that matter), but it's difficult to imagine how the host (i.e. either FMP or FMSA) is going to know which site the client (i.e. a browser client) happens to be viewing "on the side".

[Cabinetman]

Tried this file with IWP and it worked.

However it does require a plug-in which is included in a layout.

You can install and use it unregistered for trial purposes.... and further if desired if you can live with the delay.

I may play some with trying to delay the calc. but haven't a clue where to start...

PS: don't know much about passwords so left it with just login -admin no pass...

web_viewer_test.zip

Edited September 7, 2008 by Guest

[Fitch]

Good idea, Cabinetman. Using Troi URL or equivalent plugin is worth a try. (I.e., clicking a button or possibly a calc field that calls the plugin, no web viewer required.)

From the IWP Guide:

"Typically, third party plug-ins can be used for web published databases if they do not attempt to display information to an end-user’s screen, if they do not require direct end-user interaction, if they do not interact with the FileMaker Pro user interface, or otherwise require interaction from end users."

However:

"When hosting a database with FileMaker Server Advanced, only use plug-ins that have been enabled for the FileMaker Server Web Publishing Engine. (In general, a plug-in designed for use only with FileMaker Pro will not be compatible with the Web Publishing Engine.)"

I'm using 360Works Email and SuperContainer plugins with FMSA/IWP; but you'd have to check with Troi to verify that their stuff can be deployed that way. (I'm assuming you're using server since you said you'll "use it throughout the hospital.")

PS: Thanks comment, for the correction on my "bug" report. Can't believe I missed that, must have gone bleary-eyed searching that IWP Guide so much.