Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Asu

  • Rank

Profile Information

  • Gender

FileMaker Experience

  • Skill Level
  • FM Application
    15 Advanced

Platform Environment

  • OS Platform
  • OS Version
  1. Script loses related records

    No, I have not run it in the debugger, as it is a single step (action c is irrelevant to the script, as it can be any other action that could be done on a set of related records. ) and the naked eye can see what happens. My guess was that something was not working in FM and Agi's post supports my suspicion. And thank you for the advice, I will return to FMPro v5 and do a search and find. As for indexing, I have tried every variation and their combinations on both ends but to no avail. Thanks for all yall's help
  2. Hi FM Mavens, this will be long, I am sorry. The following is the setup: Small medical office database I am writing for myself. 4 tables: "Pts", "Encs", "Rxs/RxDup" (patients, encounters, prescriptions - patients have several encounters, encounters have several prescriptions.) RxDup is a duplicate of Rxs but that is not why it is called RxDup, it is called that because it is used to duplicate individual medication orders. Mac OS 10.13.2, FMPro Advanced Task: (a) selecting an arbitrary number of records in a portal within Pts that looks at Rxs by setting the match field to a certain value (b) going to the records that become related via this act and (c) doing something with those records (duplicate them). (c) is not problematic. (a) and (b) are. Relationships: Pts - Encs via _PtID, Pts - Rxs also via _PtID, Encs - Rxs via _RxID and Pts - RxDup via _RxDupID. _PtID is a serial number of patients. It is added to every new encounter record for any patient in table "Encs". This is clear and it works as it should. _RxID is a combination decimal number obtained as _PtID + encounter serial for that patient * 0.001. So for patient #25, prescriptions written on visit 1 will be matched between "Encs" and "Rxs" via 25.001, etc. This also works as it should. As table "Rxs" also has _PtID, all prescriptions are visible from table "Pts". This also works as it should. All these are static values. I mention these only for the sake of completeness, there are no problems here. _RxDupID is the value of _PtID combined with the term "dup" (a text field) e.g. "25dup". It is the match field between tables "Pts" and "RxDup". In table "Pts" _RxDupID is a static calculation text field. In tables "Rxs/RxDup" it is a text field that can be set to the match value or to "". The setting occurs via clicking a checkbox on or off in the portal looking at "Rxs" from "Pts" via the _PtID relationship. The value list attached to the checkbox is the value of _RxDupID in the active "Pts" record, obtained via a Pts-to-Pts self-relationship using PtID. This also works, i.e. the value of the match field in the Rxs records seen in the portal is correctly set to the single value that shows up in the value list. I assume that this occurs in RxDup as well necessarily and simultaneously. (Am I correct?) The following happens: I open the database, go to today's set of patients. I go to one of the 5 patients whose records are in today's found set. Let's say it is Pt #25. I tab to the portal showing Rxs, let's say there are 30 previous rx orders showing. I click the checkbox in 3 records. I see it confirmed that the match fields are set to what they should be (PtID & "dup"). I run the script Go to Related Record [ From table: “RxDup”; Using layout: “Rxs DUPLICATOR” (RxDup) ] [ Show only related records ] Do (c) It does what it is supposed to do. It goes to the 3 related records in the correct layout and does (c) on them. Then I go to another one of the 5 patients in the found set. Let's say it is Pt #56. I tab to the portal showing Rxs, let's say there are 50 previous rx orders showing. I click the checkbox in 6 records. I see it confirmed that the match fields are set to what they should be (PtID & "dup"). I run the script again. Here it becomes dicey. There are a few ways things can go wrong here: - The script takes me to the 3 related records of Pt #25 and does (c) on them. - The script takes me to the related records of Pt #56 but not all 6 show. If I go back to the portal in Pts and run the script again, this time it may show all 6 records. - The script takes me to some or all of the related records of Pt #56 but in some records the match field is blank. (This really baffles me) Then it becomes really interesting. I go to a third patient in today's found set, lets say it is Pt #77. I run the script again. I get a 101 Error. The script does not go to the related records in table "RxDup", it stays in table "Pts" and runs (c) on the 5 records there. This repeats reliably. On first run, and sometimes on second, the script works well. On runs 2 - 4 it makes an error in going to the correct (or correct number) of related records. Eventually it does not go to the related records at all. The indexing of both match fields are set to "All". I tried "None" with "automatically create indexes" but the result is the same. My guess is that something goes wrong with the indexing but I could be wrong of course. Any help would be much appreciated. Thanks, Asu
  3. $contfield will be different depending on which field will activate the script, thence the need for a script parameter. wd/ht are calculations: GetContainerAttribute ( container1 ; "width" ) etc. I'm sure this could be tighter but this is just a test file. I tried adding explicit "-s to the FieldName but it still does not work
  4. Script parameter set by specifying Optional Script Parameter as GetFieldName ( Untitled::container1 ) or 2 depending on the field clicked. Yes, it resolves to Untitled::container1/2. And this is a simple test file with one table. I am not sure how to set two different script parameters with one step.
  5. Hello, I have a Case calculation that does not return what I expect wd1 = width of image in container1 , ht1 = height of image in container1 wd2 = width of image in container2 , ht2 = height of image in container2 A script would open up a popup window sized to the parameters of the image in the container. This is how it starts: Set Variable [ $contfield; Value:Get ( ScriptParameter ) ] //which is the name of container1 or 2 which it gets correctly Set Variable [ $ht; Value:Case ( $contfield = Untitled::container1; Untitled::ht1; $contfield = Untitled::container2; Untitled::ht2; "ERROR") ] Set Variable [ $wd; Value:Case ( $contfield = Untitled::container1; Untitled::wd1; $contfield = Untitled::container2; Untitled::wd2; "ERROR") ] The calculations return "ERROR". Which I don't understand as I would expect $ht/wd to be set to the corresponding numbers in ht1/2 and wd1/2. What am I doing wrong? Thanks
  6. Script to activate dropdown list

    Great, thanks. I was using a popup menu and indeed the "go to field" step was not working with that. I did not know there was a difference.
  7. Hello, I am wondering if there is a script step or or other mechanism which would cause the automatic activation of a drop-down list, or a pop-up menu, as if I had clicked on it.
  8. Dynamic portal sort

    sorter_asc and sorter_desc are both defined as text fields. The funny thing is that one half of the script works as it should but the other is totally off the wall. Or rather, the script does what it is supposed to do but the portal sorts what it is NOT supposed to sort.
  9. Dynamic portal sort

    Hello All, hoping to revive this old thread. I have created a script that uses the idea presented on FMHacks (http://filemakerhacks.com/2011/04/07/portal-sorting-part-2/) The idea behind the script is to create 2 sortfields, one of which will sort ascending and the other descending. A clever trick (using ScriptParameter) sets these fields to the contents of the various working fields in the portal. The script toggles asc to desc and vice versa so you can sort up and down with serial clicks. Set key to itself to redraw the portal So here is the setup: fields "serial", "FN", "LN", "sortfield_asc", "sortfield_desc" Portal sort order is by "sortfield_asc" ascending, "sortfield_desc" descending. Nothing else is in the sort order. Script is triggered and it sets "sortfield_asc" to "LN", "sortfield_desc" to "", and the portal gets sorted by LN in an ascending order. So far so good. What should happen is that if the script is triggered again, then it sets "sortfield_asc" to "", "sortfield_desc" to "LN", and the portal gets sorted by LN in an descending order. But instead, this is what happens: Script sets "sortfield_asc" to "", "sortfield_desc" to "LN", but the portal gets sorted by "serial" in an ascending order. "serial" is not part of any definition or sort order. I have the sort fields in the portal temporarily and I can see that they are set to what they are supposed to be set to but they are not sorted. For the life of me I can't figure out what is wrong here. Any suggestions, ideas would be most appreciated. These are the actual script steps: #These 3 variables must be set up in this order: Set Variable [ $sp; Value:Get ( ScriptParameter ) ] Set Variable [ $$sortDirection; Value:If ($sp = $$fieldName and $$sortDirection = "asc"; "desc" ; "asc" ) ] Set Variable [ $$fieldName; Value:$sp ] #Setting the primary key to itself refreshes the portal contents Set Field [ practice::_Gkey; practice::_Gkey ] This is what the portal setup looks like: 0Untitled.tiff
  10. Well, that's much better, thank you! While I have your attention: is there way to validate a calculation field for uniqueness? E.g. ding if in a new record both lastname and DOB are identical to an existing record? So to check if "lastname & DOB" is unique? Or to accomplish that in a different way? Thanks again.
  11. Hello FM Mavens, I would like to be able to change an attribute (happens to be the size) of a selection in a text window with a script. (Basically, as if moving the size selector from the Formatting Bar into a button on a layout). I created a script that cuts the selection, puts it in another text field, makes the change, cuts it out and goes back to the original field but by then the insertion point is gone. I can manually paste it back of course. I wonder if there is a way to remember the insertion point somehow and make it a so the paste step uses it. Thanks Asu
  12. Lee: Admin - blank indeed opened the file. Sorry I misunderstood your question. The permissions are the same for both files. LaRetta: The file is indeed in folder within a Dropbox account. Mac OS 10.11.5. FMP Advanced The restoration occurred from a Time Machine backup. No anti-virus sw. Asu
  13. Hello - I opened a very simple file I have been using for years (originated as v12 now 15) and it presented me with a password window. It is a simple index card file containing study material and it has never ever been password protected. I tried with my computer account info and it did not work. Admin-admin or blank-blank ditto. Again, it has never been password protected as it had no reason to be. Fortunately I could restore it from a backup drive, of course it was not password protected and it opened without a hitch. How could this have happened? Has anyone ever heard about such thing?

Important Information

By using this site, you agree to our Terms of Use.