Will this work if you are accessing the layout from FileMaker instead of a web browser?
I have done searches for IWP Limitations.
This is an unedited compilation of what was found.
Some limitations of Instant Web Publishing:
- Performance degradation for multiple users
- You may notice the system become less responsive with even a couple of simultaneous users.
- Fewer UI options
- Minimal or clunky workflows
- Requires FileMaker Server Advanced
- Yes, as previously noted, IWP requires FileMaker Server Advanced for server deployment; it won't run with plain-old FileMaker Server.
- Requires Internet Information Services (IIS) to be installed when deployed on Windows
Here are some of the challenges you will want to be familiar with before attempting the IWP option. This is not to criticize FileMaker or IWP; think of it rather as a friendly list of cautions.
- Pages will be static
- The entire layout will need to be redrawn pretty much any time the user clicks on something or when first entering a field on the page.
- Fields and text objects do not look the same in IWP as in FileMaker Pro (client)
- Drop-down menus are treated as pop-up menus (which, honestly, I think are ugly).
- Field sizes will differ from FileMaker. They will likely need to be bigger.
- Appearance and behavior of pages on an iOS device are especially different from the desktop browser.
- Conditional formatting does not work
- This will negate the handy portal row highlighting technique many of us use today.
- Buttons cannot be placed beneath other layout objects
- This means that those buttons you like to place on a portal row will need to be above the fields or include the fields, which can be a real pain.
- Record commits are handled differently
- Any data entry (even when filtering) requires the user to (whether manually or via script) enter “Edit Mode”, then explicitly commit their changes when finished. Clicking outside a field does not commit the record.
- You may want to hide the Status Area
- IWP produces a Status Area (much like in FileMaker Pro) at the top of the web page, which might not match your desired aesthetic.
- Removing the Status Area requires you to script all of the functionality for the user.
- Rendering is very limited
- Curved shapes and angled lines do not display properly.
- Icons will display differently. Transparency may be ignored.
- Sizing of objects is not 100% faithful to FileMaker layouts, primarily because of additional weight given to the borders of enterable fields.
- You'll get best results with very minimalistic layouts.
- Some scripts steps are not compatible with IWP
- When IWP comes across an incompatible script step, it simply halts the script, unless Allow User Abort is set to OFF.
- Notable incompatible script steps include anything adjusting windows or exporting data: Freeze Window, Show Custom Dialog, Print, Enter Preview Mode, etc.
- Single-window interfaces only
- New windows will appear to replace the current page.
- Users need to log out
- User sessions will persist unless they press “Log Out” or a script runs the Exit Application step.
- This is an example of a Status Area feature that needs to be scripted if the Status Area is hidden.
- You may want to devise a process or button that ensures users log out successfully.
Here are some of the other behavior differences between accessing databases in FileMaker Pro and a web browser. This list is by no means exhaustive but should give you an idea of the kind of differences that exist.
- Web users cannot interact directly with the hard drive so features such as importing and exporting do not work.
- Web users cannot enter or modify container field objects like images, sounds, or QuickTime files.
- Web users cannot spell check their data.
- FileMaker keyboard shortcuts do not work in IWP.
Limitations of IWP
- Only certain script steps work. (More recent versions of FMP can be set to grey out steps that fail)
- The FileMaker dialogue script step cannot be used
- It is difficult to control the way things print
- Only a limited number of records can be shown at one time in list view, and if the navigation bar is turned off this becomes even more problematic
- If you want public access but also extra functionality which requires password access you cannot use a guest account so will need to use a complex URL link that includes auto logon to a pseudo guest account. You will then need to script the solution to handle these accounts accordingly. Otherwise you can use two files which may double the hosting costs
- You need to handle time outs and the close/quit/exit script steps and try to mitigate data loss if the window is closed
- It is best to open IWP in a browser window without a back button because IWP does not handle the reloading of pages this way
- If you make design changes while users are using IWP the system can become unusable until they log back in
- Unlike FileMaker client software if you close the window the data on the page is lost unless the user has submitted it with say a submit button that triggers a commit or by changing screen/layout.
Top 10 list of things you might normally do in your Filemaker database, that you’d be better off to avoid if you want your database to be 100% fully ready to go in IWP mode.
- No New Windows — if your solutions uses a lot of new windows in it, that’s gonna be a problem.
- No Dynamic Value Lists — they’ll work, but slowly. If you have a big data set, and the dynamic values are complex, forget it. The speed, or lack thereof, will kill it. Stay away from dynamic value lists if you can.
- No List Views (kind of) — ok, so not entirely true. There is a list view, but, to keep it succinct, it sucks. Limit to 25 at a time, and Filemaker hasn’t come up with a clean intuitive method of displaying or editing records in the list. If you can, just use portals instead.
- No Rounded Corners — if you like rounded corners on buttons, or anywhere else on your layout, you’re out of luck.
- No Conditional Formatting — One of the best most recent features of Filemaker, not available online. Really too bad. Conditional formatting is perfect for better UI’s.
- No Script Triggers — Due to the web’s statelessness. Too bad. Script triggers are awesome.
- No Dialog Boxes — A much needed tool, but not available online. In my IWP solutions I’ve built a global field element to take over this function.
- No Automatic Commitment — Online, the data in your browser window does not make it to the server on its own. You’ll need to refresh, go to another layout, or trigger a script.
- No File Insertion — You can’t insert a file, like Excel, Word, or a PDF in IWP (unless you use a plug-in, like SuperContainer from 360Works)
- No Import or Export — No records can be imported or exported in the IWP setup.
In the script window, you have the option to show indicate web compatible scripts. When ticked, all incompatible steps with IWP are greyed out, this will help you to create scripts that are going to work in an IWP environment.
A script that has IWP incompatible commands, will not run - it does not ignore the incompatible things - it stops. Now I know to trap these, when I still want the code to run on FM for non-IWP connections, and write work-arounds for those things still needed.
• No database development tools. Can’t create new files, tables, fields, relationships, alter layouts; manage user privileges, or edit scripts.
• Can’t use any of the FileMaker Pro keyboard shortcuts. Any navigation must be built in via scripts.
• No capability to import or export data from an IWP session. Actions that interact with another application, the file system, or the operating system is not possible via IWP.
• No Preview mode. This means that sliding, subsummary reports, and multicolumn layouts, all of which require being in Preview mode to view, are not available to IWP users. Similarly, printing is not supported. IWP users can choose to print the contents of the browser window as they would any other web page, but the results will not be the same as printing from FileMaker Pro. (That is, headers and footers won’t appear on each page, page setups will not be honored, and so on.)
• Web users can’t edit rich text formatting in fields. They can’t change the style, font, or size of text in a field.
They can generally, however, see rich text formatting that has already been applied to a field.
• Browsers can show only the currently active window in the virtual FileMaker environment.
That environment can maintain multiple virtual windows and switch between them, but a user can’t have multiple visible windows in the browser, and cannot resize or move windows except to the extent allowed by the browser (in other words, theser us can manually resize their browser windows, but precision movement and placement of windows is not supported in IWP).
• None of the FileMaker Pro toolbar sare available via IWP. IWP does offer its own tool-bars in the status area, however, and these contain some of the same functionality found in the FileMaker Pro toolbars.
• Spell-checking is not available via IWP.
• Many graphical layout elements are rendered differently, or not at all, on the Web.
This includes diagonal lines, rounded rectangles, rotated objects, ovals, and fill patterns.
• IWP users can’t edit value lists through a web browser.
• There is no built-in way for users to change their passwords via IWP, even if they have the privilege to do so.
If you need this sort of functionality, you need to use the account management script steps in your own scripted routine.
Drop downs cannot be populated from IWP - they must be static lists
Transparent buttons are not recognized.
Stateless transactions requiring a COMMIT instead of autosave in layout setups ( I believe??)
- Performance degradation for multiple users
Yes, it works in the client.
Thanks for sending those limitations!
I noticed this one:
No List Views (kind of) — ok, so not entirely true. There is a list view, but, to keep it succinct, it sucks. Limit to 25 at a time, and Filemaker hasn’t come up with a clean intuitive method of displaying or editing records in the list. If you can, just use portals instead.
I have tried it in a portal and it works, so I will try to go that route. Thaks again for your help!