How do I select multiple records ?

[mingmen]

I need a solution that lets you Shift-click (to select a series of records) or Ctrl-click (to select individual records) in a portal and then be able to delete those records.

 

Example (select # 1-5, 7,9).

 

Thanks

[Maarten Witberg]

single user or multi-user?

[mingmen]

single user

[Maarten Witberg]

I fiddled with this a little bit and it's harder than I thought.

Selecting multiple portal rows one at a time is easy enough, even multi-user secure if I'm any judge.

But selecting multiple fields in a sequence ( with two clicks) is something that I need to think about more - or hope someone performed that trick before and will share.

 

Trouble is I don't readily see a way, or maybe a very, very clunky one, to keep tabs on the records selected and guess the user's intention.

 

say you have rows 1,2,3,4,5,6,7,8

user clicks this sequence:

 

ctrl-1 ctrl-8 shift-4

 

would he want 1-4 selected or 4-8?

 

or seemingly simpler:

 

ctrl-4 ctrl-1 shift-8.

 

Now I know he wants to have 4-8, but I don't see a way to pick row 4 out of the registry (say something like $ListOfClickedRows) cos it's not the last click and the one but last, but the one before that, and really it could be anywhere. So I'd have to loop backwards or forwards as the case may be trough the related records, starting from the last row clicked, and test if they're already flagged, and if not set the flag. But it's clunky and unsmooth at best. Any ideas welcome...

 

PS Mac finder deselects cmd-clicked single selections that are before or below a shift-click and the first selected item it encounters. make sense? see what it does.

[mingmen]

Thanks

 

Seems like this is re-inventing the wheel...this is standard stuff in any word processing table,Excel or Access db. Even Filemaker, in Scriptwriter, lets you select using Shift and Ctrl.

 

Tried your example in Scriptmaker using an 8 line script. If you Ctrl 1, Ctrl 8, Shift 4, you get 4-8 selected.

 

You'd think this would be a standard function in Filemaker just like in Access. At one time or another, hasn't everyone needed to delete more than 1 record at a time. smiley-smile

[Ender]

Well, usually you're dealing with found sets. Basically, whatever it is about those records that you're selecting, you should have data in fields to give them common properties. Then you can Find based on that field data.

 

For example, if you're selecting Overdue records, then there should be data that indicates which records are overdue. Or if you're selecting records for people that you think should get an email, instead have a portal of related Mailing Groups attached, where you can assign different groups to different members. Once the data is in there, it's then a matter of performing a Find to get those records into a found set. Once you have the right found set you can work in them, print them, email them, or whatever.

[David Head]

You'd think this would be a standard function in Filemaker just like in Access. At one time or another, hasn't everyone needed to delete more than 1 record at a time. smiley-smile

You'd think it would be a standard function. But it is not. Maybe it will be in some future release.

 

Expecting matching features between products is somewhat dangerous. That is what makes them different products. They each have their unique feature sets.

 

For example, you would think that Go to Related Record would be a standard function in Access. At one time or another, hasn't everyone needed to go directly to a related record.

[Maarten Witberg]

you should have data in fields to give them common properties.

true in most cases... however I think there may be situations where there are none, or none apparent. For instance a notes table.

[Ender]

I guess you'd have to convince me.

 

In my mind, I want to be able to repeat the same search, or run the same report in the future to keep up to date on the status of my records. I don't want to rely on my memory to pick out which records I need, I want the data in there so they can be found automatically.

[mingmen]

This is one part of an Invoicing system for a particular customer. Products are invoiced but shipped at a later date, so the line items get added to a Pending file. The Pending file keeps a a running total of all items in it.

 

When ready to ship, two reports are created from the Pending file:

1.) a list of all items in the file (easy enough to do)

 

2.) A summary report that has 1 line item for each product category that was shipped, with an extended total for that product category. The extended totals are all summed to a Grand total, which is equal to all of the line items in the Pending file.

 

Am trying to build this in Filemaker and automate the whole process. Right now its a mix : Reports are done in Access. For # 2, the unwanted items are deleted using Shift-click or Ctrl-click. The new line item totals are entered manually, and the Grand total field automatically calculates the result.

 

Where to next ?

[Maarten Witberg]

Where to next ?

follow Ender's advice. And shift the whole thing to one app, either Access or Filemaker.

 

I guess you'd have to convince me.

Alright. Suppose you have a notes table for a project. You keep track of who it's about, when it was, when a call back's due, the works. But still, the notes are notes that can hold any information on anything.

