10 Replies Latest reply on Jul 29, 2014 10:31 AM by davehob

    Keeping a popover open when switching layouts

    davehob

      I think I’m wanting the impossible (not for the first time...), but thought I’d check.

       

      In a single-window solution, I have a layout, based on Table A. On it, I have a popover button. In the popover, I want to use a variety of global fields (dates and times), from the Globals table, to check the availability of resources. To do this, once I’ve gathered the values into the globals, I need to go to another layout (based on the Globals table), do the business, and come back to [original layout], where the popover will be as I left it, now listing the available resources. But unfortunately, the first Go To Layout [] script step closes the popover.

       

      Is there any way around this?

       

      Dave.

        • 1. Re: Keeping a popover open when switching layouts
          mikebeargie

          No way around it, however you can just reopen the popover on return using the Go To Object or Go To Fields script steps. I think if you couple that with a freeze window the result might be negligible.

           

          Let us know if that works for your needs!

          1 of 1 people found this helpful
          • 2. Re: Keeping a popover open when switching layouts
            DavidJondreau

            Have you tried making a new window?

            • 3. Re: Keeping a popover open when switching layouts
              mikebeargie

              He mentioned single-window solution. But yes, opening a new window (tested FMPro13adv on Mac OSX 10.9.x) will keep the popover open in the back window.

               

              New windows behaves differently in FM Go and FM WebDirect though, so it probably only would work that way on Pro, and then you'd have to deal with windowsOS resizing actions as well due to their single application window.

              • 4. Re: Keeping a popover open when switching layouts
                DavidJondreau

                My brain skipped that single window part.

                 

                I'm not sure why a layout switch needs to be done though. Only if non-global fields in non-related tables need to be set. That's pretty unusual. Setting globals doesn't require a layout change. Retrieving non-global data can be done with ExecuteSQL().

                1 of 1 people found this helpful
                • 5. Re: Keeping a popover open when switching layouts
                  davehob

                  Thanks for the input, David.  The reason I think that a layout switch is needed is because I need to populate the list of available resources based on relationships to other tables - so, although I can see and set the global fields from the context of Table A, I don't think I can use those fields in a relationship to the other tables from the same context.  I could, of course, have the globals in Table A, but I really want to make this as portable as possible, hence the globals in their own table. 

                   

                  So maybe this is, as you suggest, a case for eSQL.  I'll give that a bash.

                   

                  Dave.

                  • 6. Re: Keeping a popover open when switching layouts
                    davehob

                    Thanks, Mike, for the suggestion, which works, to a point.  However, I fear that my enthusiasm for triggered scripts is in danger of tripping me up:  I now relaise that I have an OnLayoutExit script on the layout that I'm leaving, as well an OnLayoutEnter for when I go back to it, both of which (of course) run when I switch back and forth.  So the whole layout switch thing is getting way too complicated, and I think I need to concentrate on avoiding switching - it'll be much cleaner if I can do so.

                     

                    Dave.

                    • 7. Re: Keeping a popover open when switching layouts
                      erolst

                      Dave Hobson wrote:

                       

                      so, although I can see and set the global fields from the context of Table A, I don't think I can use those fields in a relationship to the other tables from the same context.

                       

                      Try creating a Cartesian relationship from your popup table's TO to the Globals TO that has the required relationships; that should let you access all those other TOs.

                      • 8. Re: Keeping a popover open when switching layouts
                        DavidJondreau

                        Could you be more clear about what your doing? It's hard to say if you can accomplish what you want.

                        • 9. Re: Keeping a popover open when switching layouts
                          davehob

                          David – thanks again for your help.  Happy to provide more detail.

                           

                          I’m working on the resource booking part of my solution.  The basic data structure is:

                          Programmes (PGM) > Sessions (SSN) > Resource Bookings (RBK) > Resources (RSC)

                           

                          From various contexts, I need to see what Resources are available (i.e. not booked for other, simultaneous Sessions).  (And by “simultaneous”, I obviously mean overlapping, i.e. a Resource is only available if it’s unbooked for the whole Session.)

                           

                          So I have a chain of relationships which I use to populate a GLOBAL multi-key field in Sessions called AVAILABLERESOURCES.  (This used to be a calc field, but it was really slow, and it seems much more efficient to update it when I need it.)

                          This is what the relationships look like:

                           

                          available_resources.jpg

                           

                          The first relationship, a self-join, is defined simply as:

                          timestampFrom < timestampTo AND
                          timestampTo > timestampFrom

                           

                          Once I’ve got the values in AVAILABLERESOURCES it’s a straightforward job to present them in a portal for the user to select from.  Once a Resource is selected, I update RESOURCESAVAILABLE, so that it disappears from the pick list.  So far, it all works fine.

                           

                          But, because I need to do this sort of checking from a variety of contexts, I want to make the relationships more context-independent, to avoid repeating the relationship chain in several places.  Hence the use of global fields in a GUI table: DATEFROM, DATETO, TIMEFROM, TIMETO (and associated timestamp fields), and RESOURCESAVAILABLE.  So, wherever we are, we can put the date and time values in the GUI table, and, via relationships like the one above, but starting from GUI, get the available resources.

                           

                          But the problem I’m now finding is that, having populated GUI::RESOURCESAVAILABLE, the ability to list the related Resources is still context-dependent.  Because, although I can see the global fields wherever I am (e.g. in a popover), I can’t show the Resource names in the popover without relationships to the other tables.

                           

                          As Erolst suggests above, I can get part-way there with Cartesian joins, but I’m still going to end up repeating a bunch of relationships, aren’t I?

                           

                          I may, of course, be going about this in the wrong way altogether, and I’ve a feeling that I’m making it more complex than it needs to be, so I’d really appreciate any advice you may be able to offer.

                           

                          Dave.

                          • 10. Re: Keeping a popover open when switching layouts
                            davehob

                            I seem to be getting somewhere in my quest for context-independence.  I've created a couple of CFs, using ExecuteSQL(), the first one just gets all Resource ids, like this:

                             

                            ExecuteSQL (

                            "SELECT id

                            FROM RSC";

                            "";"")

                             

                            And the second, "GetResourceIDsInUse" returns the ids of all resources in use during the time slot defined by the global timestamp fields, like this:

                             

                            ExecuteSQL( "

                            SELECT DISTINCT r.id

                            FROM SSN s, PGM p, RBK rb, RSC r

                            WHERE s.id_PGM = p.id

                            AND rb.id_SSN = s.id

                            AND rb.id_RSC = r.id

                            AND s.timestampFrom < ?

                            AND s.timestampTo > ?" ; "" ; "" ;

                            GUI::TIMESTAMPTO; GUI::TIMESTAMPFROM)

                             

                            (This performs pretty quickly, as long as the time slot is not too long - then it's a bit slugish.)

                             

                            I then use the excellent FilterList CF to give me all AVAILABLE resource ids, i.e. those that are IN the first list, but NOT IN the second.

                             

                            FilterList ( GetAllResourceIDs; "NotEquals" ; GetResourceIDsInUse ; 0 )

                             

                            I can use this to populate whatever multikey I need, without the need for the repetition of lengthy relationship chains, which will make life much easier.  For example, back to my original problem of needing to populate a portal of available resources in the popover, that's now easily done, by using the above "FilterList" calc - no need to switch layouts just to get to the relevant relationships.

                             

                            Thanks, as ever, for the help.

                             

                            Dave.