addFoundSetFilterParam

I’m experiencing major frustration with getting this function to work. On two previous occasions I’ve called for and received help on this issue. However each time I still couldn’t break the mental logjam and put the issue to one side for later. Now I simply must break through with this filter’s functionality.

I have a solution that will be used by multiple clients. Each one should only see their own records no matter what they do. Thus the need for the addFoundSetFilterParam filter to work and be bullit proof.

When the user logs into Servoy the solution’s opening method fetches the security.getUserId(), does a lookup to a table to identify that user’s client id and stores that into a global.

Now the opening method runs the onLoad method of several of the forms:

forms.companyForm.controller.addFoundSetFilterParam('forms.companyForm.clientid', '=', 'globals.gclientid');
forms.companyForm.controller.loadAllRecords();

With the above the form loads zero records. If I alter the middle element to ‘==’ then ALL records load.

In truth, I’m simply rattling around, making guesses, finding nothing works, not understanding my results. Not a good strategy, at least in this situation. Clear guidance appreciated.

Discovered Bob Cusick’s tutorial on this function about 10 minutes after posting the above.

The major concept I had missed (and Bob didn’t highlight it either but was implicit visually in his demo). There are three arguments in this function. The first is a field name enclosed in quote marks. With the third argument don’t use quote marks if you’re specifying a field, include them if you’re hard coding a text or numeric value. Counter intuitive I know, but that’s how it is in 2.1.1.

I was also labouring under misunderstandings from earlier coaching.

  1. I was under the impression this function only performed when it was called by the onLoad property. Not true.
  2. Believed it could only be cancelled by quitting Servoy. Not true. You can break it by going into Designer mode and coming back to Brouse.
  3. I was under the impression that once you ran this function on one form it automatically applied to ALL forms without exception. Not quite that black and white.

The very good news is my muddled thinking has lifted and I’m now filtering. Thanks Bob.

tip: If you’re not certain about the syntax of a function, hover with your mouse over it in the method editor.
Attached image shows you that function asks for String/String/Object.

Not wanting to be argumentative, but the specifics of the syntax needs are not clearly spelled out, not there nor in the printed docs nor the online help.

I’m wary about raising shortcomings in the docs. Some readers of this forum over react. Writing docs are a delicate science. What’s clear to one is mud to another.

In this specific instance, there’s a requirement to include quote marks around the field in the first argument, but DEFINITELY NOT if there’s a field in the third argument. Not understanding this curious requirement left me baffled for months, posting repeatedly to this forum without effect. Bob Cusick’s new tutorial finally broke through.

I just wish people weren’t so defensive about Servoy’s docs. In my view, a miscommunication in the docs is much like a bug in code. If the docs send some readers barrelling off in the wrong direction, then that snippet of documentation needs reworking. Nothing to be gained in the blame game.

In other words, I’ve been holding back on my observations about the specific weaknesses in the docs for some time. I’ve been singed a few times. The docs are good, but there are definitely some bumps in the road.

Hi Morley,
please try the examples (in the method editor, right click with your mouse!) Or post your method that does not work on the forum. We are glad to help!

Morley:
Not wanting to be argumentative, but the specifics of the syntax needs are not clearly spelled out, not there nor in the printed docs nor the online help.

I’m wary about raising shortcomings in the docs. Some readers of this forum over react. Writing docs are a delicate science. What’s clear to one is mud to another.

In this specific instance, there’s a requirement to include quote marks around the field in the first argument, but DEFINITELY NOT if there’s a field in the third argument. Not understanding this curious requirement left me baffled for months, posting repeatedly to this forum without effect. Bob Cusick’s new tutorial finally broke through.

I just wish people weren’t so defensive about Servoy’s docs. In my view, a miscommunication in the docs is much like a bug in code. If the docs send some readers barrelling off in the wrong direction, then that snippet of documentation needs reworking. Nothing to be gained in the blame game.

In other words, I’ve been holding back on my observations about the specific weaknesses in the docs for some time. I’ve been singed a few times. The docs are good, but there are definitely some bumps in the road.

Morley,

Documentation is a VERY important part of the tools that Servoy provides.
As such, it is the posts to the Servoy Forum that contribute not only to
resolving unclear issues in the documentation but also affect the content
of the documentation as well.

