maybe a bit late -
the biggest problem with named selections
they are static.
unlike a set, you can simply add or remove records from a named
selection.
Of course adding or removing records from a named selection would also
require resorting.
So the cost of using a named selection increases - possible a lot - if
you are trying to use them in a context where you need to add/delete
from the selection.
Also - depending on the sorting complexity, the sort could be
'expensive'
a simple sort on a field of the table in the named selection is not too
expensive,
however, a cross relational sort, or worse a sort by formula could get
very expensive.
And having to apply the sort criteria repeatedly could introduce delays
the user would find annoying to unacceptable.
Sets:
create set([table];"Myset")
Add to set([table];"Myset")
Create Set([table];"To_be_Unioned")
Union("Myset;"To_be_Unioned";"Myset")
Intersection("Myset;"To_be_Unioned";"Myset")
Difference("Myset;"To_be_Unioned";"Myset")
Use Set("Myset")
clear Set("Myset")
Order By([table];[table]Field;>)
** Note this only needs to be done once - just before display
Named selections
Copy Named Selection([table];"MySelection") (alternatively Cut Named
Selection)
Adding to it?
create record([table])
save record([table]
create set([table];"ToAdd")
use named selection("MySelection")
create set([table];"Add_to")
Union("Add_to";"ToAdd";"Add_to")
Order By([table];[table]Field;>)
Copy Named Selection([table];"MySelection") (alternatively Cut Named
Selection)
** Note this would need to be done every time a record was added
Deleting from?
see above, replace Create/save with a Query
I think you can see my point -
Yes Named selections have many uses, but I do not see them as a
replacement for sets when working with displayed lists of records where
users can/are adding removing records from the display/table
On Tue, 13 Sep 2016 08:57:39 -0600, Cannon Smith wrote:
> I got to wondering how expensive it really is to used named
> selections everywhere and then move them to the current selection to
> do some work on them and then back again. It turns out that it is
> really fast if you use CUT NAMED SELECTION and USE NAMED SELECTION to
> move it back and forth and it doesn’t seem to matter how many records
> are in the named selection. I suspect that when using these two
> commands, internally 4D just updates a pointer or something like that.
>
> To test I created selections of varying sizes and then moved them
> into a named selection and then back into the current selection
> thousands of times. Each cycle averaged 3-8 microseconds (not
> milliseconds)!
>
> Maybe there are other gotchas I’m not thinking of, but based on these
> tests it seems like it would be possible to have all an application’s
> windows in the main process as long as they all used named selections
> and just moved them temporarily into the current selection to work on
> it before moving it back into the named selection.
>
> --
> Cannon Smith
> Synergy Farm Solutions Inc.
> Hill Spring, AB Canada
> 403-626-3236
> <[email protected]>
> <www.synergyfarmsolutions.com>
>
>
>> On Sep 5, 2016, at 3:53 PM, Cannon Smith
>> <[email protected]> wrote:
>>
>> - In my current code, I tend to let almost every window have its own
>> process. One reason for this is that the window has full control
>> over selections and current records in every table. Even when the
>> widows are array and variable based, this is very helpful. It seems
>> like things could get very complicated if you had several windows
>> open in the same process. For example, what if two of the windows
>> were list windows for the same table and a third table was editing a
>> record in that table? I suppose I could use named selections, but
>> they seem limited. For example, I don't know how to programmatically
>> ask a named selection to sort itself a certain way without making it
>> the current selection and then pushing the current selection back
>> into the named selection. Is this an expensive operation? I don't
>> know as I've not tested it. Intuitively it seems like it would be.
>> It is certainly expensive code wise in the sense that I'd have to
>> remember to never accidentally use the current selection except to
>> do temporary work for a named selection.
>
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> FAQ: http://lists.4d.com/faqnug.html
> Archive: http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub: mailto:[email protected]
> **********************************************************************
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
