Does anybody know how to allow scrollbar in a field in iwp? I notice the scrollbar would appear only if the field is editable, but not in read only format.

As such the field size becomes the limiting factor as one can't have more text inside than the field size.

Regards,

Clifford

This is actually the behaviour I know from the standard client since (at least) FP 6. Seems not to be an IWP problem, but it certainly is a nuisance.

A quick fix would be to create a calculation field which is equal to the field you want to be read only and display that field with scroll bars.

Stu

The calc field solution doesn't work in IWP--at least not in my experiments with them. The only workaround I could think of was to create a throwaway global field that gets loaded with fresh data each page load...

I'm not sure if global field is the solution since I want to display a field with a scroll bar for each record in iwp.

I hope this would be addressed in the upcoming version of fmp.

Regards,

Clifford

Just tried it out with the calc field and you are correct!! Sorry for the misinformation.

Stu

It looks like the field needs to be entered in order for the scrollbar to appear. This seems to be the case for both IWP and desktop solutions. However, in a desktop solution, a field can be entered without being designated (in Accounts/Privileges) as being modifiable, whereas in an IWP solution, a field can only be entered if it is designated as modifiable. In other words, in a desktop solution, it is possible to scroll through a field without being able to modify the contents, but this is not possible in an IWP solution.

This is frustrating. IWP solution designers must accept a tradeoff: if we want a scrollbar to display for a field, then we have to ensure that the web user has modify privileges for that field. But what if we don't want the web user to be able to change the contents?

There are workarounds, but the workarounds are not particularly clean, and besides, it seems silly to have to resort to workarounds in order to have a non-editable scrollable field. The potential workaround that I'm currently experimenting with makes use of the Revert record script step. Basically, I direct web users to a layout containing a portal that contains an editable field that displays a scrollbar. Web users can scroll the field, but as a consequence, they can edit or delete all of the text in all of the related records in the portal if they wish. However, the status area is hidden/locked, and their only path out of this layout is through a button that runs a script that contains the Revert Record script step. This reverts all related records in the portal to their previous state. I've added a note to the layout advising users that no changes made to records on this layout are saved.

Basically, as soon as the web user clicks in a field, he enters Edit mode, but no changes are saved unless the changes are submitted/committed. You can't simply have a button that transfers control to another layout, because changes are committed when control transfers to a different layout, so it is important to add the Revert Record step.

Not an ideal solution, as the impression is created for web users that they are in fact altering the records. And it gets messier if desktop users are accessing the same solution, because they can simply commit the changes by clicking outside of a field on the layout, whereas this does not commit changes for IWP users. So this has forced the creation of two versions of the layout--one for IWP users and one for desktop users; the privileges for the field in the desktop layout are specified as view only.

As much as I love FileMaker, this problem alone is killing much of the zeal I have for using it to develop IWP solutions, and without the ability to develop effective web-based solutions, FileMaker may not have much of a future at my company, so I hope FileMaker rectifies this soon!

The scroll bar works in IWP but doesn't display. You can position a header above and below where it is as an indicator of where it is. Clicking between those marks will take you up and down. Not a good solution but it does work.

Doug

Interestingly enough, putting the marks in, as earlier described, made the scroll bar appear in IWP as it should have all along. I did have top and bottom marks plus had vertical lines that fell within the scroll bar area. It may be the latter that triggered the bar's appearance.

Doug

Hi Doug,

I can't replicate this behaviour. Put all sorts of things in the scroll bar area and nothing unusual happens.

Clicking in the scroll bar area does work, but as previously described, it puts the record in edit mode, which is far from ideal.

Cheers,

Sean.

Hi Sean, Zardoz, Clifford ...

I'm sorry but it seems to me that Doug Obesefelinex missed a point when he said the scrollbar works in IWP, obviously he was talking about scrollbars in normal editable fields and layouts.

Anyway, I am glad that he took up again an older discussion that otherwise I would have missed.

On the other hand the points that Zardoz made in this very important question nearly 3 weeks ago inspired me tonight.

I did about the same thing as what Zardoz described so well, but without the need of a portal.

I duplicated the "view only" layout, made a scripted button to that duplicate layout,

but noticed that in IWP this button takes me to the very 1st record of the file, and not to the same record I started from.

This is different from the behavior in the client, where, if you start from record 24, you automatically get to record 24 in the duplicate.

It appears that for the sake of IWP an extra script step is needed at the start of the script. This one works well: Go to record ... [no dialog; Get (RecordNumber)]

So in order to let IWP home users scroll when needed, we have to make them switch to and from between the "view only" layout and the "editable and scrollable" (status area hidden) version.

Hope better solutions will come up soon.

Guus