For example, there were posts in the Forum and emails that were
received by Servoy that suggested adding all of the Servoy functions and
runtime properties as index entries to enable developers to find information more easily.
All Servoy functions and runtime properties (over 300 index entries) were
added to the index as of the Servoy 2.1 documentation.

More recently there have been posts that have pointed to bugs in the
indexing and search engine of the online Servoy Help Navigator.
These issues have been resolved as well as over 100 new index entries
added as of the Servoy 2.1.1 Online Help update and fixes.

We welcome any and all comments and/or suggestions regarding specific
documentation issues. The only way that we know what works (or does
not work) well for developers is if you tell us.

Regarding your particular comment about the addFoundSetFilterParam function:

Entering “add” in the Index tab search box shows “addFoundSetFilterParam” in the list of index entries.
Doubleclicking on this entry opens the “Form functions” topic.
Choosing Tools>Find and entering “add” in the “Find What” box highlights
the “add” of the form function addFoundSetFilterParam.

The example for this function shows:

controller.addFoundSetFilterParam('department', '=', 'sales');

This example includes exactly the same syntax as the “Move Code”
sample for the function addFoundSetFilterParam in Servoy Editor.

This exact same function and example is also available in
Servoy Developer Edition Reference Guide p.193.

What information regarding the clarity of using quotes around the first
argument and third argument of this function is missing?

What suggestion do you have that would help to make the Servoy
functions and their examples more clear in the documentation?


Marc Norman
Servoy

Sorry, I thought I was entirely clear. The example shows
controller.addFoundSetFilterParam(‘department’, ‘=’, ‘sales’) which is both incomplete and ambiguous.

The critical part is the third argument. In your example and all the supporting documentation I’ve seen, there’s nothing to indicate whether “sales” is a field or a string of text. The difference makes all the difference.

If the third argument is surrounded by a quote (as in your example) it’s treated as a string of text. However, if you want the third argument to call a field then that field must NOT have quotes.

The first argument IS a field and it DOES require quotes. As I explained in my original posting this is counter intuitive.

I’ve spent literally months attempting to figure out addFoundSetFilterParam and why it wouldn’t work for me. I’ve been on the forum repeatedly asking for help and have been sending eMails to Servoy support on this issue (as I detailed in my opening post in this thread). No one caught on that I was attempting to call a field and Servoy was interpreting my call as a string of text.

The omission of this critical detailing from the docs makes all the difference.

Morley:
Sorry, I thought I was entirely clear. The example shows
controller.addFoundSetFilterParam(‘department’, ‘=’, ‘sales’) which is both incomplete and ambiguous.

The critical part is the third argument. In your example and all the supporting documentation I’ve seen, there’s nothing to indicate whether “sales” is a field or a string of text. The difference makes all the difference.

If the third argument is surrounded by a quote (as in your example) it’s treated as a string of text. However, if you want the third argument to call a field then that field must NOT have quotes.

The first argument IS a field and it DOES require quotes. As I explained in my original posting this is counter intuitive.

I’ve spent literally months attempting to figure out addFoundSetFilterParam and why it wouldn’t work for me. I’ve been on the forum repeatedly asking for help and have been sending eMails to Servoy support on this issue (as I detailed in my opening post in this thread). No one caught on that I was attempting to call a field and Servoy was interpreting my call as a string of text.

The omission of this critical detailing from the docs makes all the difference.

Morley,

Your issue is noted. We will try when to be more clear and,
when appropriate, provide other examples and information that will also
help to lessen confusion in future documentation.


Marc Norman
Servoy

Just so I can understand what’s going on here, can someone explain why the arguments of addFoundsetFilterParam require quotes around some elements and not others. I’m sure there’s an underlying logic to it. The first element which is a field requires quotes but the third element (when it’s also a field) doesn’t.

While we’re at it, why is this function’s quote requirements so completely different from all other function arguments? Usually a field is not quoted but a text string is. With addFoundsetFilterParam it’s both different and internally inconsistent.

As I said above, I’m sure the decision to go this way isn’t arbitrary. There must be some element of structure I’m not catching on to.

Maybe this example shows the meaning of quotes

//search in the column with name = ‘department’
//and look for a literal string ‘sales’
controller.addFoundSetFilterParam(‘department’, ‘=’, ‘sales’);