Now during the project, it is decided there's a branch-off for some reason, and the project is split in two. Now you want to be able to select certain notes solely on what's in their note field, and while you may solve this with a clever search term, you can't rule out that term will cover all. So scroll-and-pick would be appropriate.

I would agree if you said this was scenario-spinning. Still it's a possibility. However for the current problem and based on latest information in post#10 I'd say look at the data rather than the UI first, just as you suggested all along.

[Ender]

Alright. Suppose you have a notes table for a project. You keep track of who it's about, when it was, when a call back's due, the works. But still, the notes are notes that can hold any information on anything.

Now during the project, it is decided there's a branch-off for some reason, and the project is split in two. Now you want to be able to select certain notes solely on what's in their note field, and while you may solve this with a clever search term, you can't rule out that term will cover all. So scroll-and-pick would be appropriate.

 

I would solve this differently. I'd change the data in the record so that it would then be matched to the correct project.

[Maarten Witberg]

Say you have 100 notes, about 70 must stay, about 30 must go to the new project. They are in random order, so timestamp, contact, or other straightforward information will not do. There are some clumps though, say of 5 or 6, but also single records. What data are you going to change?

[Maarten Witberg]

I mean except from the projectID which is what the procedure should result in.

[Ender]

I'd either classify the records as part of a different phase of the project (using some sort of value list attached to a field), or if the new project is actually a distinct, separate Project record, I'd change the foreign keys.

 

If this reassigning records is something that's a regular occurance, you could build an interface to make it fairly simple. It might have two portals, one for each Project's notes, with buttons to move them from one to the other.

 

Bottom line is, if the user has to look through all the records anyway, why not have them fix the data while they're at it. That way if they want to look at each Project's notes next week or next month, they won't have to manually sift through them all again.

[Maarten Witberg]

Ah ok, I think we're at cross-purposes here. the idea was, select a group and assign a different project ID to them (so they swap portals in your suggestion). I agree it would be pretty quick to just click them one at a time while scanning, but the original question was about selecting multiple rows with a start and end click.

[Ender]

And what's the point of selecting multiple rows (shift-click or not)? Presumably it's to do something with them.

 

My point is that it's easier to just have data in there that you can use to isolate those records in a found set. Then you can easily find them and do what you want with them, and not have to fiddle with selecting them out of a larger list.

[Maarten Witberg]

point taken... I'm not going to make up more theoretical situations to see if I can convince you it can be feasible in some cases to have a finder-like feature where you first select and then decide what to do such as here.

I already agreed that it's usually not necessary, but I tend to get carried away if it looks like my pet project. Oh Really!

[mingmen]

Have been playing around and have been able to put this together:

 

1.) I have a layout with a drop down Customer ID field and a portal to the Pending file whch shows the records for a particular Customer ID. A continue button runs a script Go To Related Record and copies those records to a second layout.

 

2.) The second layout has a radio button called Is_Checked with Yes/No for ech record so you can select the records you want. A Continue button runs a script (Perform Find[Restore]) for all records = Y, and gives you a new found set.

 

I've tried putting the radio button in the portal and then running the Perform Find script, but it's not working. Is there a way to do this ?

[Maarten Witberg]

I'm not completely sure I follow all that you want, but maybe here's a start. see sample.

[mingmen]

Thanks for the sample. Using your example, lets say there are 100 records in

the Pending file. The 8 records in the left hand portal are the result of a drop-down list where you selected a CustomerID (8 records for customer #1). That's what I'm able to do now.

 

Of these 8 records you select No for the ones you don't want to ship. Click a refresh button and the portal is updated to show only the records= Yes (the one's you're going to ship) with a new, revised total.

 

I was thinking maybe this could all be done in the left-hand portal in one layout.

[Maarten Witberg]

You could go two ways:

1- treat the Parent ID in the main table as foreign key from the customers table; the main table in my sample would then logically hold just one record. I don't readily see a reason to though.

 

2- treat the main table as orders table and store a separate customer ID as foreign key in this table. Then you can display shipping adress and so on in this table (and shunt it to the order items). This to me makes more sense.

 

Either way there is no need to script this. Just select the "yes's" and commit the record and you're done. Go to the child table to print shipping labels and so on.

[mingmen]

Thanks for your help. I've used the second method

 

Either way there is no need to script this. Just select the "yes's" and commit the record and you're done. Go to the child table to print shipping labels and so on.

 

I'm not 100% clear on this.Maybe I'm not using the right terms. What I've done is selected the "yes's", but if I only want to see those records, I go to my second layout (child table?) and do a find for "yes". Now I have a shipping list I can print.

[Maarten Witberg]

yes, or use the go to related records script step such as in the sample. btw. here is a slightly more extended sample on how to print line items.