selecting multiple rows in a portal

[nangko]

Hi,

 

I want to let the user select multiple rows in a portal, so they can do some action with the selected records (print, change status, delete etc.).

 

In this example I will speak of a portal with invoices as portal rows.

 

I'm thinking of the folowing stratagy:

 

1) create a global field "selected_invoices" wich will store the primary_keys of the selected invoices in the portal. (this way it is muliti user compatible)

 

2) create a button in the portal row(s) that wil store the key of the invoice in "selected_invoices" when pressed.

 

3) Highlite the portalrow text when the invoice key is in "selected_invoices".

 

This will be the first try, i don't know if it is possible this way, but I'll try it.

 

If anyone has some tips for this problem, they are very welcome!

 

Thanks in advance!

[nangko]

I can now select one item at the time

Ok I've got it working for one item.

 

STEP1) I made de text of the portal function as a button running the following script:

Set Field[inovoiceManagement::selected_id; Invoices::_pk_id]

 

STEP2) I created a conditional format for that same piece of text:

Formula is InovoiceManagement:: selected_id = Invoices::_pk_id

If the formula is true, the text will highlite (change collour and underline)

 

Now if I click the text in the portal row, it highlites

If I click the text in another portal row, that piece of text will highlite (and the other one returns too normal state)

 

Now I need to change the following so I can select multiple invoices.

 

STEP1 Has to put the Invoices::_pk_id into the next empty repetition of InovoiceManagement::selected_id (if the value is NOT allready in one of the repetitions)

 

and STEP2 Has to be true if InovoiceManagement:: selected_id "is in one of the repetitions from" Invoices::_pk_id

 

I think I'll have to use "Last() for step one".

 

But I haven't got a clue about how I should fix STEP2.

How do I make a calculation which compares a value against each repetition of a field?

[Ender]

I think your plan to insert the selected invoice IDs into a global is a good one. Except, I think it will be easier to manage if it's a single text field with return-separated values. You can then use text parsing and value parsing functions to locate and extract values.

[nangko]

Except, I think it will be easier to manage if it's a single text field with return-separated values. You can then use text parsing and value parsing functions to locate and extract values.

Yes, after ours of searching for solutions with repetition fields, I could not find anything helpfull end stopt with it.

I'm allready busy building this solution with a text field.

I'll post it if I'm done.

 

But still, working with repetitions seem to me a better solution.

Because you can use them for relationships and you can use consistant validation.

 

It's like: in JAVA I would use array's and not text variables.

 

If there were some good functions for working with repetitions (like find_repetition, push_repetition, sort_repetition etc.) it would be easier to develop more consistent. (but that's my opinion)

 

[Ender]

The good news is that you can use this multi-line text field as a key field for relationships, and each line will be matchable. This is essentially the technique for creating an OR relationship.

[nangko]

The good news is that you can use this multi-line text field as a key field for relationships, and each line will be matchable. This is essentially the technique for creating an OR relationship.

 

OW ok. I did not knew this. I thought creating an OR relationshop is only possible with repetition fields.

 

So in the end it's a good solution and it only (for me) feels like a not so pretty solution.

But I guess developping in OO languages with arrays and classes get's me a little bit spoilled

[Ender]

Ya, FileMaker is a different kind of animal. It's certainly not OO.

 

You're best to put repeating fields out of your mind until you understand the other tools better. Repeating fields are occasionally useful for some utility purposes, but more often get people stuck into corners.

 

Lists (multi-line text fields) are a great substitute for arrays. They are preferable because you can treat them as arrays if you wish by referencing their index:

 

getvalue(field; index)

 

or you can treat them as stacks or as queues. And you can use functions like list() and getnthrecord() to build lists based on record sets. And since you can process lists in calcs or CFs, you can massage them however you need to to produce filtered keys.

 

You could for example take related record sets from multiple sources and produce a key with a union or an intersection.

[nangko]

Set Field[inovoiceManagement::selected_id; <-calculation below->]

If (
FilterValues ( InovoiceManagement::selected_id ; Invoices::_pk_id ) ;
Substitute( InovoiceManagement::selected_id ; Invoices::_pk_id & ¶ ; "" ) ;
InovoiceManagement::selected_id & Invoices::_pk_id & ¶ )

 

logical said:

 

IF id in selection_list

THEN remove id from selection_list

ELSE ADD id to selection_list

[nangko]

Post above was STEP1 (push,pull id's in selection field)

 

STEP2 (higlite if selected) will be:

Conditional format Formula:
FilterValues ( InovoiceManagement:: selected_id ; Invoices::_pk_id )

 

OFFTOPIC: is there a way to edit my post? I cannot find a button for editing my posts??

[Ender]

Be sure to check your scripts when there are no values and when the only value is the one you are trying to filter (adding then removing the one selection). You may need to append a ¶ to the selected_ID list before you can substitute an ID out.

 

OFFTOPIC: is there a way to edit my post? I cannot find a button for editing my posts??

I believe you need to be a paid member to have that capability.

[nangko]

You're best to put repeating fields out of your mind until you understand the other tools better. Repeating fields are occasionally useful for some utility purposes, but more often get people stuck into corners.

 

Lists (multi-line text fields) are a great substitute for arrays. They are preferable because you can treat them as arrays if you wish by referencing their index:

 

getvalue(field; index)

 

or you can treat them as stacks or as queues. And you can use functions like list() and getnthrecord() to build lists based on record sets. And since you can process lists in calcs or CFs, you can massage them however you need to to produce filtered keys.

 

Thanks for your explenation, I will put repeating fields out of my mind (repeating field took a lot of my developing time ).

I'll focus more on lists. The CFs for managing stack and queue data will be quite handy and are helpfull learning filemaker scripting.

[nangko]

Be sure to check your scripts when there are no values and when the only value is the one you are trying to filter (adding then removing the one selection). You may need to append a ¶ to the selected_ID list before you can substitute an ID out.

 

I checked it and for selecting/deselecting it works fine: I always put a ¶ after a value. So I gues there is always an empty value at the end of the selected_ID list.

 

Maybe it will give errors when working with relationships. Later I will create three CF's:

1) list_push(value) adds value to list

2) list_find(value) returns true if value in list

3) list_remove(value) returns value and removes value from list

 

In those CF's I'll put some extra checks for the (first value of the list) to keep the List tight and clean.

[Ender]

Sounds like fun (CFs are always fun for programmer types).

 

For relationships, you need not worry about extra blank lines in the list. Those don't affect anything.

 

From my experience, I'd say be sure to test for adding and removing the only value in a list, retrieving and removing the first and last value in a list. And just as importantly, check that only whole values are recognized (not substrings). You don't want false-positives, like '123¶' hitting on '456123¶' (this won't match in a relationship, but could for a text parsing CF).