Do both layouts refer to the same table occurrence? (Same box in relationship graph is listed in Show Records From of Layout Setup...)
The reason I am asking is that when I use FileMaker 11 on Windows XP, the list layout automatically scrolls to put the current record into view on the list view layout when I switch from the form view layout. The current record may be the bottom record on the list, but it's visible.
(If the layouts refer to different Table occurrences of the same data source table, they'll have different current records and thus you won't see this happen in that case.)
Yes, they are based on the same table. I am not just switching from form to list view of a given layout though. I'm switching to another layout. It does keep track of what is the current record because when I have the script step to go to name field it goes to the name field in the same record at the form layout did, but if that is below view then I have to manually scroll down. This is current FM11 pro and W7.
I got it to work a weird way. I have to do two script steps, edit some field, which I do by assigning a field its own data (set(namefield, namefield)) and then go to a field. But that doesn't work if it's part of the script that goes to the layout. Instead it has to happen after a delay. So the script that goes to the layout does that step and then sets a timer for a timed script a second later. That script does the Set(...) and the go to field and then shuts down the timer.
So how are bug rerports given to FM. Trying to find it here just let back to this forum.
Report an Issue at the top of the page is intended for reporting possibile bugs. I'm not convinced that this is a bug, however. What I described earlier was indeed two different layouts that refer to the same table occurrence. This is not the same as saying both layouts refer to the same table as you can have different table occurrences to the same table and it's possible for your layouts to then refer to different table occurrences and then your two layouts will have different current records.
Let's try this test. Down load my Known Bugs List database:
It has both a form view layout and a list view layout of the same bug report table occurrence. Click the bug reports button to go to the form view layout. Select Show All Records so that all records are in the found set. Click through the records to select any given record. Click the List button to switch to the list view layout. On my system, the current record from the form view layout will be visible on the list layout and highlighted in yellow courtesy of a conditional format. (I disabled this and tested to make sure that it wasn't a factor.)
If you don't see the layout's scrolling as expected in this file, then I'll agree that you have a possible bug to report specific to Windows 7. If it scrolls as I expect it to, then you'll need to take a closer look at your layouts and see if there's some other factor involved here--such as a script trigger that's firing a script when you didn't expect it to or something.
I think I know why it was misbehaving. I was forgetting how I had built the list view. I didn't want repetitions in the list. To use a sales example I wanted a list of unigue sales people by unique first name, last name, city, but not repetitions if their name and city were associated with several accounts. I just wanted the list of names and cities to choose one to then go to their detail. So I made a layout that had a sub-summary field and no body so the sub-summary field just showed a given name/city once. So that sub-summary name/city doesn't really correlate to a particular record so I suspect that's why it wouldn't behave as expected.
Is there a better way to a list like that and not show the duplicates?
The method you've used is the same as the one I usually choose. You can also create a related table that does not have the duplicates, or you may be able to construct a find that drops out the duplicate values. You can specify a different table occurrence of the same table to keep this from affecting your form view layout. Of course this means that scrolling your window now has to be scripted if you want the current record of the other layout to be visible in the list layout.
Actually that was something I wanted to get back to at some point. I don't see a way to do a find that eliminates dupes of the find criteria. I find lots of info on how to find dupes, usually for the purpose of deleting them, but nothing on how to avoid dupes, other than the subsummary which is not really showing a field, just a summary break. Do you know of a way to make a find that does that?
Re another instance of a table, I wouldn't have thought of that. So you just drop another copy in the relationships box even though it won't have a self reference? Makes sense but I would have never thought of it.
Let's say records are duplicate if Field1 has the same exact value:
Then you can create a self join relationship:
YourTable::Field1 = YourTable 2::Field1
Where YourTable 2 is a new table occurrence of YourTable. You can then define a new field, UniqueFlag, that uses a looked up value setting to copy YourTable 2::Field1 into it.
If you perform a find that puts a lone = sign into UniqueFlag to find only those records where UniqueFlag is empty, you'll automatically omit the duplicates from the found set.
This method can be a bit fragile as editing field1 after the fact--even if you delete and retype the same value, will trigger the lookup and this can then result in the given value from being included in the find.
Another approach is to periodically run a variation of a script that marks duplicates for deletion, just don't delete the records. Your find can then be set up to omit records where the "mark" field has a value.
So you just drop another copy in the relationships box even though it won't have a self reference?
Yes, and this is one of two ways to maintain multiple found sets, sort orders and current records for the same table. (You can also use a hidden, new window for this, but this can create window resize issues in Windows Systems if they have Maximized the application window.)
I could never get your method to work but in playing around with it I did get the help file method to work. when I looked at the help file before all its references were to finding duplicates, not filtering them out. At the very bottom of all that is a link to "another method" with the self join. Since I already have a unique field (the key field) I didn't need to make their serial number field. I did find a little about the importance of sorts, and of having multiple copies of a table in the relationship window to keep sorts and finds for secondary purposes from messing up your main layout. I also see why the default script template includes sorting. Seems the sorting is frequently lost by things like find actions. I still have to recreate a layout with the new method of filtering duplicates so then I'll see if it scrolls correctly to the right line.
I'm missing something here. If I have a list or table view and I want the user to type in a name in a dialog box and have it jump to that name IN THE LIST, how do I do that? I can do a find or quick find but that trims my list down to just that. I want to keep the list and go to a given record. I don't have the record number in advance so GoToRecord(#) doesn't do me any good. I might be able to have the record ID (get(recordID)) in advance but don't see any corresponding GoTo(RecordID). Not even sure what good Get(RecordID) is since you can't seem to do anything with it.
As a side note even when I do a Find I have to have the field on the layout. So if I want to find by serial number field I have to have that on the layout even though it's under-the-hood stuff i don't want to confuse the user with. Again, either I'm missing something or this is all as easy as pie if I think like the FM programmers and I still haven't figured out what that is.
Option 1, write a script that loops through the records using go to record/request [next ; exit after last] to move from record to record. Use Exit Loop if to exit the loop on the first record with a matching value.
Option 2, Defiine a self join relationship matching your global field to your name field. Then use Go To Related Records, without specifying "show only related records" and it will make the first matching record the current record and will not change the current found set unless the matching record is not in the found set. If it's not in the found set, it finds all records, then goes to the record as before.
I considered a loop but, sheesh, what a slow way for FM to find a record. Option 2 still starts from some previous layout that has some record selected. (I assume your reference to a global field would be some field with global storage that, what, calculates as equal to the current name field?) I don't see how I can apply that to popping up a dialog box and having a user type in a name to jump to in a list. Or am I missing something?
This can all happen on the same layout if you define the right relationship.
Define a global text field, gName in the same table as your list.
In Manage | Database | Relationships, make a self join relationship linking the global name field to the local name field:
YourTable::gName = YourTable 2::gName (create YourTable 2 by selecting it and then clicking the button with two plus signs.)
Now you can open a custom dialog with an input box linked to gName.
Use GTRR, specifying YourTable 2 as the table, but leave Current Layout as the specified layout.
I'm feeling very dense here. If I get input from a dialog into a global field, how does it know that the "Smith" I put in the global field, that I want to find the record where LastName is Smith? And how does doing a self join from a global field to a global field tell it anything? Doesn't every record match that criteria?
I tried this and my script is:
Go To Related Record[From Table: "Maintable2"; Using layout: <current layout>]
Also you've been very responsive and I've wandered far from my original topic so I should probably start a new one so it's under its own topic. I'll play with it a little more and do that.