1 of 1 people found this helpful
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!
Have you tried making a new window?
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.
1 of 1 people found this helpful
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().
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.
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 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.
Could you be more clear about what your doing? It's hard to say if you can accomplish what you want.
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:
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.
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:
And the second, "GetResourceIDsInUse" returns the ids of all resources in use during the time slot defined by the global timestamp fields, like this:
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 > ?" ; "" ; "" ;
(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.