Chris, On Tue, Apr 28, 2020 at 10:53 PM Chris Belanger via 4D_Tech < [email protected]> 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:[email protected] **********************************************************************
