10 Replies Latest reply on Dec 9, 2013 12:52 PM by philmodjunk

    Why: about text-field and Portal

    CekariYH

      Title

      Why: about text-field and Portal

      Post

           Why aren't....

            

           Text-fields, multi-line with scroll bar:

           Why aren't they scrollable with mouse-wheel when not selected?

           Why do they revert to top-lines when not in focus?

           Why aren't they scrollable when not used as an input-field (Read-only)?

            

           Portal:

           Why can’t additional data (fields and column headers ) be added to the right of the right side and be visible when the Portal grows horizontally? (Yes one can add fields but useless with no header many times, and no I don’t what them on each row. Furthermore there is no clue to the user if there is no… see below… )

           Why are there no horizontal scroll bar?

        • 1. Re: Why: about text-field and Portal
          philmodjunk

               Why questions have to be asked of someone who helped design the product and they are likely bound by Non Disclosure agreements to not discuss such issues. You could make things a feature request. wink You are of course, welcome to post feature requests for features you'd like to see added to future versions: http://www.filemaker.com/company/contact/feature_request.html

               You can, however, get a scrollable read-only field with a bit of trickery. Remove the text field from the layout and replace it with a calculation field that "copies" the contents of the text field. You can give this field a scroll bar, enter the field and scroll it while still protecting it as "read only".

               I Know a trick that could resize your portal as described, but you'd loose the vertical scroll bar if you did. You can place the portal inside a single panel, invisible tab control. Set up the portal and column headers exactly as desired but then resize the tab control to the smaller size and use anchors to expand it when the window changes.

               Another work around is to detect the window change and swap layouts. Since you are changing layouts, each layout can have differently sized and labeled portals and you can put some kind of layout text or other indicator on the layout with the smaller sized portal. This trick is especially handy when working with FileMaker Go. (There's a new trigger in FileMaker Go/Pro 13 that is tripped by a window size change and there's a way to get similar behavior with Install OnTimerScript in FileMaker Go/Pr 12.)

          • 2. Re: Why: about text-field and Portal
            CekariYH
                 

            Why questions have to be asked of someone who helped design the product and they are likely bound by Non Disclosure agreements to not discuss such issues. You could make things a feature request. wink You are of course, welcome to post feature requests for features you'd like to see added to future versions: http://www.filemaker.com/company/contact/feature_request.html

                 Well... we have discussed this before, deadly silence on one end doesn't make a conversation :-)

                 

            You can, however, get a scrollable read-only field with a bit of trickery. Remove the text field from the layout and replace it with a calculation field that "copies" the contents of the text field. You can give this field a scroll bar, enter the field and scroll it while still protecting it as "read only".

            I'm using the On Keystroke trigger and also the Open and Close object triggers to keep the field the same should the user "paste" in something" so there are a few tricks to get that, but why should I have to... as sometimes it is supposed to be editable and sometimes not... with many such fields it gets a tad tedious ( and also for container-fields ), instead of setting a property to allow edit or not while it should keep it readable and scrollable.

                 

                      I Know a trick that could resize your portal as described, but you'd loose the vertical scroll bar if you did. You can place the portal inside a single panel, invisible tab control. Set up the portal and column headers exactly as desired but then resize the tab control to the smaller size and use anchors to expand it when the window changes.

                 

                      Another work around is to detect the window change and swap layouts. Since you are changing layouts, each layout can have differently sized and labeled portals and you can put some kind of layout text or other indicator on the layout with the smaller sized portal. This trick is especially handy when working with FileMaker Go. (There's a new trigger in FileMaker Go/Pro 13 that is tripped by a window size change and there's a way to get similar behavior with Install OnTimerScript in FileMaker Go/Pr 12.)

                 To many "tricks" and to few "real thing" properties. Sometimes I feel that I'm spending more time to get the visual to work than programming the "important" stuff.

                 

                      There's a new trigger in FileMaker Go/Pro 13 that is tripped by a window size change

                 It also say layout size change, but I guess (or know really) that zoom doesn't count in for that.

            • 3. Re: Why: about text-field and Portal
              philmodjunk
                   

                        Well... we have discussed this before, deadly silence on one end doesn't make a conversation :-)

                   Which doesn't change the fact that you are asking questions that forum participants can't answer. Posting a feature request puts your feed back where the people that can change the design of future versions will see it. There's also a FeedBack section of this forum if you just make your complaints about the product public.

                   

              I'm using the On Keystroke trigger....

              That seems needlessly complex and if you drag and drop into the field, this trigger won't be tripped even though your field was modified. It's simpler to use a calculation field in place of the text field. See the scroll bar equipped read only fields on the first layout of the Known Bugs List Database for a working example.

                   

                        Too many "tricks"...

                   Perhaps, but since neither you nor I have a magic want to wave to make the system work differently, those tricks allow us to get on with a project instead of waiting for design changes that will be a long time coming if they come at all.

                   

                        It also say layout size change, but I guess (or know really) that zoom doesn't count in for that.

                   But how would changing the "zoom" change the width of your portal to show more fields anyway?

              • 4. Re: Why: about text-field and Portal
                CekariYH

                     I wasn't really expecting an real answer to Why-Q... just taking of some heat and pressure buildup...

                     

                That seems needlessly complex and if you drag and drop into the field, this trigger won't be tripped even though your field was modified. It's simpler to use a calculation field in place of the text field. See the scroll bar equipped read only fields on the first layout of the Known Bugs List Database for a working example.

                But if it needs to be both editable or locked depending on some condition? My way makes that simpler I think?

                Will try that when I calm down :-) but I do check both "locked" text- and container-fields when the user leaves them if they changed.

                     

                But how would changing the "zoom" change the width of your portal to show more fields anyway?

                Sorry, wasn't clear there, it didn't have anything to do with Portals, just pointing out that zoom in and out doesn't trigger a layout change as I thought when I read about the new trigger.

                      

                • 5. Re: Why: about text-field and Portal
                  philmodjunk

                       Take a look at the Known Bugs List layout. What I did was include an Edit button that pops up a small window as a modal dialog for editing the field. In the pop up window, it's the text field. On the main layout, it's a calculation field that "copies" the context of the text field so that we can have a non modifiable field with a scroll bar. Such an interface design could include scripting that only pops up the edit dialog when conditions, user permissions, etc are such to permit that.

                       With the new FM 13, I'm thinking of using some pop over buttons for this kind of thing instead of opening a new window and having to deal with "Window twitching" on Windows systems with Maximized windows...

                  • 6. Re: Why: about text-field and Portal
                    CekariYH

                         I said I will check your examples out :-)

                         In these cases the text- and container-fields always must be readable and resizable with the window so the button or popover isn't a suitable way.

                         Think of an powerplant-diary where each shift gets one "page" per shift and only the current shift can add or change their current page but read every others so to speak. Every eight hour the current page locks and a new is created ( with some varnings and wait options if the writing isn't done for the off-going team.) and thats only one field. There are a lot of tables, pages and fields for other things than the diary...  like Mechanical/Electrical/Instrument/Weather/Unknown Incidents-, Enviromental Events-, Remember-tables etc and also Running Strategi for the next 24 + 12 hours, Running Orders from the "bosses", MSGs etc.

                    • 7. Re: Why: about text-field and Portal
                      philmodjunk

                           Sorry, but I don't see why that would make the approach that I am recommending not work for this. The data remains readable and scrollable at all times. You only use the added pop up window when the need arises to edit data. (And you could also use one row of fields for the "current data editing" and the "locked" data could be records in a portal listed just below the row of editable fields. or you can use a list view for the locked fields and put global fields in the header for the new data.

                           Your script that periodically "locks" down the data could simply create a new record, use set field steps to copy the data into fields of the new record and then updates the global fields if needed.

                      • 8. Re: Why: about text-field and Portal
                        CekariYH

                             Can't say as I haven't tried your way yet :-)

                             ...but how would you like to write a "book" where some pages is merely 1 row of text while others might be like 20kB+ of text and everything in between.

                             I for sure want one page ready to go every time I need to add or change something on that page and also be able to scroll easily on "my" page and read others written before my.

                        • 9. Re: Why: about text-field and Portal
                          CekariYH

                               While we are on it, I forgot... perhaps as I quite new to FMP , all the locked text-fields has to be copy-able (is that a word? ) as I haven't figured out how to print just the text in the textfield in all it's length one row or 100:s, so today we copy the text and paste into MS Word or similar when needed.

                          • 10. Re: Why: about text-field and Portal
                            philmodjunk

                                 The text in the calculation field method is fully copyable--but there are also ways to export text to a text file and one reason for that is to set up a merge file for import into MS Word. Scripts can also be used to load data into the clipboard for pasting. A significant percentage of the responses that I use to answer questions here are data that was automatically copied to the clipboard when I looked up the answer on the Tutorials layout in that same Known Bugs List database.

                                 

                                      ...but how would you like to write a "book" where some pages is merely 1 row of text..

                                 No method works in every situation nor is FileMaker the best application for every task. That's a bit too vague to be sure that I'm picturing the same thing that you are.

                                 That said, there are multiple options for working with such data. The most basic technique is, where practical, to break up those large blocks of data into a set of individual records such that a table view, list view or portal then becomes a more practical option for displaying the data. But there are a great many layout variations you can consider.

                                 One method--that as frequently been requested by Bento users migrating to FileMaker is to have a list view over view of the data with a portion of the layout set up as a kind of "form view to provide a more detailed view of that one record. This is normally done by placing the same set of fields in both the body (sized small) and either the footer or the header where you expand the size of that part and use larger copies of the field with one method or another of the options we've discussed for leaving these fields editable in the header or footer and read only in the body.

                                 Those are just a few ideas, others are possible. Some developers even set up tool tips to display the full contents of a field though I usually find that a bit too ephemeral to be practical for large chunks of data.