Jump to content

scroll bar


This topic is 6517 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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.



Link to comment
Share on other sites

  • 2 months later...

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!

Link to comment
Share on other sites

  • 3 weeks later...

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.


Link to comment
Share on other sites

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.



Link to comment
Share on other sites

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.


Link to comment
Share on other sites

This topic is 6517 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.