Hi Kirk,
Thanks for replying.
I think I stated this much earlier in this thread, but the project I am working
on is ENTIRELY orda / object based. I do not mix ‘classic’ into it; except I
would say some 4D commands basically still are ‘classic-oriented’ but they are
working on ‘ORDA-izing’ it. I even wrote my own ‘class definition’ and ‘UI
Object’ subsystem, where I have a UI to define the classes & instantiate
objects.
In my whole project, there is not a single pointer, interprocess or process
variable, or any such ‘vestiges’ of classic 4D. It uses Form, Storage, object
notation, entity selections — the whole works.
Well, there are a couple pointers (local variables) because 4D still forces one
to use them sometimes, like OBJECT Get Pointer( ). But in my own code base I do
not use them. I use strictly object notation.
I also made up for some existing 4D shortcomings, by making some ‘wrapper’
routines. For example, I can get all the attributes of some form object in an
Object.
OBJ_GetObjCharacteristics( Object Name; {what I want} ) —> OBJECT containing
all the attributes of that form object, such as .height, .width, .foreground,
et al.
So I can call:
$obj_LB:=OBJ_GetObjCharacteristics( “LB_Browser” ) and then be able to use:
$obj_LB.left $obj_LB.foreground whatever.
I am not trying to imply I want a ’Self’ function for ORDA. Keisuke explained
there is some differentiation between form object & the data it ‘controls’. The
difference was never clear in classic 4D, which I think was pretty cool.
I merely am saying that when I wanted to work with the value in the SCRIPT of a
form field in the ‘old days’ I could simply use:
Do_Something ( Self ).
And I could get at the value by Self-> and set the value by Self->:= ….
And I could write a generic routine (such as ‘Pretty_Format’) to handle the
basic stuff of stripping off extraneous spaces, enforcing captalization, etc.
And it could even do something much more significant.
I would think that in the ‘ORDA / OBJECT’ paradigm, there should be a way to
get at the ‘variable’ represented by the form object by using
This
Just like one can in many contexts in 4D right now.
In the contexts where ’This’ applies in 4D, it is astonishingly powerful and
tremendously intuitive to use.
Anyway, back to my initial inquiry:
Imagine being able to put into a 4D Object script:
This:=Pretty_Format(This)
Or perhaps:
PRETTY_FORMAT(This).
There are many places (text entry) where you don’t really care what the person
put into it, but you need to protect the user from common formatting issues.
I understand Keisuke’s response that it seems eventually there will be a “This”
in the context of a form object’s script. I hope so.
In the meantime, it seems to demand a lot of ’spaghetti code’ which I always
detest using, just to work around the absence of ’This’ in the context of a
form object’s script.
IN THE ABSENCE of the use of ’Self’, I was hoping there was some other simple
provision for getting at the data for the form object.
But even OBJECT Get Data Source( ) returns a pointer, which of course is Nil
for any Form. - based variable [i.e. Form. — datasource]
I hope you understand my inquiry more clearly now,
Chris
And please do not say that this request is illogical … it is almost as
fundamental as H2O.
> On May 1, 2020, at 1:20 PM, Kirk Brooks via 4D_Tech <[email protected]>
> wrote:
>
> Chris,
>
> On Tue, Apr 28, 2020 at 10:53 PM Chris Belanger via 4D_Tech <
> [email protected] <mailto:[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
> <http://lists.4d.com/archives.html>
> Options: https://lists.4d.com/mailman/options/4d_tech
> <https://lists.4d.com/mailman/options/4d_tech>
> Unsub: mailto:[email protected]
> <mailto:[email protected]>
> **********************************************************************
**********************************************************************
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]
**********************************************************************
