OnRecordLoad is only tripped for one record in the found set shown on your list view.
To select different tab panels on each record, you'd need to use some system that loops through all of your records, selecting a tab panel for each record in the list.
On the other hand, You might be able to use two one row portals that link via a self join to the same record, but only if a particular value exists in a field in that record. The field in the portal row of one portal can be formatted as an edit box and as radio buttons in the portal row of the other portal. Then the relationship based on a match field that can have a different value in each record controls which control format is visible.
Thanks for replying!
Looping would be fine, but on the last record, it would still change all the records tabs to that kind. It wouldn't save the tab panel for each record.
And would the two portals, would they be side by side? Then the self join would be related by ID and a field that has the different value. So essentialy only one would show up in one of the portals. I suppose I could conditionally hide the one, but I could probably do that without a portal, I think, with conditional formatting.
I see what you mean about the tab controls. Seems odd that all the tab controls stay "synched" like that but it definitely rules out using them in this situation.
The portals will not both be visible at the same time. Their borders etc would be set to be transparent and nothing would appear in them unless the value of the field that controls the relationship has the correct value to make a record appear in the portal.
See this demo file for an example of that: https://www.dropbox.com/s/8levaz6deiyzjr8/LayoutObjectVisibilityControlDemo.fp7
And it might be possible to place the two portals on top of each other, but I'd have to do a bit of experimenting to see if that is really possible.
Thank you for the file!
I converted it from .fp7 to .fmp12, which acts only a litle bit differently, but not on the example you were trying to explain to me.
Anyways, thanks again for your help. I will try the portal thing, will report back if it works. (the layering part)
You may need to put a transparent button over the stacked portals such that clicking it runs a script to put the focus in the correct field of the correct portal. You may need to give the fields object names and use go to object in order to do that if you are using the same field with different formats in both portals.
Thank you Phil!
So the portal stacking makes it look exactly how I want it to. However, even with the transparent button going to named fields, it still doesn't allow ability to access the field. (Closest I got was to put the Edit/Fill-in box portal underneath the Multiple choice portal. Make the Multiple choice portal as skinny as possible, and the fill-in as big as possible. So you can still click in the Fill-in, but not where the portal is for the multiple choice.)
What I did do, though, is create another script assigned to the onRecordLoad. It would redirect to a different layout that looks exactly like it, but the stacking of portals is different. Then it would go to the correctly named field. It seems to work well enough, without double clicking or having fields bounce. (Tedious to set up and maintain, but there are only so many control type anyways, so if I had to make other layouts it would work, just looks messy in layout mode.)
(I'm glad I don't have to do this on the web.)
Also, did you know that you can layer fields? and if you put one on top that does allow access in Browse mode, then you can access the field underneath, if it allows access in Browse mode.
Also, did you know that you can layer fields?
Yes, I do that all the time by hiding drop down lists behind related name fields.
I've just finished playing around with stacked portals and at least in FileMaker 11, I could get them to work after a fashion. I used the OnRecordLoad trigger instead of a transparent button to put the focus in the correct field in order to make them accessible. That's still a big quirky though since clicking the background can lock you out of the field.
Oh, man, the new things I learned.
Ok, just as an update I changed the several self related TOs to only one, related by ID. Then I used the filter portal records option instead. It works the same as the other way. Now if I want to add a different Control Style I don't need to add another TO. (Not much of an improvement.) (Note, need to use Refrew Window with Flushing of Cache results to get some things working.)
Anyways, I think I'm done with that. Thanks!
(Note, need to use Refrew Window with Flushing of Cache results to get some things working.)
This is a common and undesirable result of modifying the value in a field or variable used in a portal filter expression. It's undesirable because as your data sets grow and you move from test and development into the real world, it can lead to very long delays while waiting for the screen to update--especially, I'm told, with iOS clients using FileMaker Go.
You can, however, eliminate the need for this in most cases if you use the X operater between at least one pair of match fields in your relaitonship and include all the modifiable fields used in the filter expression as match fields in the relationship.
In some cases, that's the only way to go for a filtered portal. In other cases, you may realize that since you need to include the fields in the relationship, you might as well do the filtering at the relationship level and eliminate the portal filter expression completely.
Thank you for letting me know!
I will change it back.
So I changed it back, and it works. However, I realized why I want the filter portal calculations. The way my db is set up the differing field is set up in another table. If I change that value, it doesn't seem to update in the current answer table I have. So I made a calculation that would updated, but that field doesn't work in relations very well. Using filters you dont have to worry about the relations, just worry about comparisons in the filter calculation.
But I will still keep the several portal way, in any case, and see if I can somehow get that to work better.
You may, however find that your unstored calculation field that you are using to reference data in the other table will work for you as long as you take an addedd step to refresh your window, but without the "flush..." option selected.
You may also want to take a look at how the filtered portals in this demo file refresh with each keystroke while avoiding the use of a Refresh Window step to do so: