In trying to use a single-row scrollable portal to display large blocks of text, I've encountered a couple of strange behaviors that I haven't been able to figure out. Basically, the text within the portal is affecting areas of the layout outside of the portal (behaviors are described in detail in the example file).

Before I abandon this approach, does anyone know of any "rules" to apply for such extended uses? Or am I completely off of the pavement in trying to use portals this way?

Thanks for any help.

TextOverflow.fp7.ZIP

I'm not sure I'm following you, but why not format the field with a scroll bar?

Windows continues to exhibit Wonky-Portal-Display syndrome (and other things I won't go into). Graphics in rows suddenly appear below (and outside) of the portal rows, text slides down outside the portal or runs over the bottom portal border. This text then won't refresh when you change records and the bottom half of text (from prior record) remains below the portal. Real sweet.

What I've done for large text blocks is turn off entry to the row. Clicking a row to see the text opens a small window with the detail. I wouldn't trust switching records (with cursor in portal field) to display properly on a consistent basis. Sorry I couldn't help further but we're dealing with Windows XP here after all ...

Now, I'm still on 8.0v3 so I can't say how 8.5 works on Windows so take this for what it's worth. :wink2:

Edited January 9, 200719 yr by Guest

Lee, the purpose is to be able to scroll through the child records and expand/edit as needed, for which a portal seemed appropriate. Update: I added the scroll bar to the text field within the portal -- and added a corresponding Done button. It seems to work. Is that what you were suggesting?

LaRetta, that's a very interesting technique. I've tried to implement what I think I understand it to be -- but using a tab panel instead of a separate window (which I can't use in my application). It almost worked. Using my updated example, can you recommend how I might make the last (edit) step go to the proper record? Or have I misunderstood?

Thanks very much for your help.

TextOverflow2.fp7.ZIP

Edited January 10, 200719 yr by Guest
Updated example file

Hi K1200, I've been considering your situation. I think I would do away with the portal or tab and instead scroll through the related records (in popped state) by using GetNthRecord(). In this way, you can scroll through your MAIN records but remain on the same related record number (row) OR scroll through your popped related records as well as mixing the two however a User wished. Of course you would also have to control Nav of your Main records as well (which would need to include re-setting the textfield Nav as you moved) and I haven't included that.

I wanted to accomplish it with only one Nav script. It works except when it runs out of related records (in either direction) ... I end up with ?. I'm sure I could figure it out but I don't have the time now and I wanted to give you something further to consider. Although this approach would require a global and tight navigation in your Main table, it would eliminate tab control, DONE button, portal etc. Another great thing about using a standard field - it can be only one line high (heck, it could 1 px high) so it requires a very small footprint (won't require the space a portal or tab control will). When the field is popped it can be easily edited - it will expand over everything else on your layout to allow easy reading and modification.

I used global variable to track which related record was selected. It could use some work (fixing the ?) and could probably be leaned-up as well but I think the concept is viable. When User is done, exiting the field or using the arrow will finish their task or move them on. But if you place your cursor in the text field and navigate through the related records, it achieves what you wish (I think). Basically, I had a few minutes to play and now I must get serious again.

LaRetta

textField.zip

Thanks, LaRetta.

I worked with your file a bit (added limit checks to avoid the ? indications) to make sure I understood what you were suggesting. I do like the idea of fetching the text into a global and think I have some uses for that technique. In the specific instance I working on, however, I'm actually trying to control the block size so it won't expand over other fields and buttons. I've done some work with Lee's suggestion and think I have a compromise portal solution that uses a scroll bar on a 6-line text field. The scroll bar only activates when the user clicks on the field, of course, which helps keep a clean display.

By the way, does anyone know of a technique to get the Windows XP scroll bar (like FileMaker uses on value lists) to be displayed for large text block fields? That would be a great improvement over the smallish standard ones.

Anyway, thanks for your suggestion and file.

Edited January 12, 200719 yr by Guest