Using IWP publishing with FMSA9 on OS X.4.10 on a G5PMac, I have run into multiple problems using radio buttons and check boxes, particularly unpredictabler layout behavior in the browsers.

For instance, I am completely unable to see vertically oriented buttons, regardless of the size given to the field.

More seriously, certain field list values appear not to register at all in the browsers, although they function fine in the client.

For example: the list values No/Yes/? work fine, but No/Yes/Unknown leads to only the No button accepting any input, and changing to another value (in the browser) fails.

Moreover, if I choose other values using the FMP client, which works, the browser continues to display only the no value, even after logging out etc. Again, this does not change with resizing.

What is going on here?

This is a wel known problem:

http://network.datatude.net/viewtopic.php?t=125&highlight=iwp

--sd

Søren,

thanks, we already discussed this layout problem.

I posted this mostly for the second, more serious issue of radio button behavior (not accepting/showing certain values in the browser), which is not addressed in your link and has me really stumped...

Edited August 25, 200718 yr by Guest

I just wanted to add that I've found what seems to be the same behaviour desribed elsewhere:

the topic:

"Radio button value incorrectly reflects value of field in IWP" in the IWP section of the fmwebschool site (http://fmwebschool.com/frm/index.php)

is exactly what I'm seeing.

GENX is welcome to comment...

In the FMwebschool thread, GENX suggested several throubleshooting steps, like trying a fresh list, new layout etc.

I finally went so far as to create a new file, with one (text)field, as only option validate by list with three values:

No

Yes

Unknown

In the layout, the field is set up a radio button linked to the above list.

I enable IWP, open it in Safari, and boom: only the No value is accepted/displayed, while the FM client happily shown Yes or Unknown.

I change the value list to

No

Yes

IDK

and everything works fine.... what the @#$%%@#$ :?

I'm not much of a web guy overall, but there has been discussion of this on the TechInfo list of FileMaker. Basically it seems almost as if IWP is doing a PatternCount() match rather than a "whole value" match like we would expect. It might be JavaScript who's responsible. I don't really know.

So "male" will match "female", because it's contained within it.

"No" and "Unknown" ("no" is in both)

About the only work-around is to always use terms that are completely mutually exclusive.

Thanks Fenton.

Pretty scary the kind of stuff lurking below the surface.

But this almost sound like an explanation for why finds on radio button fields fail - note that my problem has nothing to do with finds - just simple data entry... If the IWP engine somehow running scripts that screw up when you hit the "submit" button in the browser?

I think it's an inadaquacy in the JavaScript. I mean, you could produce exactly the same problem within FileMaker if you used PatternCount() on a multi-line field, like a checkbox. The proper procedure is to surround both the target and the value with delimiters (usually returns), so partial matches do not happen. (Or use the Value functions.). It just seems as if they couldn't be bothered to do that with the JS in IWP, which is really a combo of FileMaker and JavaScript.

Well,

I certainly don't understand the rules of this issue.

simply changing the listvalues to Unknown/No/Yes made the field behave normally...:

So I'm not sure what the "syntax" might be.