Steve Martino

I think we still need a little more info on the workflow/process of what you are trying to accomplish. Why is a user opening a popover? For which task(s). What triggers the popover to open? What do you expect to happen if they open the popover change their mind? Or a popover can have a field at the type that does a 'search as you type'. There are many options. I recommended a card window because you could make it look and function almost exactly like a card window. 'Empty field' dialogs can be surpressed.

Couldn't you just make it a card window instead of a popover? Or put a 'find' or 'search' button on the popover to run the script?

I think if you just sort the relationship in descending order by date of the phone log entries, simply putting those fields on the Customer layout (or a 1 row portal) should do the trick. Then you wouldn't need what's probably an unstored calc at all.

Most likely someone from FM Starting Point will respond in the morning.

I forgot about the Base Elements Plug-in, which is free to download: https://baseelementsplugin.zendesk.com/hc/en-us/articles/360017562794-Downloads

It's hard for me to follow your script but basically when pulling records like this, you probably need a loop in a loop. Also, when doing a virtual list, you usually have to append the results in a variable (over and over when looping), local is faster, then move that entire value to a global variable if need be. Virtual list requires that you pre-populate the table with more records than you could ever need, then performing a find on a field guaranteed to have a record, unless you're building your VL with repeating fields. Probably the only way to solve this is with a sample file.

Hey Caroline, Happy New Year's!! Here's a file posted long ago by Stacy Chamblee, you can use it to make a shortcut with an icon on the screen. The only seemingly unavoidable thing is that it opens both FileMaker Go and the app, so you have to kill 2 things when done. I use Metro Studio for simple icons. Took playing with it for about an hour to get it to work for me. App_Maker_-_Copy.fmp12

https://www.databasepros.com/training.php

You have to import (or copy/paste) and set up custom functions manually. FM doesn't come with custom functions installed.

Keep in mind, only you know all the terms and minutia of your database. For others looking at it cold, it's very confusing. I kind of understand what you are trying to accomplish, and that seems like it could be sort of straight forward. For me, quicker way to help would be a copy or sample database. Seems like you have way to many TO's, some probably unneeded as you could most likely cover some of these tasks with filtered relationships or filtered portals. You can also clean up your graph to show just the TO's, and the fields that connect them, and collapse the rest for easier readability. And you can group them by color too. All the TO's starting with PER and GUE are suspect, and what's a Guest, and how are they important to the overall scheme of things. In general, it's just a matter of figuring out what TO you want to start with (standing on) and connecting to the proper child TO to view the related records, in its easiest form, in a portal. I'm also curious about the Countries TO's. If needed for reporting, can probably accomplish more simply with scripted finds. Overall it's a very complicated database, or you made it that way. Which can easily happen. It's not too hard to run amok with adding more and more TO's or TOG's and going 'too far down the rabbit hole', so to speak, just to try to accomplish each new task you want to add. Sometimes a re-build could be in order, then transfer (import) the data into the new one. Also, it's helpful to amend your profile for FM version, and Operating system/version.

Basically the button would start a script that would go to that related record in a new card window. If the button is in a blank row, it would grab the primary id of the layout (in a variable), open the card window, new record, set foreign key to primary key variable. Only allow the user to commit via a Save button, or allow the user to cancel (delete record for new record, or undo changes for existing record), commit, close window, maybe refresh first layout or portal.

There's always a solution. The problem is one of obvious structure & context, and your understanding of table occurrences (TO's) and table occurrence groups (TOG's). Not all TO's have to be connected in one continuous string, and they usually should not be connected that way on any but the simplest database. Using TOG's enable you to show how data is displayed and presented, and how it relates to the other TO's. It's also important that the relationships are set up properly, and the method you are using to create related records. Venue data in two separate tables sounds problematic. I also don't understand why all your TO's start with 'PER', but I can't see your entire graph. To me this set up is more like a basic Invoice solution set up, where the customer is the director, the line items are the screenings. The venue, movie title, etc are products. It's obviously more involved than that. It also matter from what perspective you want to view the records (reporting). Do you want to go to a Director's layout, and create a screening record by selecting a movie, a venue (date, time, notes)? Do you want to look up movies and see all the screenings? Do you want to look up venues and see all the screenings? A copy of your database file (with personal data deleted) would be the quickest way to get some help, and prevent myself and others from the back and forth that will occur with the first 20 questions popping up into my head.

Don't quite understand the request. If you put it in a portal row, you would probably want to hide it on any row that has data, and just show it on the blank row, otherwise, every portal row has a button for a new record. Seems more intuitive to pop open the card window, then the user is focused on that specific task to either complete adding the new record or change their mind.

I'm a little confused, but I'll take a shot. I think what you could do in a script is: Grab the primary key of the record on the main layout. Open a new window on the layout you want to create the related record. New Record Set the foreign key to the variable Enter your data. I'd either cover the entire new layout with a button so a user can only commit the record by clicking your Cancel or Submit buttons, or use a script trigger to prevent committing the record unless the use the buttons. Cancel button runs script to delete or revert record, close window. Submit button commits record, close window You may need a refresh on the portal.

You should probably post a simple sample file.