The piece of equipment is selected and added to the equipment list on the next layout, but the tick doesn't appear in the checkbox list, which could create some confusion for the user if the piece of equipment is selected or not. The list is quite long and a scrollbar is required so not sure if that has anything to do with it. Do you know why this is happening?
Does it never appear or does it appear after you enter layout mode and then return to browse mode or after closing/reopening the file?
The second issue could be very "sticky". If the script is changing layouts to create a new record or delete one in a related table or using commit records to try to get the layout to refresh (item 1 above), either of those actions will cause the portal scroll bar to "snap back" to the original position.
It is very intermittent. The items at the top of the list seem to be ok, but the ones at the bottom don't seem to work too well. More often than not, they never come in, but if you enter layout mode then back to browse mode they SOMETIMES appear. There is no pattern to it. Sometimes they do but more often they don't appear. Same applies when closing/reopening the file. Occasionaly, when I reopen the file there are no tick marks present, then you click one of them and they all come back. Like I said, unfortunately no pattern to this.
As for the second issue, the script (which came from you) does change layout to create a new record. I'm guessing there is no way round this as it seems the script changes layout then comes back to the same one without appearing to do so.
I'm trying to determine if the first problem is a screen refresh issue or a case where a field is either not getting the value it should or that a record is not being created with the necessary values. Have you checked to confirm that the fields/tables involved have the correct data? Am I remembering correctly that we are using conditionally formatted layout text to show which items on the list are selected? You might try going old school by defineing a calculation field that returns a value to show which item is selected.
The change in layouts is what is causing the portal scroll bar to snap back. I'm mulling over a pair of alternative approaches: A script that uses relationships to create/delete the needed related records without changing layouts or opening a second window and creating the needed related record via a specified layout in the new window. In theory, both approaches should keep the portal scroll bar from resetting.
Yes, the fields and tables have the correct data. There isn't much to it to be honest, just a new equipment record and that's it. Yes you remember correct, the text is conditionally formatted to show a tick mark when the equipment item is clicked and tick mark removed when it is clicked again. Sorry, can you explain a little more re the calculation field that returns a value? Do you mean as a substitute for the conditionally formatted tick mark?
If possible, I would like to avoid deviating away from the current layout i.e. opening a second window to create the needed record, but whatever you think is best and easiest.
Yes, that would substitute for the conditionally formatted tick mark. But before you try that, see if any combination of:
Refresh Window [Flush Cached Join Results]
works to correct the display issue. (But this will also cause your portal's scroll bar to reset, so this is may not be the best alternative here.)
I would like to avoid deviating away from the current layout
What I am thinking of here still leaves the user on the current layout in the same window. The script would open a new window, create the related records and then close the window as a way to keep the scroll bar properly in place. But this may not avoid window refresh issues where updating the current window also resets the scroll bar on the portal.
You may also want to consider using methods that segment the items in your portal into smaller sub groups to avoid/minimize the scrolling. A drop down above the portal can be used to select different sub groups of items or you can put several filtered portals inside a set of tabs in a tab control. Either way, the user selects a group of portal items then interacts with them in the portal.
I forget: Are you using mac or windows? Filemaker 11 or 12?
I am on a mac using FMP12.
1st Issue: Ok, I tried all those suggestions, plus all of them together but nothing happens. I'll try redoing the conditional formatting see if it makes a difference. Otherwise any other suggestions?
segment the items in your portal into smaller sub groups
I have actually looked into that already as that would be more ideal than having one long vertical scrollbar. I came across this, http://fmforums.com/forum/topic/475-horizontal-portal-layout/
I was thinking though, instead of having one portal with a drop down to select a sub group, it would be better if I have for example 4 portals that displayed the groups all at once. I would think though that each of those portals would still need a drop down to select the appropriate subgroup?
I tried to change the downloaded FM file (from the link above) to have more than one portal, however, I was unable to do so. Each portal showed the subgroup that was displayed in the first portal. In database manager I duplicated the gGroupSize, gGroupNumber and the calculation field and created a new table occurance of the Child table but didn't work. What am I missing here?
Apologies, but I've been tossing general approaches to this at you without specifics as I haven't had the time to work up detailed descriptions nor tested them.
I did find this demo file that puts check boxes in a portal without using conditional formatting: https://www.dropbox.com/s/ti8vep64h67mtj2/CheckboxWScrollBar.fp7
You could set up a group of portals where a portal filter limits each to a sub set of the total. To save layout space, you might place each inside a different tab panel.
I wouldn't, however, use the standard horzontal portal method as it doesn't filter the records shown down to specific groups, it just breaks up a long vertical list into columns or a single horizontal list. I'd think the user's would find it easier to find the equipment they need to work with if they first selected "category 1" to get all equipment for category 1 and then selected a different category to see all equipment in a different category.
Thanks for the demo file. I think I will have a rather large issue if I set it up like that file. I noticed that the 2 table occurances All Products and Selected Products are from the same data source table, Products. I however have those equivalent occurances in my database (All Equipment and Equipment_List) based on 2 different data source tables, Equipment and Equipment_List respectively. Now the rest of my database is pretty much built around the selection and non-selection of equipment from these tables so I am really not wanting to make any major modifications that will likely affect the database further down the line.
You may also want to consider using methods that segment the items in your portal into smaller sub groups
How would I assign the items to a subgroup when I create the Equipment record? Would I need to create a field to assign the item to a category? Would the portals then be filtered based on those categories created?
Yes, but don't change your structure, just use the demo file to understand how the calculation field works with a checkbox format. A list of values in a field--what the demo file uses--has identical structure to a list of values produced by using List ( RelatedTable::Field )
So the code to manipulate the list of values used in the demo won't work for your solution, but the formatting of the calculation field would if adapted to your actual design and since this elminates the conditional formatting, it may refresh more reliably.
For your last question, see the discussion of portal filtering I just added to one of your other threads for one possible example.
Ok, so I have categorised the equipment and setup a group of portals, each filtered to one of the categories and placed each in a different tab panel. It solves the problem of the tick mark not appearing on the "bottom" items of the list. Clicking on them all makes the tick mark appear/disappear. So, that problem solved! THANK YOU!
The problem that still remains when I select an item say in the 4th group portal, once I click on it the tab panel jumps back to the 1st tab panel automatically. Basically, the same as before with the portal jumping back up to the top of the list. Maybe I will just have to live with this for the moment.
Fortunately, that's an easy problem for your script to handle.
Enter layout mode
Select each tab panel and use the name box on the inspector's position tab to give each an object name. (click the tab control once to select the whole control, then click a tab to select a specific tab panel.)
Then your script can use Go to Object ["TabPanelObjectNameHere"]
to reselect the correct tab panel after your script has returned to the original layout.
Sorry Phil, which script are you referring to? Are you referring to the one where the equipment is selected/deselected in the portal?
How would it go to the right object though? If I put the Go to Object script after the Go to Layout (original) and enter for example the name of the 2nd tab, then every time I click on an item to select it, it will go to that 2nd tab instead of the one that I just selected the equipment in.
You perform the script from a specific tab panel that changes layouts, adds a record and returns to the original layout do you not? This may be the same script on every panel or a different script, but you can pass the object name of the panel to the script as a script parameter.
You can also use script triggers on the tab panels to capture the current panel and store its object name in a global variable. FileMaker 12 introduced some new triggers and new get functions to make this easier to script, but it can also be done in earlier versions.