Founsets are shared by all forms of the same table. Until you start modifying the foundset on one form via a method (say a GTRR method or a loadAllRecords step). Then the forms become disconnected.
It would be useful to be able to link the foundset of one form to another (as a property maybe?). This would save a lot of foundset management in cases where I have a lot of tab panels showing the same table data.
Not sure what you mean David but by default,
x forms on one table share one foundset all the way, unless you activate the form property “useSeparateFoundSet”
Assume form1, form2 and form3 are build on table companies
Doing a find in form1 with foundset=50 will also reflect in form2 and 3
now activate “useSeparateFoundSet” in form 2
Do a new find in form1 > foundset=10
form2 will have another foundset.
form 3 will have foundset=10 (still being shared with form1)
In my experience, you loose the “shared foundset” once you manually load records in whatever way (e.g. controllerLoadRecords(pks)). You can re-synch things using loadAllRecords(), but I think this is what David refered to…
patrick:
In my experience, you loose the “shared foundset” once you manually load records in whatever way (e.g. controllerLoadRecords(pks)). You can re-synch things using loadAllRecords(), but I think this is what David refered to…
We too are very interested in the issue of foundset splitting.
After having made some (lotta) brainstorming, and having changed our data structure, we think it’s about time to share our thoughts.
What’s annoying with foundset splitting is that:
a) some functions modifying the foundset are splitting it, where other don’t
b) as soon as a form foundset is splitted, we have no way to rejoin it to the shared foundset
Here are the features we would love as programmers:
a) having an ‘explicit’ parameter added to all functions modifying the foundset, letting us decide if this function will or will not split the current foundset. Letting us decide to modify the ‘shared’ foundset, or to create a new foundset instance for the current form.
b) having controller.getFoundsetPointer() and controller.setFoundsetPointer(), the first function returning a pointer to the foundset object, the second function letting us point the form to another foundset object.
I think a) + b) should resolve all our foundset splitting-rejoining issues.
For instance, it will let us have 2+ forms sharing a specific foundset which is not the main foundset, this during a specific user operation, while letting us rejoin these forms with the main shared foundset when operation ends…
DevTeam, the only drawback for these functions, as far as we can see, will be to handle when servoy could erase ‘splitted’ foundset from memory.
Servoy developpers, please share your thoughts about this proposition. Do you think it will help you? Any other ideas?
olivier melet:
b) as soon as a form foundset is splitted, we have no way to rejoin it to the shared foundset
loadAllRecords() on every form of the same table is what I’m having to do at the moment. Sometimes loadAllRecords() on one form of the table will sync them all back up but not always it seems. I still haven’t figured it out fully when/where/why of it but to be safe, I just slap it on all the forms when I need to resync and move on.
It seems to me that the default behavior no matter what is to share the found set no matter how it gets changed unless “useSeparateFoundSet” property is enabled on a form.
“useSeparateFoundSet” property should then be able to be changed via methods.
olivier melet:
b) as soon as a form foundset is splitted, we have no way to rejoin it to the shared foundset
It seems to me that the default behavior no matter what is to share the found set no matter how it gets changed unless “useSeparateFoundSet” property is enabled on a form.
“useSeparateFoundSet” property should then be able to be changed via methods.
David, your proposition is very elegant as it does not involve to introduce new paradigms to servoy programming.
However, I would insist on the ‘get and set’ functions which would let us have far more freedom while progamming and letting us doing such things as:
olivier melet:
For instance, it will let us have 2+ forms sharing a specific foundset which is not the main foundset, this during a specific user operation, while letting us rejoin these forms with the main shared foundset when operation ends…
The more freedom you get when programming, the more power you can build into the programme.
olivier melet:
However, I would insist on the ‘get and set’ functions which would let us have far more freedom while progamming
Being able to turn on and off the “useSeparateFoundSet” property from a method at runtime is the same thing…I think. At least that was what I was getting at. The end result is that we can split the found set at runtime anyway we want by flipping this property on and then at the end of our operation flip the property back off to continue sharing the “common” found set.
One problem I see is what is the common foundset at this point? That is why I suggest in the first post that we be able to link one form to another’s foundset via a property. So the form at the top of the link chain is always the “master” foundset when you resync the foundset.