Hey Jeremy,
A couple of thoughts:
On Sun, Jul 28, 2019 at 9:20 AM Jeremy Roussak via 4D_Tech <
[email protected]> wrote:
> I have a collection objects, each of which has a pointer to a variable and
> an associated object:
>
You don't need to use a pointer in the collection. It sounds like what you
want is for that value, in the collection, to be dynamic and to be able to
query on it and find different results as other things have changed. So
what you need to do is design things so that whatever is now a pointer is
itself a reference.
"list" could be any number of things but I bet it could be represented as a
collection. At which point it becomes much easier for you to work with
directly rather than having to dereference what ever that is.
> I want to find the item in the collection from the pointer, which is in
> $ptr
> $boxes:=<>boxes.query(“lb = :1”;$ptr)
>
This might work if $ptr is pointing to a var and you dereference $ptr. But
it's not clear if $ptr is an actual pointer or not.
> Is searching for pointers not allowed?
>
Using ORDA I don't think so.
Using these new data structures, collections, objects, entities and such,
works most effectively when you work with them using references. Within
that context a reference is similar to a pointer but more powerful and
easier to use. Pointers are for working with variables, fields and tables.
It's a different structure from ORDA. You have to rethink how you go about
doing some things. Especially when working with forms and familiar objects
like listboxes. But it's what we have to do. I can tell you from personal
experience over the past year or so the payoff is pretty good. These new
abilities are great.
If you find yourself trying to figure out how to use pointers when you're
doing something with an object, collection or entity you are on the wrong
path. Take a step back and figure out how to accomplish your goals using
references.
You know since Form I rarely use pointers for anything except buttons. Why?
Because it's easier to simply put those objects in the Form object and
reference them.
Input fields: you need to recognize the On data change event but from there
I just work with whatever the value in Form.thisField is.
Listboxes: the only place I've made a listbox with an array is in v15
projects I'm still working on. Otherwise they are either collections or
entity selections. Once more there is nothing I need a pointer to - the
components of them are referenced in Form and easy to work with from there.
Speaking of them, your example suggests to me you are working out a way to
have several different 'boxes' in an array, perhaps with the intent of
making it easy for the user to switch between them? Great idea. I might do
something like:
$lb_obj:=New object("name";"my name";"data"; <collection of columns>)
as the object. And instead of an IP var consider using a process variable.
To accommodate multiple windows you use DIALOG(*). You can have many
independent windows in a single method. I'm starting to have a single UI
process where all the windows the user interacts with exist. Coupled with
CALL FORM it's very easy to support this.
Finally, keep in mind that when we create a reference to something we
aren't duplicating it. This is where the similarity to pointers is similar.
$obj:=new object(with a bunch of data)
And then I include this in a collection:
processColl.push($obj)
There is still only 1 instance of $obj. If I then do
$otherColl.push(processColl[0])
$myColl.push(processColl[0])
it's the same thing. There's only one instance of $obj and now 3 references
to it, one in a process variable and 2 in locals (these could be on forms).
So thinking about a form for a moment let's say I put $myColl into
Form.myColl. Now I can reference the values of $obj on my form with
Form.myColl[0].someProperty
which in this example is equivalent to
processColl[0].someProperty
And if the user makes some change on the form those changes are reflected
in all the instances. This is a pretty simple example and you could pretty
easily accomplish the same functionality using pointers. You would need a
lot more code to do it but really I just wanted to try to highlight the
differences in the way you think about the data.
--
Kirk Brooks
San Francisco, CA
=======================
What can be said, can be said clearly,
and what you can’t say, you should shut up about
*Wittgenstein and the Computer *
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
