Kahuna:
Shame it cant be rolled into the 5.x series of updates as it would be an embellishment rather than a limitation for current functionality and already deployed solutions. I’ll stand to be shot down, but if developers have already used the filter params they will be overwriting each other
I’m using filters in many big solutions and they are working perfectly for me, an implementation change in 5.2 would break everything so: don’t stand Ian, I could be the one pulling the trigger
David is right, SaaS is very complex, even in Servoy. You need patience and some trial and error to make it right.
I see your point Nicola - but you know if there was a modified filter param with a switch to NOT overwrite filters that defaulted to overwrite, your solutions would not break - or at least I can’t see why that couldnt be achieved.
david:
Looks like you have your value parameter wrong. When using the “IN” operator with addTableFilterParam(…):
1- You need to pass in an array in the value slot.
2- If there is only one value in the array, it will fail. Need to use the “=” operator and a non-array value instead in this case.
No
You can use an array or you can use, as Ian is doing, a sql query.
No
If this was ever a limit, then this is fixed in Servoy 3.5 where I rewrote the sql generation.
Rob
Cool, been looking at code (and our copious comments) that we figured out way back in Servoy 3 days – before multiple table filters, before foundset filters, etc. Still works which is cool but with your upgrades coming in Servoy 6 that will be our opportunity to retool our filter engine code. Like the idea of applying layers of filters – would really make the logic behind our filter UI’s much easier.