IWP Select causes records to disappears

[KirkR]

I have a simple database that runs fine in Filemaker and FM Remote, however, when it is up in Instant Web Publishing (IWP), clicking on a record causes all the records listed above the point of click to disappear. Also, as soon as I click on that record, that record is the only one that I can enter the fields; clicking on any other record does not allow field selection.

This is a simple layout, with the list headings in the header, and the fields as a single row (from one table) in the body. I only have 9 records currently in the DB.

A scripted "show all" button will NOT display the records. However, if I perform a FIND first, then a SHOW ALL, the records all return. The behavior returns to the same condition - select and everything above the selection disappears. I have the file concurrently open in FM and all operational behavior is correct.

I have checked the layout for alignment - nothing is closer that 4 pixels to the edge of the body. A layout "select all" does not show any hidden fields or control elements in places where they are not supposed to be.

Tried adding a SELECT RECORD [FIRST] in the script that goes to that layout, but that did not help.

Suggestions? This is a very strange one. The behavior is identical in Safari (OS X), Firefox (OS X and Windows) and IE (Windows). Am I missing something simple?

[KirkR]

Apparently this is a "broken as designed" - LIST views that work fine in FMPro, work like this in IWP -( .

Specifically, in the browser, clicking on a client, hides all client records above that record in the list, and only allows editing of that record selected. Clicking on another record does nothing after that point.

There are a couple POTENTIAL (read:speculated but untested) work arounds, each of which change the behavior of the client screen.

1) Create a SUBMIT button on the right of the records in the LIST VIEW, that when clicked, would restore the entire list. Easy to implement, however, it has the visual discontinuity of A) removing the display of all records in the list above the click point until after SUBMIT, : leaving the display of records after the record selected, displayed, but not active. Records (at least the one clicked) remains editable until the SUBMIT (or DONE, or OK, or GEORGE - any text label that works) button is pressed. (easy, but not pretty or recommended)

2) A little more work (not much) would be to lock the field entry in the list, and create an edit window and button. Clicking EDIT would open a window with just that client's records displayed. That would also more room for other client information, like the program name, or any other details.

3) Create the list in a portal - a scrollable and editable view into the table. The portal does not exhibit the same characteristics as the list view. If it works, it would retain the "edit in list" capability.

In application, (combining 2 and 3) It would probably be best if the list were just a "select record" function for the parent fields, assuming that the PORTAL is created as a result of cartesian relationship.

[Søren Dyhr]

I can confirm that we too uses selfjoin portals for our listings task when IWP'ing.

But any kind of non scripted filtering such as RG craftiness hits the server too hard. So if a found set is established do we save the ID's via a tail-recursive CF, in a global - just before the filtering is introduced via Constrain Found Set steps, which in a similar manner is saved in yet another global, which is the point from which the portal data is shown. Since only the portal is shown in the window could a GTRR(SO) easily be issued to re-establish the found set again.

--sd