Could you possibly utilize a Tool Tip to accomplish this?
I think you may need to post your script so that we can see all its details.
You can use Go to Object to open a Popover if you give the PopOver frame (Not the button) an object name so that you can specify it in this script step. You can select OnObjectEnter for the popover frame in order to perform a script each time that you click the Popover button.
But with the Popover button located outside the portal, the mouse click that opens the popover also loses the "focus" on a particular portal row and thus any script steps that reference data after this happens will reference data from the first row in your portal if the portal is unsorted and unfiltered.
Ok, after typing that, I got interested and messed around with a test file for a long time trying different options and resolving some unpleasant surprises. I used: Parent, Child and GrandChild tables for this test.
a) You are correct that you can't put a portal into the popover frame when the pop over button is inside a portal row. The portal object "falls through" the frame to the layout behind it.
b) But this can be set up as another version of a "master detail" set of portals such as I have described here: Need layout solution for nested portals...
c) The tricky part is when you want to add a new Child record in the child portal then try to immediately open the popover in order to enter Grandchild records. Unless you script very carefully, the "selectedChild" field that is used to match the Current Parent record to the Grandchild records of a specific Child, does not get the needed ID value and you get error messages when you try to enter data in the popover's grandchild portal.
Here's the script that worked for me:
- Set Variable [ $Row; Value:Get ( ActivePortalRowNumber ) ]
- Commit Records/Requests
- Go to Object [ Object Name: "Child" ]
- Go to Portal Row [ $Row ] [ Select; No dialog ]
- Set Field [ Parent::SelectedChild; Child::__pkChildID ]
- Set Variable [ $$ChildName; Value:Child::Name ]
- Go to Object [ Object Name: "Popover Frame" ]
If I have just created a new Child record in the portal when I perform this script, the set Field step fails to enter a value into SelectedChild even though the __pkChildID field is set to generate a serial number "on creation" unless I first Commit records. But since that drops the focus on a specific portal row, I have to capture the current portal row number in a variable so that I can use Go To Portal Row to return the focus to it.
This would suggest that using a button and script to add a new Child record might be simpler.
PS. You can enter True into the new "Hide when" property when the popover button is selected to hide the actual popover button from view at all times. If you then slide the button so that it is mostly behind the portal, the popover frame appears to pop out of the Child portal.
Could you possibly utilize a Tool Tip to accomplish this?I think that it is too much data I want to display for a tooltip, plus I have a button in the popover window as well. You actually reminded me that I am not using tooltips enough. Thanks!
The examples you provide as usual are a wealth. That script modified to what I am doing works well. To accomplish what want I am starting to develop the idea of more table occurrences and a few calculation to deduce my result natively. Seems like I have too much going on and jumping through a lot of hoops. Basically I think I am relying too much on automation and not foundation. You had told me that a Layout with many calculations could be slow and clunky, I first took it as number of calculations in a table, you later cleared it up that it is the ones on the layout that count when talking about speed. When a calculation is on a layout for example Value Count ( someField ), does it run for the entire set of records every time a record is browsed to, or dose it only process it for the current record?
I'm not really sure. I think it's only as you scroll through to different records, but I do know that the truly critical calculations are those that compute an aggregate value from a large number of records. That could be a summary field that pops up a progress bar when you pull up a half million records into your found set and FileMaker gamely tries to produce that aggregate value (Sum, average, Standard Deviation...). Or it could be that you have only one record in your found set, but an aggregate function such as Sum ( RelatedTable::Field ) evaluates and there are a half million matching records in the related table.
Filtered portals can also be an issue if there are a lot of related records as the portal filter expression has to be evaluated for each related record in order to determine whether or not to omit each related record from view in the portal.
If your network is slow such as when the hosted DB is at a remote site (WAN instead of LAN) or your CPU is slow (iOS client) these issues become much more apparent.