Greetings FM community, 

Hopefully this can be useful to as many as possible. I've looked around and couldn't find the answer to this one, so perhaps it will be. 

Objective: to have a text string that filters in real time the values shown in a portal

How's:

-I have a portal inside a popover to display a list of records, in this case displaying names. In the Inspector, the portal's name is set to "PortalClients"

-Above that portal (see picture), is a text field (edit box) where the user can enter a text string to filter out the values shown within the portal. That field is called "filterString", and is defined within the layout's table as "text".

-In the text field's "Set Script Trigger", the "OnObjectEnter" and "OnObjectKeystroke" events are activated, and fire the script below: 

Beep

Refresh Object (Object name: "PortalClients")

-The beep's there just as a debugging cue, it works

-The portal has "Filter portal records", set to the following script:

Length ( t_Ventes::filterString ) = 0  
or
PatternCount ( t_Clients::Nom complet ; t_Ventes::filterString )  ≥ 1

-Yes, the filterString used in the above script is the same as the field's. Could that be the problem?  

-This is set up so that when the filterString is empty, all records show, and whenever it's not, the records are filtered accordingly.

Bottomline/problem:

-It works just fine, but the portal is not refreshed whenever a character is typed in. I have to close the popover, then reopen it for the changes to be there and the filtered records to show. Tried RefreshObject, and RefreshWindow, neither work

 

Any ideas?

 

Thanks!

 

 

 

 

 

 

 

 

Try attaching the following script to an OnObjectModify trigger for your filter field (“the object”):

#Make sure the object has an (arbitrary) layout object name
# 
Set Variable [$currentObject; Value:Get ( ActiveLayoutObjectName )]
Set Variable [$currentRepetition; Value:Get ( ActiveRepetitionNumber )]
Set Variable [$currentSelection; Value:Get ( ActiveSelectionStart )]
Commit Records/Requests [Skip data entry validation; No dialog]
# Refresh Window [Flush cached join results; Flush cached external data]
Set Field [ local match field of portal relation ; to itself ]
Go to Object [Object Name: $currentObject; Repetition: $currentRepetition]
Set Selection [Start Position: $currentSelection; End Position: $currentSelection -1]

The portal has "Filter portal records", set to the following script:

Length ( t_Ventes::filterString ) = 0  
or
PatternCount ( t_Clients::Nom complet ; t_Ventes::filterString )  ≥ 1

​Just to be nit-picky: that's a calculation, not a script … and you could write it more succinctly as

IsEmpty ( t_Ventes::filterString )
or
PatternCount ( t_Clients::Nom complet ; t_Ventes::filterString )

… though that's considered to be a matter of style

 

Yes, yes, and YES! Vielen danke!

Works exactly as hoped for, but hardly expected. This somewhat limits my satisfaction, as working through the script steps left me puzzled at the logic behind, and frankly, grasping for understanding. Hopefully your answers can help anyone else too.

You've been very generous with your time, but if I may ask, for clarity's sake (questions in comments, above pertaining code blocks)

#I understand the field's state must be saved before proceeding with using its value

Set Variable [$currentObject; Value:Get ( ActiveLayoutObjectName )]
Set Variable [$currentRepetition; Value:Get ( ActiveRepetitionNumber )]
Set Variable [$currentSelection; Value:Get ( ActiveSelectionStart )]

#why do we need to do the following? Is committing the new state of the match field's value whenever it's changed necessary?
Commit Records/Requests [Skip data entry validation; No dialog]

#this is the instruction that leaves me most puzzled. Setting the field... to itself?

Set Field [ local match field of portal relation ; to itself ]

#make the field with the filter string active again
Go to Object [Object Name: $currentObject; Repetition: $currentRepetition]

#??
Set Selection [Start Position: $currentSelection; End Position: $currentSelection -1]

Thank you so much again,

 

 

 

#why do we need to do the following? Is committing the new state of the match field's value whenever it's changed necessary?
Commit Records/Requests [Skip data entry validation; No dialog]

#this is the instruction that leaves me most puzzled. Setting the field... to itself?

Set Field [ local match field of portal relation ; to itself ]

#??
Set Selection [Start Position: $currentSelection; End Position: $currentSelection -1]

​If you're using Commit[], you need to save the current object's (text field) name to be able to re-enter it; also capturing the current selection means that your insertion point (aka cursor) can be placed at its former position (which may not be the end of the field's contents), so the user experience is seamless.

Setting a match field to itself will force FM to re-evaluate the relationship and thus refresh the portal; this is less expensive then flushing all join caches.

Commit[] is necessary to have the refresh step work reliably; you can try if Set Field[] alone is sufficient for a refresh, in which case you wouldn't need the other steps. (In brief, just experiment a bit …)

Thanks! I'll experiment with this.