"If we could at least get the DATA SOURCE of the object that is using object notation as its data source, it would be nice:” Feature request time!
Back in 2018 (way back then!), I asked to be able to get the table number for a entity selection and got the equivalent of “Why would you want to do that?!". Lo and behold, it showed up a few R releases later. Another WTF is that you can’t iterate from the end of a collection to the start. You can reorder the collection and then run a For each loop but that’s a complete kludge. Dollars to doughnuts, 4D will eventually add a parameter to the For each so that we don’t have to use that workaround. As Tim Nevels is wont to say (paraphrasing) “This just the beginning - have patience!" -- Douglas von Roeder 949-910-4084 On Thu, Apr 30, 2020 at 6:22 PM Chris Belanger via 4D_Tech < [email protected]> wrote: > I thoroughly enjoy using object notation and the Form. object. That is why > I want a way to continue to use it to designate the data source of form > objects. > I have read and re-read Keisuke’s comment, and there are aspects I do not > comprehend. I thought that the attachment between form object and data > source object is an integral relationship and I can’t see how using the > form object to obtain its underlying data source [an attribute of an > object] is so bad. > And I am trying to understand the counsel: > > > > "I would focus my use of object notation to areas where classic > > code could not go, not spaces already occupied by classic code." > > > Not to mean any disrespect to Keisuke. He is one of the brightest 4D > programmers around. > But somehow this goes over my head. It is too philosophical to comprehend; > almost metaphysical. When I examine code that Keisuke creates, it is > elegant. I am confused as to how he would actually accomplish what we have > been discussing in an object script — would he use ‘classic 4D’ on some > screen elements, and not on others? > I do not want to resort to a mixture of ‘classic’ and object notation. > In the ‘perfect implementation’, within an object’s script: > > This.value := Pretty_Format(This.value) // or something like this > > “This” would give you access to the data source (being as it is basically > an attribute of an object, like Form.en_This.Company.Name). > > I understand that it creates some potential for confusion in the case of > something like: > Form.en_This.Company.Name > > In that this is actually an entity attribute. Perhaps the coder would > somehow start trying to extrapolate other attributes from its entity (i.e. > “owner"). > While one can traverse down the path (eg. Form[en_This][Company][Name] ) > one cannot traverse up the path as in: > > Let $attribute = Form.en_This.Company.Name // i.e. that is what > $attribute is; pseudo-code > $attribute.owner is Form.en_This.Company // hypothetical > code > ( applied to Form.en_This.Company.Name giving Form.en_This.Company > [in this case, an entity] ) > > ____ > If we could at least get the DATA SOURCE of the object that is using > object notation as its data source, it would be nice: > But: > OBJECT Get data source ( *; $objName ) returns Nil for form objects (dot > notation) because it returns a pointer. > > > So it seems the only way to get the ’simple script’ is to do something > like hard-coding: > $temp:=Pretty_Format(Form.en_This.Company.Name) // so we don’t > ’touch’ an attribute unnecessarily, triggering a save condition > If (Form.en_This.Company.Name # $temp) // if the formatting > would change the value > Form.en_This.Company.Name:= $temp > End if > And propagate it all over the place. > > — Chris > > > > On Apr 30, 2020, at 6:23 PM, lists via 4D_Tech <[email protected]> > wrote: > > > > Doug, > > > > Just for discussion sake, I'd say that a good portion of long > established systems have 100% of their space already occupied by classic > code.... > > > > The use of the Form object offers so much that I am resigned to let go > of some generic code, not happy, but willing to pay that price. > > > > Lahav > > > > -----Original Message----- > > From: 4D_Tech <[email protected]> On Behalf Of Douglas von > Roeder via 4D_Tech > > Sent: Thursday, April 30, 2020 5:51 PM > > To: 4D iNug Technical <[email protected]> > > Cc: Douglas von Roeder <[email protected]> > > Subject: Re: Object notation replacement for use of Self in a script — > v18 > > > > Randy: > > > > "If there is such an issue trying to get object values to work right, > what’s the reason to use them at all?” > > The new language is extremely powerful and I found it quite easy to pick > up (mostly). The fact that it doesn’t give us 100% backward compatibility > is not unexpected. > > > > "I know everyone is all excited about object notation, but it’s not > mandatory. Why should we even consider using it if doesn’t do what we > need? I’m sure there are some areas where it’s useful, but it sounds like > there’s a lot where it isn’t. Am I missing something” > > “[doing everything that] we need” is a pretty high bar, wouldn’t you > agree? For me, I’ve been using ObjectTools + constructors since the late > 90’s, biding my time for 4D to adopt objects/object notation/OOP. At this > point, I’ll take what I can get. > > > > While I was quite not-happy with this particular limitation (I have > forms with hundreds of fields that use Object name that are used with > Object get pointer), I think the last paragraph of Miyako’s posting, above, > is sound advice - "I would focus my use of object notation to areas where > classic code could not go, not spaces already occupied by classic code." > > > > -- > > Douglas von Roeder > > 949-910-4084 > > > > > > On Thu, Apr 30, 2020 at 3:03 PM Randy Kaempen via 4D_Tech < > [email protected]> wrote: > > > >> > >>> On Apr 30, 2020, at 4:43 PM, lists via 4D_Tech > >>> <[email protected]> > >> wrote: > >>> > >>> OK, based on this design, we are back to using variables (or dynamic > >> variables) for data entry of anything that needs any kind of > >> processing done to it after an entry, having to load the values to > >> these data entry objects when loading the form, and copying the values > >> back when we want to save any user changes. > >>> > >>> OR > >>> > >>> We can use the Form.XXX notation to gain the advantage of that new > >>> nifty > >> option, but lose the generic coding ability. > >>> > >>> I'd say it's a choice, but the lack of the ability to address an > >>> object > >> from within generically definitely seems to be a glaring omission... > >> > >> If there is such an issue trying to get object values to work right, > >> what’s the reason to use them at all? > >> > >> I know everyone is all excited about object notation, but it’s not > >> mandatory. Why should we even consider using it if doesn’t do what we > >> need? I’m sure there are some areas where it’s useful, but it sounds > >> like there’s a lot where it isn’t. Am I missing something? > >> > >> > >> Randy Kaempen > >> Intellex Corporation > >> > >> ********************************************************************** > >> 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] > >> ********************************************************************** > > ********************************************************************** > > 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] > > ********************************************************************** > > ********************************************************************** > > 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] > > ********************************************************************** > > ********************************************************************** > 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] > ********************************************************************** ********************************************************************** 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] **********************************************************************
