Exactly. Lahav really gets it. — CB > On May 1, 2020, at 2:51 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: > > Kirk, > > I have one word that will do all of what we are after : "This" > > It works in listbox, which is a form object, any reason it can't be extended > to other form objects? > > Again, I don't think anyone on this thread is complaining, we are just trying > to understand how to use the new functionality to do what we need to. > > We need to interact with the users through some entry areas, call it objects, > fields, variables. Whatever. And sometimes do silly things like verification > of values, formatting to a certain standard etc. From everything that was > presented so far, there is no way to utilize the new methodology (call it > ORDA, dot notation whatever) as a data source of an entry area without using > some part of classic 4D. Coming up with all sorts of workarounds is fine, > but it is still a workaround. > > Cheers, will probably see you later today..... > > Lahav > > -----Original Message----- > From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Kirk Brooks via > 4D_Tech > Sent: Friday, May 1, 2020 1:21 PM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: Kirk Brooks <lists.k...@gmail.com> > Subject: Re: Object notation replacement for use of Self in a script — v18 > > Chris, > > On Tue, Apr 28, 2020 at 10:53 PM Chris Belanger via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > >> Generic programming of vars on a form is very complicated when one >> uses object attributes for the data source. >> >> For example, on screen you make a simple text input object named >> “enCompany”. It’s data source is Form.en_Company.Name ( i.e. >> [Company]Name ) >> In ‘classic 4d”, where the data source would be [Company]Name, one can >> code its script: >> > TRIM ( Self ) > > And TRIM would simply take a POINTER, and you can perform operations on the >> data that the user typed into that field. (Such as trim off leading & >> trailing spaces). >> > So what does Self actually point to? The object on the form the field is > displayed in or the actual field in the database? > > The two are not the same thing. In classic 4D that distinction is never > really apparent to us. It didn't need to be and we didn't want to have to > deal with it. It was part of the how we perceived working with 4D: a field on > a form _was_ the data. It's also why 4D forms from ages past are so > overloaded with data processing being done on the form itself instead of > separated into more independent modules. IP and process vars enabled that > trend even more. This is a main reason opening up one of these old databases > in v18 and attempting to change something is so fraught. But I digress. With > modern 4D tools you just don't do things that way anymore. > > Working with ORDA I rarely find a pointer a good solution to anything except > managing form objects like buttons. We are saddled with some unfortunate > nomenclature here because a 'form object' has nothing to do with an object in > Form. 'Form objects' are those named widgets on the form. > They _may_ be populated with data from something in Form, or a variable, or a > list box and so on. > > A big conceptual difference between classic 4D and modern 4D is the > distinction between a form object and the data it presents is explicit. So > when I set the data source for an input object to be > > Form.myEntity_o.Name > > where myEntity_o is a reference to an entity in Company the actual data and > the form object are no longer implicitly the same thing like they are in > classic 4D. I have a reference to the entity and I have a form object. They > are two different things. > > I can't get a pointer to the form object in this case. Why not? > First, what do I want to do with it? If I want to manage the form object > itself, visibility, enterability, etc., I don't need a pointer, I can just > use the object name. > If I want to do something with the data, as you do, the pointer won't work > because there are no pointers to object references. Why not? I'm sure there > are technical reasons but they don't matter to me because you don't need it. > You don't need it because you have a reference: myEntity_o. If you want to > change the data you do that with the reference - not through whatever that > data happens to be displayed in. > > This is a fundamental, conceptual difference between using ORDA and classic > 4D. > > In classic 4D we have tables, records, fields and pointers to reference them. > In ORDA we have datastores, dataclasses, entities, properties and we use > references. > > > In the example of the name field you can still put code in the form object to > react to On Data Change. And you can still pass data to a generic method to > manage it. Two ideas come to mind: > 1) method takes an entity > > // myMethod1 (entity) > > // $1 is a Company entity - check the name, address, etc. for proper > formatting > > 2) method is a function > > Form.myEntity_o.Name:=myMethod2(Form.myEntity_o.Name) > > > Is the form you are working with an existing form or one you created from > scratch? > I find it much easier to use the new approaches on new forms. If not by > totally rewriting them then by separating out the new work into a subform. > That lets me design the form using a modern approach without having to do too > much to the old one. > > I said this someplace else recently and it applies here: just because 4D > (still) provides some tools for doing things doesn't mean it's a good tool to > use. For instance, would anyone make a new form and use DRAG AND DROP > PROPERTIES? ORDA isn't an evolutionary step in 4D - it's a revolutionary > step. It really is like learning a new language. 18r3 is that way for sure. > > I had time to begin updating my old 4D coding ideas starting a couple of > years ago. It wasn't easy and it made me feel old. But I kept at it. And it > became a lot easier and them fun. Now I'm amazed at things I can do simply by > setting up the data structure. Another big difference for me in this. > Taking time to get the structure right is time well spent. > > -- > Kirk Brooks > San Francisco, CA > ====================== > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > **********************************************************************
********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