//search in the column with name = the value that is inside the variable named department (could be sales, finance or whatever>> so this is crap in this context)
// and look for a literal string ‘sales’
controller.addFoundSetFilterParam(department, ‘=’, ‘sales’);

//search in the column with name = ‘department’
//and look for the value that’s inside the variable sales
controller.addFoundSetFilterParam(‘department’, ‘=’, sales);

so in other words…
using qoutes means: refering to a hardcoded literal string
not using quotes means : refering to the content of a variable

note: a variable could be a database column, javascript variable, global…

Hi Maarten

Much more flexible and subtle than I suspected. I’m actually running with a column name within quotes on the left side, and it works!?!
Here’s actual code:

controller.addFoundSetFilterParam('com_sev_id', '=', globals.gseven_id);
controller.loadAllRecords();

com_sev_id is a column in the table associated with the current form. Thus my confusion on how to treat field names in this function.

ok , so let’s focus on the first argument.
By setting this argument with ‘com_sev_id’ you’re telling the method
"go get me the database column that has the name “com_dev_id”

Suppose you would set the parameter with com_sev_id(without the quotes) and suppose com_sev_id has a value ‘1234’ inside the database.
Now you’re telling the method: go get me the database column that has the name “1234”. (which is cpomplete nonsense in this case)

so, again the essential part to understand is:
with qoutes means > the method accepts the exact string between the quotes
no quotes means > the method handles your parameter as a variable and will accept the value that’s inside the variable

Let’s clear up the confusion: SEE MY NEW TUTORIAL! http://developer.servoy.com

:D

Bob Cusick

Great job on the addFoundSetFilterParam tutorial Bob. Very clear!

The direct link is:

http://developer.servoy.com/generic.jsp?taxonomy_id=370

I hate to throw a wrench in the monkey works but…

How do I use this parameter through a related tabpanel.

In other words, I have a contact table with my main contact info, i.e., name, company, title. In a tabpanel on that contact table I have my address table information.

When I apply an addFoundSetFilterParam to a column in my address table it obviously doesn’t filter when the contact table is acting as base.

How do I run a method from the base table that also affects the foundset in the related tabpanel?

This would be awesome!

Can you give an example in what way you would want to effect the related foundset?
The related foundset in the tabpanel is already bound by the relation and I don’t see how addFoundSetFilterParam would fit in here.

I had a similar problem. Of course you can adapt the relation to do the same. But what about this simple example:

  • a tab panel shows sales per customer
  • the head of department sees all sales
  • a sales person sees only his product sales (a filter)

I thought I’d use a filter for that until I figured that it has no effect in tab panels. If you also use a table view for all sales with no regard to what customer they belong to, you have a filter there but not if used in a tab panel.

What is nice about addFoundSetFilterParam is that Servoy takes care of that filter in all occasions (searches and so on). I think addFoundSetFilterParam should just stay as it is, but a addTableFilterParam could be added to the application node. With that we could completely “block” certain records for a session wherever they are shown.

How about that?

Patrick

Maarten:

Part of my contact info resides in the base table (name, company) and part in a tabpanel (address info).

The information is related by way of contactid.

Not only do I want to limit the parent found set of the base table so that the user that created the record sees only those records, I also want to limit their ability to see the related address information in the tabpanel to those records the user created.

The way it’s configured now, when a record is created a column called origin in the tabpanel/address information is set to the users name.

I would like to filter this field based on who’s looking at the record.

If it’s easier to set the filter on the base table that’s fine. But it doesn’t seem to work either way. When I filter a column on the base table it doesn’t filter the related records in the tabpanel.

How do you addFoundSetFilterParam on related tables that deal with the same contact info?

Thanks!

Patrick, that’s a perfect example and you posted it during my diatribe which follows.

Thank you! Hopefully there’s an answer!

Maybe you can extend the relation contact_to_address using multiple keys?
CONTACTS contact_id~gUser_id :: ADDRESSES contact_id~user_id

(assume gUser_id is set when user logs into servoy client)

note: once addFoundSetFilterParam is triggered on a foundset
you won’t be able to populate this foundset again with other records (that are outside the filtered foundset)
So it’s always a one time action, which is commonly used with onLoad(form) event