Grundly

Members
  • Content count

    53
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Grundly

  • Rank
    member

Profile Information

  • Gender
    Female

FIleMaker Profile

  • FM Application
    15 Advanced
  • Platform
    Mac OS X El Capitan
  • Skill Level
    Expert
  • Certification
    11
    12
    13
  • Membership
    FileMaker Business Alliance
  1. Yes, after some additional testing, I've run into similar shortcoming in that solution, unfortunately. In your example, we would have wanted Melanie to also become related now to all 5 of Jane's other relatives, but that does not happen, Melanie is just left with Jane only instead of Jane and all of Jane's relatives. The structure in efen's file is the same structure I have right now in my real file. Not sure if this can be further enhanced via script, or if a change in structure is needed. At a loss, but feels like we are closer than before.
  2. Thanks folks you've been helpful. Efen, you got it, that file you created hits the mark. It looks like it was not trivial to create, so thank you for taking the time to put together such a thorough example. I like how the loop works. That's totally the piece I was missing. From this logic you've laid out, I should be able to adapt it to fit into the existing solution. Perfect, THANKS!
  3. I'm sorry if you are unable to understand my problem, I may not have explained it well enough. Would anyone ELSE like to take a stab at my problem? Please don't reply if all you want to do is talk about how good someone is. Only reply with technical answers about my problem. Thanks.
  4. Hello folks! Setup: Our graph looks like this: People >> FamilyMember >> People. The People table has a name field and a primary kp_PeopleID field. The FamilyMember table has but two fields: kf_PeopleID and kf_FamilyMemberID. The first relationship predicates are: People::kp_PeopleID = FamilyMember::kf_PeopleID. The second relationship predicates are: FamilyMember::kf_FamilyMamberID = People::kp_PeopleID. We have a portal on People layout, that looks at FamilyMember (and the second People table occurrence also, to grab their names). This is all fine and well to specify other People as Family Members, we have a scripted picker that creates related records in FamilyMember by dropping in the Family Member's PeopleID. No problems there. Everything works great. We have a bunch of records like this now. Example data: Bob has 2 Family Members, Mary and Jane, they show up in Bob's Family Member portal. If you go to Mary's record, you will see, she has two relatives also, Sven and Thor. Also, if you go to Jane's record, she has a relative, Susan. So technically speaking, Bob actually has five relatives, according to the way we think, not just the two in Bob's portal. But now the task is this: We want a script that'll fetch all Family Members, and relate them all to each other. We want to see Sven, Thor and Susan also in Bob's Family Member portal, in addition to the original Mary and Jane. Further, we want all of these six people's Family Members to have the other five people in them, too. We could trigger this script with a manual button, and maybe also tack it onto the end of our Picker script. I want to do this in an elegant way, and the only way I have come up with so far is a very large, very limited, very hard-coded and hairy script which stops at three levels deep, which is probably not the best way. It feels like it should be a LOT shorter and more dynamic than what I have now. Any suggestions?
  5. Comment, sounds like a good solution. I'll have to make sure the revised layout stays 'sorted' no-matter-what, but otherwise, close enough. Thanks again. Should serve the need quite well!
  6. Ah! That must be it then, thank you! Browse mode is in fact needed. I wonder if anyone has sent that to FileMaker INC as a feature request yet. Seems to me like.. when specifying Portal details, instead of only accepting an integer for the number of rows, allow us to enter a formula as well if we want to. And 'somehow' make Body aware of that option too. Probably opening up a nasty can of worms by doing that maybe. Thanks for taking the time to look into it!
  7. Laretta thank you Could I trouble you for a tiny demo file? I am unable to get that to work, I get no action at all. I've double and triple checked but I must be missing something still... Food.fmp12 Food.fmp12.zip
  8. Greetings FileMakers! Is it possible to have a Body part as well as a Portal within that body part both resize, dynamically, based upon the number of records within that portal, within certain pre-defined bounds? For example: I have a table of Foods (in database speak, not in the literal sense). The Foods table has a child table called Ingredients. We show the Ingredients via a portal on the Foods layout. The Foods layout is Browsed in List View. The Body part is, say, 150 pixels tall. Within that, we stuff a little 140-pixel-tall portal showing a few rows. We could define, say, 4 rows. But that would be boring. Not all Food have 4 ingredients. Some might have just 2 ingredients, others might have 20 or 30 ingredients. What if I wanted that Foods layout's body parts and portal within to grow a bit for the "20 ingredients" and shrink a bit for the "2 ingredients" scenarios? Additionally, perhaps, grow and shrink within specific bounds, like, say, "never smaller than 2 portal rows, never bigger than 10 portal rows, scroll the portal if more than 10". Or is that asking for a pie in the sky? Specifically, I need them as portals, which is why I am asking about Portals, because some buttons are going also to live in the portal rows that do other things, which is why I am simply not doing a text concatenation of Ingredients if all I wanted was to only see a neat list of ingredients. Thanks!
  9. Quick question... How about using $$globalVars there in place of hard-coding? Any problems you can forsee using that approach? Thanks
  10. Excellent information, Comment. I shall try to implement this, thank you. If I get it working, I'll post the new file up here for anyone who wants to see. (Perhaps I should .zip it next time?)
  11. What I have: • A table of Animal. Four records in this example. Three fields: a primary ID (number), a Name (text), and Quantity (number). TheQuantity number field's contents gets changed by users at various, random intervals. • A table of Snapshots. Twenty records in this example. Four fields: a primary ID (number), a foreign key (for Animal), Date, and Quantity. • A script that runs once every 24 hours (perhaps from Server). The script simply looks at the current state of each record in the Animal table (Quantity), then goes to the Snapshots table, and creates one record for each Animal (foreign key), and its currently sampled Quantity. The result is a table which shows the state of the Animal table as it was when the script ran, once per day. What I want: • The goal is to chart this Snapshots data (Day-by-Day) using FileMaker's built-in native charts (no web viewer/javascript/etc), and also, to not use ExecuteSQL. • Bonus would be the ability to allow us to select which of the Animal we want to chart (we may not always want to chart all Animals) • Bonus #2 would be to allow us to select the date range of the snapshots (we may not always want to chart all snapshot days) Thanks!! Animals.fmp12
  12. Perfect, this works great! Produces the sub-summary's record IDs in the form of a return-separated list, which is exactly what I needed. This is so much faster and cleaner. Thank you very much!
  13. 1. I don't fully understand the question. I'll attempt to answer: There are records present representing all three Types. The sub summary layout is sorted by Type. Thus in my hypothetical example, you will end up with three sub summary sections when sorted by Type, each with some records in them. One sub summary section for Type "Paper", one sub summary section for Type "Glass" and one sub summary section for Type "Plastic". This is already built and works as expected, nothing tricky, nothing unusual. 2. The purpose is to have a list of IDs, stored in a variable in a script (or placed into a field), which will go to other parts of the database and perform any number of other operations outside the scope of this question, to which I am not at liberty to disclose. You could say, simply "to export them", or any number of other valid reasons to wish to have a list of IDs. To want a list of IDs is to want a list of IDs. That is the goal, to produce a list of IDs. I'll add: there will be a button in the Subsummary part. It is this button that should trigger the new, unwritten script that has yet to be built, which should gather the IDs of only the records in THAT particular sub summary part. If we end up with three Subsummary sections by Type, it follows that we will end up with three of these buttons, via usual operation of sub summary parts. Clicking the first button will yield a list of IDs for the records within the first sub summary part, and only those of the first sub summary part (all Type=Glass records). Clicking the second button should yield a list of IDs for the records within the second sub summary part, and only those of the second sub summary part (all Type=Paper records) . Clicking the third button should yield a list of IDs for the records within the third sub summary part, and only those of the third sub summary part (all Type=Plastic records). The found set can change. It is dynamic. Users can and will change the Found Set. When they do, the script they used to produce the new Found Set also re-applies the sort order by Type field, so the layout is always presented with active Sub-summary by Type parts. Thank you!
  14. I've got a Subsummary layout. The layout is based upon the table, lets call it "Materials". The subsummary part is sorted-by the field "Type". Type can have say, one of three possible values in it: Glass, Paper, Plastic. When we sort this layout, we get subsummaries by the types, Glass, Paper, and Plastic, as expected. There's a script that performs some Finds, based on user-entered criteria, to narrow down that list. What I need to do now is have a script gather the IDs of only the records under, say, Paper. And only Paper. Suppose three records are showing under Paper, I want those three records' IDs in some form or another. So far I've only been able to have it gather ALL of the IDs in the whole table (wrong), or, only gather the first ID under the subsummary part (also wrong). My third method works and returns the desired results, but feels "dirty", so i hope to hear about a better way. That is, I perform a Find based on the last known Find criteria, adding in to that mix, the ID of the subsummary part they chose (=Paper), to actually go find and truly isolate those three records in question, then I can gather their IDs. But that throws off my Found Set, is slow, and requires more work afterwards to restore the layout to how it was before. Not a great solution either. Any input would be appreciated. Thanks!
  15. Very good ideas there. Thank you!