Re: ListBoxes and AreaList Pro again (was: Object notation replacement for use of Self in a script — v18)
I agree with your logic, John. A well-spoken and thoughtful reply. I also used ALP for many years; back in the ‘dinosaur’ days before list boxes were not even thought of. Seemed for many years 4D was content to leave that aspect of the UI to ALP, which it filled most admirably. I built a significant amount of my code library on ALP. It served a vital role in my 4D apps for many years. However, after 4Dv14 arrived, I re-engineered my DBs to eliminate ALP. ALP licensing had been changed so it was ‘attached’ to a 4D license a few years before, and it became expensive to me. It took a few days because it was quite integrated into my ‘libraries’ but I managed to replace it all satisfactorily, including my customization code that allowed reconfiguration of an ALP during runtime (and saving the config, etc.). Now I have a whole new ORDA/entity selection codebase (greatly simplified, I might add) founded upon the use listBoxes. I can adjust the columns & all the appearance options of the listBox area using my own GUI, at run-time. Even the method they run. Considering that Entity selections have been available for so many months now, I am surprised to learn that they are not supported in ALP yet. But I imagine it is a huge undertaking to support it, especially as a plug-in. I suppose another consideration in the debate may be if a developer is going to use "4D for iOS". I haven’t ever checked that out myself — I plan to but need to get some projects finished up first. I don’t know if it supports listBoxes. But either way I would imagine that ALP would not be available for such projects (as they become Xcode). I hope all the best for the publishers of ALP, but I can’t see any reason for me to jump back on the wagon. — Chris > On May 4, 2020, at 4:48 PM, JOHN BAUGHMAN via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > > First off, this is in no way an attempt to bash AreaList Pro. It is one > of the best and most solid plugins available. Price is write and support > continues to be great. If any plugin fits your needs by all means stick with > it. Some of yoI have may remember that in the old days I always argued for > the use of plugins. I still feel the same and will gladly argue for their use > again. Replacement in favor of a built in 4D feature is a different story. > > After many many solid years with AreaList Pro, however, I made the > switch to 4D listboxes a couple of years ago. I made the switch because I > got tired of dealing with plugins in general when upgrading 4D over time. In > most 4D upgrades over the years making sure the plugins worked and were > properly licensed has always been the biggest hurdle (the move to 64bit and > 4D Write Pro are the most glaring examples of exceptions to the rule). > > Another reason I am prone to switch is that I find that debugging code > that involves a plugin can be a real headache. Also it is far easier to force > a crash when using a plugin vs a built in 4D feature. > > To me plugins exist to fill gaps in 4D. When those gaps are filled in > by 4D, it is time for me to consider abandoning the plugin that bridged the > gap. AreaList Pro, PrintList Pro. ObjectTools, and DisplayLiat have all been > victims of my evolved philosophy with regard to plugins. Having far fewer > plugins today makes my programming life far less complicated than before. > I’ve found that the effort to replace has definitley paid off for me in the > end. > > Referring to Philipp’s comments... > >> It would be too bad (and very time consuming) to get rid of all your hard >> work instead of just following AreaList Pro's evolution. > > Actually I found the switch less painful than expected for all of these > plugins. I always wrap plugin commands as much as I can as soon as I get them > so that replacing code is an orderly and centralized process. Also I never > touch the existing implantation of the plugin. I duplicate the methods and in > the case of AreaList make the AreaList areas invisible and place the listbox > on top of the ALPRo area. For other form objects that contain plugin code I > like to put the object's code inside a case statement with both the plugin's > code and the new 4D code in the same object. I don’t remove the plugin until > I am sure that the replacement works as expected. A day or 2 of work at most. > >> The main ListBox features are basically AreaList Pro v6-7, IOW they (almost) >> do what AreaList Pro did 20 years ago. > > True, but that is no reason to keep using the plugin if 4D can do every > thing you want now, be it 20 years later. If I later find a feature that I > absolutely have to have and the only way is to use ALPro, put it back in the > mix. So far I have not run into a subsequent need for a feature in a replaced > plugin. > >> 4 versions (and many years) later there is still no comparison between the >> basic ListBoxes and the numerous features
Re: Object notation replacement for use of Self in a script
I can't think of a single instance where iterating in reverse is even necessary. If you're deleting elements of a collection, simply build a new collection of the ones you want to delete. If you do it right, that's easier to read, anyway. Doug On Sat, May 2, 2020 at 12:10 AM Aparajita Fishman via 4D_Tech < 4d_tech@lists.4d.com> wrote: > > "Don’t be so quick to complain; you finally got ‘for each’ 10 years after > > the rest of the world (including Active4D).” > > Good point. So…you’re thinking that the feature set is complete? > > Absolutely. In fact it is more complete than most implementations, you can > specify and begin and end index for ordered collections. > > > > "I don’t know of a single language (and I have used at least 6) where > ‘for > > each’ is reversible.” > > This could be 4D’s chance to be a trendsetter! > > I don’t think it's worth it. Iterating in reverse is not a common > operation. > > > > it’s funny that we have such a handy looping construct yet I have write > > code to init and update my own index. > > If you need an index in a ‘for each’ loop, you should actually be using an > indexed ‘for’ loop. That’s the point of having ‘for each’ separate from > ‘for’: 90% of the time you don’t need the index and ‘for each’ is more > concise, but when you need an index a for loop increments it for you. > > - Aparajita > > ** > 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) New Forum: https://discuss.4D.com Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
RE: Object notation replacement for use of Self in a script — v18
Bernard, This works perfectly fine until you use an object member as your data source. Once you do that, the Object get pointer command will return a nil pointer. In your example, put Form.Note as your data source (Variable or Expression), run it and see what you get Regards, Lahav -Original Message- From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Bernard Escaich via 4D_Tech Sent: Wednesday, May 6, 2020 2:16 AM To: 4D iNug Technical <4d_tech@lists.4d.com> Cc: Bernard Escaich Subject: Re: Object notation replacement for use of Self in a script — v18 Why not use Form event.objectName ? I find it very useful ; I use it and write in form method : Case of :(Form event.code=On data change) Case of :(Form event.objectName="Name) Object get pointer(Object named;"Name")->:=MyMethodUppercase( Object get pointer(Object named;"Name")->) :(Form event.objectName="Address) Object get pointer(Object named;"Address")->:=MyMethodUppercase( Object get pointer(Object named;"Address")->) :(Form event.objectName="Form.Note) Object get pointer(Object named;"Form.Note")->:=MyMethodUppercase( Object get pointer(Object named;"Form.Note")->) End case End case Two solutions for MyMethod : - if used elsewhere, use a method (waiting for classes) - if used locally, made a call to form method : Execute method(Current method name;…. Cordialement, Bernard Escaich > Le 29 avr. 2020 à 19:15, lists via 4D_Tech <4d_tech@lists.4d.com> a écrit : > > OK, so can we get a real example of how to replace the *old* way with the > new? In a case where there are several entry objects: > > Form.Name > Form.Address > Form.Note > > I want to enforce a proper uppercase/lowercase on all three, so in the old > days I created an object, set the method to "UpperLower(self)", duplicated it > three times, change the object name and I'm done. For simplicity sake, lets > say that UpperLower simply do $1->:=Uppercase($1->). > > How would you do the same while using object notation instead of a variable, > dynamic or not? ** 4D Internet Users Group (4D iNUG) New Forum: https://discuss.4D.com 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) New Forum: https://discuss.4D.com Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Object notation replacement for use of Self in a script — v18
Why not use Form event.objectName ? I find it very useful ; I use it and write in form method : Case of :(Form event.code=On data change) Case of :(Form event.objectName="Name) Object get pointer(Object named;"Name")->:=MyMethodUppercase( Object get pointer(Object named;"Name")->) :(Form event.objectName="Address) Object get pointer(Object named;"Address")->:=MyMethodUppercase( Object get pointer(Object named;"Address")->) :(Form event.objectName="Form.Note) Object get pointer(Object named;"Form.Note")->:=MyMethodUppercase( Object get pointer(Object named;"Form.Note")->) End case End case Two solutions for MyMethod : - if used elsewhere, use a method (waiting for classes) - if used locally, made a call to form method : Execute method(Current method name;…. Cordialement, Bernard Escaich > Le 29 avr. 2020 à 19:15, lists via 4D_Tech <4d_tech@lists.4d.com> a écrit : > > OK, so can we get a real example of how to replace the *old* way with the > new? In a case where there are several entry objects: > > Form.Name > Form.Address > Form.Note > > I want to enforce a proper uppercase/lowercase on all three, so in the old > days I created an object, set the method to "UpperLower(self)", duplicated it > three times, change the object name and I'm done. For simplicity sake, lets > say that UpperLower simply do $1->:=Uppercase($1->). > > How would you do the same while using object notation instead of a variable, > dynamic or not? ** 4D Internet Users Group (4D iNUG) New Forum: https://discuss.4D.com Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Object notation replacement for use of Self in a script
You are correct and I have used it, I just forgot even though I was looking at the documentation while writing that email. Jim Crate > On May 5, 2020, at 3:02 PM, Jeremy Roussak via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Doesn’t the option until/while syntax fit the bill for early exit? I agree an > automatically-maintained index would be nice, though. > > Jeremy > >> On 5 May 2020, at 19:13, James Crate via 4D_Tech <4d_tech@lists.4d.com> >> wrote: >> >> In 4D, when enumerating collections or entity selections, about half the >> time I want an index for progress calculation, and other times I have to use >> the indexed for loop because I want to early exit. >> >> For other languages, providing the index on enumeration varies by language >> and enumeration construct, but most have an enumeration construct that >> provides an index. Almost all support break. >> >> So 4D’s implementation could be considered more redundant, less >> feature-complete. If an index were provided instead of start/end, and you >> could set that index to .length to exit the loop, we’d pretty much never >> have to use an indexed loop for a collection or entity selection. >> >> Jim Crate > > ** > 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) New Forum: https://discuss.4D.com Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Object notation replacement for use of Self in a script
Doesn’t the option until/while syntax fit the bill for early exit? I agree an automatically-maintained index would be nice, though. Jeremy > On 5 May 2020, at 19:13, James Crate via 4D_Tech <4d_tech@lists.4d.com> wrote: > > In 4D, when enumerating collections or entity selections, about half the time > I want an index for progress calculation, and other times I have to use the > indexed for loop because I want to early exit. > > For other languages, providing the index on enumeration varies by language > and enumeration construct, but most have an enumeration construct that > provides an index. Almost all support break. > > So 4D’s implementation could be considered more redundant, less > feature-complete. If an index were provided instead of start/end, and you > could set that index to .length to exit the loop, we’d pretty much never have > to use an indexed loop for a collection or entity selection. > > Jim Crate ** 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 **
Re: Object notation replacement for use of Self in a script
On May 2, 2020, at 1:10 AM, Aparajita Fishman via 4D_Tech <4d_tech@lists.4d.com> wrote: > >> "Don’t be so quick to complain; you finally got ‘for each’ 10 years after >> the rest of the world (including Active4D).” >> Good point. So…you’re thinking that the feature set is complete? > > Absolutely. In fact it is more complete than most implementations, you can > specify and begin and end index for ordered collections. Since both collection and entity selections support .slice(), I’ve wondered why the begin/end index parameters exist on For each. >> it’s funny that we have such a handy looping construct yet I have write code >> to init and update my own index. > > If you need an index in a ‘for each’ loop, you should actually be using an > indexed ‘for’ loop. That’s the point of having ‘for each’ separate from > ‘for’: 90% of the time you don’t need the index and ‘for each’ is more > concise, but when you need an index a for loop increments it for you. In 4D, when enumerating collections or entity selections, about half the time I want an index for progress calculation, and other times I have to use the indexed for loop because I want to early exit. For other languages, providing the index on enumeration varies by language and enumeration construct, but most have an enumeration construct that provides an index. Almost all support break. So 4D’s implementation could be considered more redundant, less feature-complete. If an index were provided instead of start/end, and you could set that index to .length to exit the loop, we’d pretty much never have to use an indexed loop for a collection or entity selection. Jim Crate ** 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 **
Re: Object notation replacement for use of Self in a script — v18
Jim: "This is pretty much the same way you enumerate in reverse order in the other languages I use.” Thank you for posting that. I brought this up on the Forum a while back and I even brought it up in a tech support call but…nada. Interesting thread - https://forums.4d.com/Post/EN/34415270/1/34415271#34415271 A sage suggesting .reverse, as you have, and another steering the poster toward a For loop. Reminds me of: “Less filling! "Tastes great!” I’ll go with .reverse -- Douglas von Roeder 949-910-4084 On Fri, May 1, 2020 at 5:41 PM James Crate via 4D_Tech <4d_tech@lists.4d.com> wrote: > On Apr 30, 2020, at 9:36 PM, Douglas von Roeder via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > > > > 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. > > For each ($item;$collection.reverse()) > // do some stuff > End for each > > This is pretty much the same way you enumerate in reverse order in the > other languages I use. > > Jim Crate > > ** > 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 **
Re: Object notation replacement for use of Self in a script
Aparajita: "Absolutely. In fact it is more complete than most implementations, you can specify and begin and end index for ordered collections.” Sorry for the confusion. I was referring to 4D implementation, not A4D. -- Douglas von Roeder 949-910-4084 On Fri, May 1, 2020 at 10:10 PM Aparajita Fishman via 4D_Tech < 4d_tech@lists.4d.com> wrote: > > "Don’t be so quick to complain; you finally got ‘for each’ 10 years after > > the rest of the world (including Active4D).” > > Good point. So…you’re thinking that the feature set is complete? > > Absolutely. In fact it is more complete than most implementations, you can > specify and begin and end index for ordered collections. > > > > "I don’t know of a single language (and I have used at least 6) where > ‘for > > each’ is reversible.” > > This could be 4D’s chance to be a trendsetter! > > I don’t think it's worth it. Iterating in reverse is not a common > operation. > > > > it’s funny that we have such a handy looping construct yet I have write > > code to init and update my own index. > > If you need an index in a ‘for each’ loop, you should actually be using an > indexed ‘for’ loop. That’s the point of having ‘for each’ separate from > ‘for’: 90% of the time you don’t need the index and ‘for each’ is more > concise, but when you need an index a for loop increments it for you. > > - Aparajita > > ** > 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 **
Re: ListBoxes and AreaList Pro again (was: Object notation replacement for use of Self in a script — v18)
This is always a no brainer for me. Arealist every time. It’s just far more professional looking and performing IMO. I use listboxes a lot for testing - I really use them quite intensively for that, but then I go and do the production version with Arealist since I still find list boxes clunky and more like a big global variable with window panes than a high performance business tool that Arealist always has been. Another reason I stick with Arealist is scaleability. Listboxes have struggled with this for decades which tells you something. Only now are they starting to get there but it’s been painful. Meanwhile Arealist could display a million records in a millisecond 20 years ago. It just has the right performance model for a grid inside and out and since the object-property approach arrived is infinitely more flexible. Finally I’ve seen some cool looking listbox based applications so both are clearly viable for professional deployments, but listboxes for ma are always playing catchup. Regards Peter > On 5 May 2020, at 00:48, JOHN BAUGHMAN via 4D_Tech <4d_tech@lists.4d.com> > wrote: > Referring to Philipp’s comments... > >> It would be too bad (and very time consuming) to get rid of all your hard >> work instead of just following AreaList Pro's evolution. > > Actually I found the switch less painful than expected for all of these > plugins. I always wrap plugin commands as much as I can as soon as I get them > so that replacing code is an orderly and centralized process. Also I never > touch the existing implantation of the plugin. I duplicate the methods and in > the case of AreaList make the AreaList areas invisible and place the listbox > on top of the ALPRo area. For other form objects that contain plugin code I > like to put the object's code inside a case statement with both the plugin's > code and the new 4D code in the same object. I don’t remove the plugin until > I am sure that the replacement works as expected. A day or 2 of work at most. ** 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 **
Re: ListBoxes and AreaList Pro again (was: Object notation replacement for use of Self in a script — v18)
First off, this is in no way an attempt to bash AreaList Pro. It is one of the best and most solid plugins available. Price is write and support continues to be great. If any plugin fits your needs by all means stick with it. Some of yoI have may remember that in the old days I always argued for the use of plugins. I still feel the same and will gladly argue for their use again. Replacement in favor of a built in 4D feature is a different story. After many many solid years with AreaList Pro, however, I made the switch to 4D listboxes a couple of years ago. I made the switch because I got tired of dealing with plugins in general when upgrading 4D over time. In most 4D upgrades over the years making sure the plugins worked and were properly licensed has always been the biggest hurdle (the move to 64bit and 4D Write Pro are the most glaring examples of exceptions to the rule). Another reason I am prone to switch is that I find that debugging code that involves a plugin can be a real headache. Also it is far easier to force a crash when using a plugin vs a built in 4D feature. To me plugins exist to fill gaps in 4D. When those gaps are filled in by 4D, it is time for me to consider abandoning the plugin that bridged the gap. AreaList Pro, PrintList Pro. ObjectTools, and DisplayLiat have all been victims of my evolved philosophy with regard to plugins. Having far fewer plugins today makes my programming life far less complicated than before. I’ve found that the effort to replace has definitley paid off for me in the end. Referring to Philipp’s comments... > It would be too bad (and very time consuming) to get rid of all your hard > work instead of just following AreaList Pro's evolution. Actually I found the switch less painful than expected for all of these plugins. I always wrap plugin commands as much as I can as soon as I get them so that replacing code is an orderly and centralized process. Also I never touch the existing implantation of the plugin. I duplicate the methods and in the case of AreaList make the AreaList areas invisible and place the listbox on top of the ALPRo area. For other form objects that contain plugin code I like to put the object's code inside a case statement with both the plugin's code and the new 4D code in the same object. I don’t remove the plugin until I am sure that the replacement works as expected. A day or 2 of work at most. > The main ListBox features are basically AreaList Pro v6-7, IOW they (almost) > do what AreaList Pro did 20 years ago. True, but that is no reason to keep using the plugin if 4D can do every thing you want now, be it 20 years later. If I later find a feature that I absolutely have to have and the only way is to use ALPro, put it back in the mix. So far I have not run into a subsequent need for a feature in a replaced plugin. > 4 versions (and many years) later there is still no comparison between the > basic ListBoxes and the numerous features added by AreaList Pro v9 and v10. > To name a few: breaks, sub-totals/calculations, transposition, displaying > mySQL data, complete granularity up to cell level, event callbacks, area > templates (global default settings), multiple header rows, zoom, etc. True again, but if you need any of those things the gap has not yet been filled… don’t replace. I you do not need any of those featrures nor expect to in the future… it may be time to replace. > And the property-based syntax since version 9 makes it very easy to program. For me I find it easier to program a listbox than an AreaListPro area, but I do agree that it is easy to program AreaList. > > Now the recent features of ListBoxes regarding object support are not yet > available in AreaList Pro, just because we have the same level of information > as everyone else here, so it take time to catch up. OTOH it provides the > distance to think twice about how it should be done, and collect requests > from informed developers. Not an issue if you still have a need to continue to use AreaList. The beauty of AreaList is that when it does catch up it often does what ever was lacking better than 4D. > > BTW these features often (and increasingly will) require a 4D View pro > license, much more expensive than AreaList Pro. Good point. I only have one client where there was a need for View. The difference in maintenance to my client, however, was barely noticed. No cost increase for me. My 2¢ worth. ;-) John ** 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 **
ListBoxes and AreaList Pro again (was: Object notation replacement for use of Self in a script — v18)
It would be too bad (and very time consuming) to get rid of all your hard work instead of just following AreaList Pro's evolution. The main ListBox features are basically AreaList Pro v6-7, IOW they (almost) do what AreaList Pro did 20 years ago. 4 versions (and many years) later there is still no comparison between the basic ListBoxes and the numerous features added by AreaList Pro v9 and v10. To name a few: breaks, sub-totals/calculations, transposition, displaying mySQL data, complete granularity up to cell level, event callbacks, area templates (global default settings), multiple header rows, zoom, etc. And the property-based syntax since version 9 makes it very easy to program. Now the recent features of ListBoxes regarding object support are not yet available in AreaList Pro, just because we have the same level of information as everyone else here, so it take time to catch up. OTOH it provides the distance to think twice about how it should be done, and collect requests from informed developers. BTW these features often (and increasingly will) require a 4D View pro license, much more expensive than AreaList Pro. And yes, version 11 will support entity selections and collections. Beta program just started (see my next post). Regards, -- Philippe Ganter www.e-node.net > On 1 May 2020, at 05:59, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> wrote: > > First there were no listboxes, so AreaList was created. And it filled a > needed hole in the 4D environment. So we all used AreaList Pro and loved it. > And built big code libraries with it. Then 4D implemented listboxes, but it > did not compete with AreaList in many areas. So for something “simple” you > would use a listbox, but for the power and features you stayed with AreaList > Pro. Now that gap is very small. 4D listboxes are very close to the power and > feature set of AreaList Pro. And if you want to use entities or use > collections AreaList Pro is out of the picture. 4D listboxes are the only > option. So throw the AreaList Pro code library away and start over. ** 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 **
Re: Object notation replacement for use of Self in a script — v18
I agreed on your request. Thanks for initiating it. Hopefully more will see its value and join in. — CB > On May 2, 2020, at 12:42 AM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: > > I've created a feature request on the new forum. Voting is open. > > 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 3:13 PM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: Kirk Brooks > Subject: Re: Object notation replacement for use of Self in a script — v18 > > Lahav, > > On Fri, May 1, 2020 at 1:51 PM lists via 4D_Tech <4d_tech@lists.4d.com> > wrote: > >> I have one word that will do all of what we are after : "This" >> > Damn - I wish I'd said that. > > >> 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. >> > I don't either. I probably overthink things like this or project my own > experience on it too much with the focus on the conceptual stuff. But I read > a lot of posts here and on the Forum and the common thread, to me, seems to > be folks attempting to use ORDA like it's an extension of classic. > It was incredibly frustrating for me until I got past thinking about ORDA > from a classic perspective. > > Cheers, will probably see you later today. >> > Hope so. > > -- > 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 **
Re: Object notation replacement for use of Self in a script — v18
> On May 1, 2020, at 1:13 PM, James Crate via 4D_Tech <4d_tech@lists.4d.com> > wrote: > >> Here is an idea which seems to work, but needs more evaluation. What if you >> named the form object with the property path in the form data? Even if >> periods are not allowed (they seem to be), another character could be used. >> I think the maximum length of an object name is 255 characters which should >> be plenty. > > The problem with this approach, as others have mentioned, is that you can no > longer use object name prefixes to show/hide/enable/etc groups of form > objects. I don't see why that is a problem. Just give them a common property in the path to group them and use a contains string, e.g. "@.property.@". Or probably better and more explicit, just create a collection on the Form for the items in the group. John DeSoi, Ph.D. ** 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 **
Re: Object notation replacement for use of Self in a script
> Le 2 mai 2020 à 07:10, Aparajita Fishman via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > >> This could be 4D’s chance to be a trendsetter! > > I don’t think it's worth it. Iterating in reverse is not a common operation. I don't think i've used reversed loops except to remove items from arrays. In a 'for each' it doesn't bother: for each ($entity;$entitySelection) if (mustRevove ($entity)) $entitySelection.minus($entity) end if end for each -- Arnaud de Montard ** 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 **
RE: Object notation replacement for use of Self in a script — v18
I've created a feature request on the new forum. Voting is open. 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 3:13 PM To: 4D iNug Technical <4d_tech@lists.4d.com> Cc: Kirk Brooks Subject: Re: Object notation replacement for use of Self in a script — v18 Lahav, On Fri, May 1, 2020 at 1:51 PM lists via 4D_Tech <4d_tech@lists.4d.com> wrote: > I have one word that will do all of what we are after : "This" > Damn - I wish I'd said that. > 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. > I don't either. I probably overthink things like this or project my own experience on it too much with the focus on the conceptual stuff. But I read a lot of posts here and on the Forum and the common thread, to me, seems to be folks attempting to use ORDA like it's an extension of classic. It was incredibly frustrating for me until I got past thinking about ORDA from a classic perspective. Cheers, will probably see you later today. > Hope so. -- 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 **
Re: Object notation replacement for use of Self in a script ― v18
Lahav, not 'That', 'This' :) Chip > >> I have one word that will do all of what we are after : "This" >> > Damn - I wish I'd said that. Hell is other people Jean-Paul Sartre ** 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 **
Re: Object notation replacement for use of Self in a script
> "Don’t be so quick to complain; you finally got ‘for each’ 10 years after > the rest of the world (including Active4D).” > Good point. So…you’re thinking that the feature set is complete? Absolutely. In fact it is more complete than most implementations, you can specify and begin and end index for ordered collections. > "I don’t know of a single language (and I have used at least 6) where ‘for > each’ is reversible.” > This could be 4D’s chance to be a trendsetter! I don’t think it's worth it. Iterating in reverse is not a common operation. > it’s funny that we have such a handy looping construct yet I have write > code to init and update my own index. If you need an index in a ‘for each’ loop, you should actually be using an indexed ‘for’ loop. That’s the point of having ‘for each’ separate from ‘for’: 90% of the time you don’t need the index and ‘for each’ is more concise, but when you need an index a for loop increments it for you. - Aparajita ** 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 **
Re: Object notation replacement for use of Self in a script — v18
On Apr 30, 2020, at 9:36 PM, Douglas von Roeder via 4D_Tech <4d_tech@lists.4d.com> wrote: > > 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. For each ($item;$collection.reverse()) // do some stuff End for each This is pretty much the same way you enumerate in reverse order in the other languages I use. Jim Crate ** 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 **
Re: Object notation replacement for use of Self in a script — v18
On May 1, 2020, at 3:44 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> wrote: > > I have not had any great joy attempting to use pop-ups with object > references. Haven't tried in v18 so maybe it's improved. In V17, popups work with form object expressions. If you set the expression to “Form.payment_type”, then when it displays, it selects the appropriate value in the popup, and choosing an item populates Form.payment_type” with the value. If you have a static set of options you just enter them in the object properties and you’re done. If you need a dynamic list it’s also pretty easy to use New list and OBJECT SET LIST BY REFERENCE. Much nicer than using popups with arrays. > But with respect to changing the names of a few form objects why is that a > deal? The form objects can be named anything - doesn't matter what the > field names are. I know form objects can be named anything. That was entirely my point; if you use form object names to reference the value, I.e. > Here is an example. I created a form with one in input and the object method > below. The form object name is "some.property.path" and the expression is > Form.some.property.path. Then you probably can’t use form object names to help manage groups of form objects. Jim Crate ** 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 **
Re: Object notation replacement for use of Self in a script — v18
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 > 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 >
Re: Object notation replacement for use of Self in a script — v18
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 <4d_tech@lists.4d.com>
> wrote:
>
> 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
Re: Object notation replacement for use of Self in a script — v18
Lahav, On Fri, May 1, 2020 at 1:51 PM lists via 4D_Tech <4d_tech@lists.4d.com> wrote: > I have one word that will do all of what we are after : "This" > Damn - I wish I'd said that. > 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. > I don't either. I probably overthink things like this or project my own experience on it too much with the focus on the conceptual stuff. But I read a lot of posts here and on the Forum and the common thread, to me, seems to be folks attempting to use ORDA like it's an extension of classic. It was incredibly frustrating for me until I got past thinking about ORDA from a classic perspective. Cheers, will probably see you later today. > Hope so. -- 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 **
Re: Object notation replacement for use of Self in a script
Aparajita: "Don’t be so quick to complain; you finally got ‘for each’ 10 years after the rest of the world (including Active4D).” Good point. So…you’re thinking that the feature set is complete? "I don’t know of a single language (and I have used at least 6) where ‘for each’ is reversible.” This could be 4D’s chance to be a trendsetter! "Indexed loops haven’t gone away and have their uses.” No doubt. I have to use them often when working with collections. Frankly, it’s funny that we have such a handy looping construct yet I have write code to init and update my own index. How about using “++" to increment? -- Douglas von Roeder 949-910-4084 On Fri, May 1, 2020 at 1:32 PM Aparajita Fishman via 4D_Tech < 4d_tech@lists.4d.com> wrote: > > >> 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. > > Don’t be so quick to complain; you finally got ‘for each’ 10 years after > the rest of the world (including Active4D). I don’t know of a single > language (and I have used at least 6) where ‘for each’ is reversible. > Indexed loops haven’t gone away and have their uses. > ** > 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 **
RE: Object notation replacement for use of Self in a script — v18
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 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
Re: Object notation replacement for use of Self in a script
>> 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. Don’t be so quick to complain; you finally got ‘for each’ 10 years after the rest of the world (including Active4D). I don’t know of a single language (and I have used at least 6) where ‘for each’ is reversible. Indexed loops haven’t gone away and have their uses. ** 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 **
Re: Object notation replacement for use of Self in a script — v18
Tim Nevels wrote: >if you want to use entities or use collections AreaList Pro is out of the >picture. As posted on e-node’s forum two weeks ago: “ALP v11 will definitely support entity selections and collections. Mostly it seems to already work in ALP 11.0a5" It may not do everything you want in the first version, but don’t worry - only babies don’t understand they can’t have everything immediately. Regards, Ben Kershaw ** 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 **
Re: Object notation replacement for use of Self in a script — v18
Jim, On Fri, May 1, 2020 at 11:53 AM James Crate via 4D_Tech < 4d_tech@lists.4d.com> wrote: > Suppose you have a section on the form with labels/fields for payment > info. You have a popup with payment type, and fields for credit card, ACH > (bank name/acct number), check, cash. When you choose a payment type, you > want to show the labels/fields for that payment type, and hide any other > payment labels/fields. If you thought far enough ahead to name all your > payment fields correctly, maybe you can make it work. But if your fields > aren’t already prefixed properly so you can do this with wildcards, then > you have a lot more messing around to do. > I have not had any great joy attempting to use pop-ups with object references. Haven't tried in v18 so maybe it's improved. So, yeah - that probably sucks. For these sorts of things I build a menu on the fly and call it from a button or click event on the field. I really like being able to easily set the placeholder text on fields like that. The problem with pop ups/dropdowns is there is all sorts of implicit data binding that 4D just handles in classic but isn't (at least wasn't) there for working with Form and references. But with respect to changing the names of a few form objects why is that a deal? The form objects can be named anything - doesn't matter what the field names are. Unless you are trying to update an existing form. My experience here is to put whatever I want to do in ORDA into a separate form and get it working the way I want. Then put that on the existing form as a subform. If you make the subform form object an object type (jeesh the nomenclature) it's a pretty seamless addition. -- 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 **
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
Re: Object notation replacement for use of Self in a script — v18
On May 1, 2020, at 2:23 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> wrote: > > On Fri, May 1, 2020 at 11:14 AM James Crate via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > >> The problem with this approach, as others have mentioned, is that you can >> no longer use object name prefixes to show/hide/enable/etc groups of form >> objects. >> > > Why do you say that? John was talking about using the form expression as the form object name. > Here is an example. I created a form with one in input and the object method > below. The form object name is "some.property.path" and the expression is > Form.some.property.path. Suppose you have a section on the form with labels/fields for payment info. You have a popup with payment type, and fields for credit card, ACH (bank name/acct number), check, cash. When you choose a payment type, you want to show the labels/fields for that payment type, and hide any other payment labels/fields. If you thought far enough ahead to name all your payment fields correctly, maybe you can make it work. But if your fields aren’t already prefixed properly so you can do this with wildcards, then you have a lot more messing around to do. Jim Crate ** 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 **
Re: Object notation replacement for use of Self in a script — v18
Jim, On Fri, May 1, 2020 at 11:14 AM James Crate via 4D_Tech < 4d_tech@lists.4d.com> wrote: > The problem with this approach, as others have mentioned, is that you can > no longer use object name prefixes to show/hide/enable/etc groups of form > objects. > Why do you say that? In v18R2 I'm using: *OBJECT SET ENABLED*(*;"btn_setDoc";*Form*.files_LB.curItem#*Null*) // enable when file is selected *OBJECT SET VISIBLE*(*;"btn_setDoc";*Form*.files_LB.curItem#*Null*) I added the set visible just to verify if works. It does. I also have an input which displays an object named "Input2" and this works on it as well. And I have forms using things like: *OBJECT SET VISIBLE*(*;"btn_nav@";*Form*.files_LB.curItem#*Null*) Am I missing something? -- 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 **
Re: Object notation replacement for use of Self in a script — v18
On May 1, 2020, at 10:07 AM, John DeSoi via 4D_Tech <4d_tech@lists.4d.com> wrote: > Here is an idea which seems to work, but needs more evaluation. What if you > named the form object with the property path in the form data? Even if > periods are not allowed (they seem to be), another character could be used. I > think the maximum length of an object name is 255 characters which should be > plenty. The problem with this approach, as others have mentioned, is that you can no longer use object name prefixes to show/hide/enable/etc groups of form objects. On Apr 30, 2020, at 7:53 PM, Peter Hay via 4D_Tech <4d_tech@lists.4d.com> wrote: > > What we really need is a way to access a Form Object's "Variable or > Expression". There's a Command named "Object Get Data Source" which was > added in v14, but it only returns a Pointer if "Variable or Expression" is > a Variable. If it's an Expression it returns Nil. Yes, and it’s likely it will be added eventually. I mean we got a built-in string split command in v17, so it’s never too late! For the foreseeable future, there is no way to get a pointer to an object attribute and you can’t work with the form object value directly. In Laurent’s 2020 Summit presentation on classes (Entity extensions), he showed setting up a “virtual attribute” with custom getter/setter methods. I assume you will be able to set up custom getter/setter methods for datastore attributes as well, so when you are able to use that functionality (v18R?), you will be able to specify that logic in the Entity class extension and not the form. Realistically, if you want to be “all-in” on ORDA, you’ll want to use the 4D v18R? release that supports classes, DataClass and Entity extensions as soon as it’s available. Currently you spend much of your time working around the lack of those things. Jim Crate ** 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 **
Re: Object notation replacement for use of Self in a script — v18
Here is an idea which seems to work, but needs more evaluation. What if you named the form object with the property path in the form data? Even if periods are not allowed (they seem to be), another character could be used. I think the maximum length of an object name is 255 characters which should be plenty. Here is an example. I created a form with one in input and the object method below. The form object name is "some.property.path" and the expression is Form.some.property.path. Case of : (Form event code=On Load) Form.some:=New object Form.some.property:=New object Form.some.property.path:="TEST 123" : (Form event code=On Data Change) C_TEXT($name) C_COLLECTION($cPath) C_OBJECT($object) $name:=OBJECT Get name(Object current) $cPath:=Split string($name;".") $object:=Form For each ($name;$cPath.slice(0;-1)) //All except last element to get the object. $object:=$object[$name] End for each $name:=$cPath.pop() $object[$name]:=Uppercase($object[$name]) End case John DeSoi, Ph.D. > On Apr 30, 2020, at 7:53 PM, Peter Hay via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > What we really need is a way to access a Form Object's "Variable or > Expression". There's a Command named "Object Get Data Source" which was > added in v14, but it only returns a Pointer if "Variable or Expression" is > a Variable. If it's an Expression it returns Nil. ** 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 **
Re: Object notation replacement for use of Self in a script — v18
On Apr 30, 2020, at 10:00 PM, Douglas von Roeder wrote: > 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!" I see my name… and have to say “he’s right”. 4D is operating in a mode where they release what they can as quickly as they can. They don’t wait literally years to build a complete, finished product/feature set. They are in RAD mode. The “R” release is the example of that. We are getting a lot of features very, very fast. Yes, there are always some that complain that they are not getting everything right now. It is too slow. It is not complete. Why do we not have this or that? Gentlemen... grow up. Only babies don’t understand that you can’t have everything immediately. If 4D did what you claim you wanted — deliver a feature complete and totally stable new feature set — you’d be wait literally years. And you would then say “4D is doing nothing, I’ve seen nothing new for YEARS!" I am 100% on 4D’s side. In my opinion they have made a good decision with doing the “R” releases and putting out new features every 3 months. Remember that you get a new “R” release every 3 months. Every 3 months you get new feature and more things that you did not have before. And now with the 2 year major Long Term Support (LTS) cycle you are going to get 8 “R” releases of new features every 3 months. Then you get a new, major LTS version that has 2 years worth of development work. And it will be a solid release. A deployable x.0 release. That’s the goal at least. And They got very, very close with v17.0. Unknown how much closer they got with v18.0 release. But for sure it is 1,000 times better than v11.0, or v12.0 or v13.0. I lived through v11, v12 and v13 at client sites in production. And back then EVERYONE with any sense waited for .2 or .3 before deploying to production at client sites. I deployed v17.0 at client sites — first time in my life I deployed a 4D x.0. And I continued to upgrade them to .1 and .2 and using hot fix version. My current v17 version is v17.3 HF2. Yeah… I know 17.4 has been releases and I’ll most likely upgrade to that at some point. But v17.3 HF2 fixed enough and was “good enough” that I’m happy with it. ORDA and the new “classes” and the even more exciting web based options 4D is building will give us more options. Some we can use and incorporate into existing code easily. Some of the new feature REQUIRE doing new code. Retrofitting will not be possible or will not give you the desired results. Sometimes you just have to start over. I’ll give you an example… listboxes. First there were no listboxes, so AreaList was created. And it filled a needed hole in the 4D environment. So we all used AreaList Pro and loved it. And built big code libraries with it. Then 4D implemented listboxes, but it did not compete with AreaList in many areas. So for something “simple” you would use a listbox, but for the power and features you stayed with AreaList Pro. Now that gap is very small. 4D listboxes are very close to the power and feature set of AreaList Pro. And if you want to use entities or use collections AreaList Pro is out of the picture. 4D listboxes are the only option. So throw the AreaList Pro code library away and start over. 4D has ramped up to deliver a lot of fantastic, new and advanced features to the platform. They are doing it in pieces. It’s going to take time. But by releasing it in pieces over the next 2 years we will have time to get to know it, and learn it, and plan for it and figure out how we can integrate it into our existing projects. And to get some of the benefits we will need to start over. And we have to wait for the feature set to be completed. No retrofitting. All new code. But we get to choose if we do this. We can choose to not make the jump. Stay in “classic” mode and that’s OK. It’s a client driven world. If they don’t want to pay for it — and you don’t want to rewrite it all for free — you keep on the current path. Totally cool and supported. No 4D Summit 2020. It went virtual and online and it’s free. So zero complaints here.. other than missing seeing all my “old friends” again. I did miss that. A lot. 2021 there will be 4D World Tour — as usual. And it will be filled with v18 “R” release “goodies”. So I’m looking forward to that. 2022 will be another 4D Summit… and the release of 4D v19. 2 years worth of development that will finally be completed and released. It’s gonna be a big deal! The TV show Kung Fu… I loved that show when it was on TV in reruns. (I have the entire series on DVD and have watched it all from beginning to end a few years ago.)
Re: Object notation replacement for use of Self in a script — v18
"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 < 4d_tech@lists.4d.com> 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 <4d_tech@lists.4d.com> > 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 <4d_tech-boun...@lists.4d.com> On Behalf Of Douglas von > Roeder via 4D_Tech > > Sent: Thursday, April 30, 2020 5:51 PM > > To: 4D iNug Technical <4d_tech@lists.4d.com> > > Cc: Douglas von Roeder > > 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 >
Re: Object notation replacement for use of Self in a script — v18
"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….” Couldn’t agree more! As the average age of installed base of programmers decreases, the % of “classic” code in production systems will drop (hat’s the audience that will use ORDA + OOP in 4D) "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.” Agreed. If change wasn’t an inherent part of all facets of life, life would have stopped at the amoeba. -- Douglas von Roeder 949-910-4084 On Thu, Apr 30, 2020 at 5:23 PM lists via 4D_Tech <4d_tech@lists.4d.com> 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 <4d_tech-boun...@lists.4d.com> On Behalf Of Douglas von > Roeder via 4D_Tech > Sent: Thursday, April 30, 2020 5:51 PM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: Douglas von Roeder > 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 < > 4d_tech@lists.4d.com> wrote: > > > > > > On Apr 30, 2020, at 4:43 PM, lists via 4D_Tech > > > <4d_tech@lists.4d.com> > > 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: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 > ** ** 4D Internet Users Group
Re: Object notation replacement for use of Self in a script — v18
You say things much more succinctly and clearly than do I, Lahav. I agree. — Chris > On Apr 30, 2020, at 3:43 PM, lists via 4D_Tech <4d_tech@lists.4d.com> 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... > > Lahav > > -Original Message- > From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Keisuke Miyako via > 4D_Tech > Sent: Thursday, April 30, 2020 3:20 PM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: Keisuke Miyako > Subject: Re: Object notation replacement for use of Self in a script — v18 > > I can only share how I would design my user interface, but in short, I would > not have this problem > >> (Object get name).prettyFormat() > > and here's why. > > I see that the form object should either be bound to (=managed automatically > by 4D) or divorced from (managed by me) its data source. > > the object name is only interesting to me for visibility, enable/disable, etc. > I would have some kind of naming convention to take advantage of the @ > wildcard, but that's all. > > as for the data source, if I wanted to implement some kind of rule on it, I > would do so without the form object. > > in other words, I would only use object notation on form objects that do not > need to use form events. > in my opinion, any form object that do use a form event should not have > object notation as their data source, since the event is attached to the form > object and not the data source object. > there would be room for programming error if the same data source could be > manipulated outside the form event. > > same with the current item/position/selection property of the collection type > listbox. > the properties only make sense in the context of zero-coding. > if I want to manage the binding by code, I would keep these properties empty. > > classes are coming in 18 R3, but you can already create pseudo-classes by > writing custom constructors that return an object with prefab properties and > methods. > > until the use of "This" is extended to text inputs and other form objects, I > would not expose object notation (which implies that the target is an object) > in any of my form objects, other than for form objects that exist purely for > display purposes. > > I would focus my use of object notation to areas where classic code could not > go, not spaces already occupied by classic code. > >> On May 1, 2020, at 4:54, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> >> wrote: >> (Object get name).prettyFormatHow would that be achieved? > > ** > 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 **
Re: Object notation replacement for use of Self in a script — v18
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 <4d_tech@lists.4d.com> 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 <4d_tech-boun...@lists.4d.com> On Behalf Of Douglas von Roeder > via 4D_Tech > Sent: Thursday, April 30, 2020 5:51 PM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: Douglas von Roeder > 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 < > 4d_tech@lists.4d.com> wrote: > >> >>> On Apr 30, 2020, at 4:43 PM, lists via 4D_Tech >>> <4d_tech@lists.4d.com> >> wrote: >>> >>> OK, based on this design, we are back to using variables
Re: Object notation replacement for use of Self in a script — v18
Hi Chris,
What we really need is a way to access a Form Object's "Variable or
Expression". There's a Command named "Object Get Data Source" which was
added in v14, but it only returns a Pointer if "Variable or Expression" is
a Variable. If it's an Expression it returns Nil.
If we could get the Expression, then we could use Evaluate Formula to
Get/Set the Value.
There's currently no 4D Command to do this directly, but you can do it
using "Form Convert to dynamic". It's an "expensive" command, but it does
the job until 4D give us a better way.
//Method: Object Get Expression
//Returns the Expression / Data Source of the Form Object named $1
C_TEXT($0) //Object Expression / Data Source
C_TEXT($1) //Optional, Object Name. Default = the Current Object
C_LONGINT($l_Page)
C_OBJECT($o_Form)
C_TEXT($t_ObjectName)
Case of
: (Count parameters<1)
$t_ObjectName:=OBJECT Get name(Object current)
: ($1="")
$t_ObjectName:=OBJECT Get name(Object current)
Else
$t_ObjectName:=$1
End case
If ($t_ObjectName#"")
If (Current form table=Null)
$o_Form:=FORM Convert to dynamic(Current form name)
Else
$o_Form:=FORM Convert to dynamic(Current form table->;Current form name)
End if
If ($o_Form.pages#Null)
$0:=String($o_Form.pages[FORM Get current
page].objects[$t_ObjectName].dataSource) //The Object is most likely to be
on the Current Page, so start looking there
If ($0="") //Not on the Current Page, so look at all Pages
For ($l_Page;0;$o_Form.pages.length-1)
If ($l_Page#FORM Get current page) //We've already checked the Current
Page, so no need to check it again
$0:=String($o_Form.pages[$l_Page].objects[$t_ObjectName].dataSource)
If ($0#"")
$l_Page:=999
End if
End if
End for
End if
End if
End if
Ideally I'd like to have Object Get Value and Object Set Value commands.
I present to you;
---
//Method: Object Set Vaule
C_TEXT($1) //Object Name
C_VARIANT($2) //Value
C_TEXT($t_DataSource;$t_ObjectName)
C_VARIANT(__ObjectValue) //Required for EXECUTE FORMULA
If ($1="")
$t_ObjectName:=OBJECT Get name(Object current)
Else
$t_ObjectName:=$1
End if
If ($t_ObjectName#"")
$t_DataSource:=Object Get Expression ($t_ObjectName)
If ($t_DataSource#"")
__ObjectValue:=$2 //Params and Locals can't be used in EXECUTE FORMULA
EXECUTE FORMULA($t_DataSource+":=__ObjectValue")
End if
End if
---
//Method: Object Get Vaule
C_VARIANT($0) //Object Value
C_TEXT($1) //Object Name. Default = the Current Object
C_TEXT($t_DataSource;$t_ObjectName)
C_VARIANT(__ObjectValue) //Required for EXECUTE FORMULA
Case of
: (Count parameters<1)
$t_ObjectName:=OBJECT Get name(Object current)
: ($1="")
$t_ObjectName:=OBJECT Get name(Object current)
Else
$t_ObjectName:=$1
End case
If ($t_ObjectName#"")
$t_DataSource:=Object Get Expression ($t_ObjectName)
If ($t_DataSource#"")
EXECUTE FORMULA("__ObjectValue:="+$t_DataSource)
$0:=__ObjectValue //Params and Locals can't be used in EXECUTE FORMULA
End if
End if
It's very round about code, but not particularly complicated, which makes
me wonder why 4D don't just give us some commands to do it.
Anyway, I hope these work for you. They work for me.
--
Pete Hay
Managing Director
Foreground Software Limited
New Zealand
**
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
**
RE: Object notation replacement for use of Self in a script — v18
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 <4d_tech-boun...@lists.4d.com> On Behalf Of Douglas von Roeder via 4D_Tech Sent: Thursday, April 30, 2020 5:51 PM To: 4D iNug Technical <4d_tech@lists.4d.com> Cc: Douglas von Roeder 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 < 4d_tech@lists.4d.com> wrote: > > > On Apr 30, 2020, at 4:43 PM, lists via 4D_Tech > > <4d_tech@lists.4d.com> > 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: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 **
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 < 4d_tech@lists.4d.com> wrote: > > > On Apr 30, 2020, at 4:43 PM, lists via 4D_Tech <4d_tech@lists.4d.com> > 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: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 **
Re: Object notation replacement for use of Self in a script — v18
> On Apr 30, 2020, at 4:43 PM, lists via 4D_Tech <4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com **
RE: Object notation replacement for use of Self in a script — v18
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... Lahav -Original Message- From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Keisuke Miyako via 4D_Tech Sent: Thursday, April 30, 2020 3:20 PM To: 4D iNug Technical <4d_tech@lists.4d.com> Cc: Keisuke Miyako Subject: Re: Object notation replacement for use of Self in a script — v18 I can only share how I would design my user interface, but in short, I would not have this problem > (Object get name).prettyFormat() and here's why. I see that the form object should either be bound to (=managed automatically by 4D) or divorced from (managed by me) its data source. the object name is only interesting to me for visibility, enable/disable, etc. I would have some kind of naming convention to take advantage of the @ wildcard, but that's all. as for the data source, if I wanted to implement some kind of rule on it, I would do so without the form object. in other words, I would only use object notation on form objects that do not need to use form events. in my opinion, any form object that do use a form event should not have object notation as their data source, since the event is attached to the form object and not the data source object. there would be room for programming error if the same data source could be manipulated outside the form event. same with the current item/position/selection property of the collection type listbox. the properties only make sense in the context of zero-coding. if I want to manage the binding by code, I would keep these properties empty. classes are coming in 18 R3, but you can already create pseudo-classes by writing custom constructors that return an object with prefab properties and methods. until the use of "This" is extended to text inputs and other form objects, I would not expose object notation (which implies that the target is an object) in any of my form objects, other than for form objects that exist purely for display purposes. I would focus my use of object notation to areas where classic code could not go, not spaces already occupied by classic code. > On May 1, 2020, at 4:54, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> > wrote: > (Object get name).prettyFormatHow would that be achieved? ** 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 **
RE: Object notation replacement for use of Self in a script — v18
Indeed, if you are using a process or an IP variables to hold the entity (or object for that matter), you will get a pointer to that variable. But if you are using the Form.XXX notation and eliminate the use of process or IP variables, the pointer always return Nil, so it's useless. The question remains, what is the right "New World" approach to achieve functionality that seems to have no work around. Lahav -Original Message- From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via 4D_Tech Sent: Thursday, April 30, 2020 3:03 PM To: 4D iNug Technical <4d_tech@lists.4d.com> Cc: kculotta Subject: Re: Object notation replacement for use of Self in a script — v18 Sorry, meant to say the pointer that results from the Object Get name is to the entity > On Apr 30, 2020, at 3:59 PM, kculotta via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > 18.1 > > The pointer OBJECT Get name(Object current) is to the entity instead of the > to the entity attribute. > > The field is eg, MyEntity.MyName, but the pointer to the form object > ends up being ->MyEntity > >> On Apr 30, 2020, at 3:52 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: >> >> Sorry, Are you saying that you can get a valid pointer with Object get >> pointer() on a dot notation object of a form?, if so what version? >> >> Lahav >> >> -Original Message- >> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta >> via 4D_Tech >> Sent: Thursday, April 30, 2020 2:50 PM >> To: 4D iNug Technical <4d_tech@lists.4d.com> >> Cc: kculotta >> Subject: Re: Object notation replacement for use of Self in a script >> — v18 >> >> Yes, I'm using it, but it really seems like an artificial way to get an >> entity field's displayed contents. >> >> I'll explore your example. >> >> Keith - CDI >> >>> On Apr 30, 2020, at 3:45 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: >>> >>> Did you actually test this?, any kind of a get pointer on a form object >>> having a dot notation source will return a Nil pointer, regardless of the >>> name matching or not. >>> >>> If you are using matched names, you could use the following: >>> >>> Form[Object get name(object current)]:=DoWhatever(Form[Object get >>> name(object current)]) >>> >>> But that is not quite what we need to be truly generic >>> >>> Lahav >>> >>> -Original Message- >>> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta >>> via 4D_Tech >>> Sent: Thursday, April 30, 2020 2:29 PM >>> To: 4D iNug Technical <4d_tech@lists.4d.com> >>> Cc: kculotta >>> Subject: Re: Object notation replacement for use of Self in a script >>> — >>> v18 >>> >>> This example does not avoid having to carefully name form objects and the >>> form object must have "matching" variable and object names: variable >>> entity.MyName with its object name of "MyName" >>> >>> // the object method >>> a_test (OBJECT Get name(Object current)) >>> >>> // a_Test >>> $ent:=OBJECT Get pointer(Object named;$1)-> $s:=$ent[$1] >>> ALERT($s) // the value entered into the text area >>> >>> Keith - CDI >>> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> wrote: I don’t wish to imply that I ‘prefer’ pointers; in fact, I am not using a single process variable, interprocess variable, or any other ‘vestiges’ of 4D Classic. I am ‘fully committed’ to object notation. I also use Storage extensively for system-wide values, and really love it. The problem I describe is that I need a way to generically ‘get’ and ’set’ the value of an object (meaning an entry variable on the form). 1) A variable is placed on the form. It’s “variable or expression” is: Form.LB.Browser_JobForms.en_edit.RigFrom. It has an object name of “enLSDFromRigDispatch” I have given it this name because it gives me a simple methodology to SHOW/HIDE a whole group of objects on the screen with OBJECT SET VISIBLE(*; “enLSD@“;…) Now I wish to use a standard project method to ‘pretty-format’ this variable. With ‘4D Classic’ this is easily achieved by making a project method that takes a POINTER in $1. The OBJECT SCRIPT would be something simple, like: PRETTY_FORMAT(Self) [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of the variable and do any formatting options needed] With ‘4D DOT NOTATION’ … — How do I create a simple OBJECT SCRIPT that would do something similar to that in 4D Classic? — I don’t feel that I should have to resort to using the ‘variable or expression’ name in every single script; because what happens if I change that variable for some reason and it totally screws up the object script? And it also makes it very complicated. THE OBJECT METHOD should be something as simple as: PRETTY_FORMAT ( Object Get Name )—— instead of Self
Re: Object notation replacement for use of Self in a script — v18
I can only share how I would design my user interface, but in short, I would not have this problem > (Object get name).prettyFormat() and here's why. I see that the form object should either be bound to (=managed automatically by 4D) or divorced from (managed by me) its data source. the object name is only interesting to me for visibility, enable/disable, etc. I would have some kind of naming convention to take advantage of the @ wildcard, but that's all. as for the data source, if I wanted to implement some kind of rule on it, I would do so without the form object. in other words, I would only use object notation on form objects that do not need to use form events. in my opinion, any form object that do use a form event should not have object notation as their data source, since the event is attached to the form object and not the data source object. there would be room for programming error if the same data source could be manipulated outside the form event. same with the current item/position/selection property of the collection type listbox. the properties only make sense in the context of zero-coding. if I want to manage the binding by code, I would keep these properties empty. classes are coming in 18 R3, but you can already create pseudo-classes by writing custom constructors that return an object with prefab properties and methods. until the use of "This" is extended to text inputs and other form objects, I would not expose object notation (which implies that the target is an object) in any of my form objects, other than for form objects that exist purely for display purposes. I would focus my use of object notation to areas where classic code could not go, not spaces already occupied by classic code. > On May 1, 2020, at 4:54, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> > wrote: > (Object get name).prettyFormatHow would that be achieved? ** 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 **
Re: Object notation replacement for use of Self in a script — v18
Agree with Lahav. I think the point of OBJECT NAMES is to also help with SHOW/HIDE objects on screen by OBJECT SET VISIBLE ( *; “Prefix@“) sort of thing. The object name should not need to be exactly what the ‘Variable or expression’ is. And besides, there would be quite a problem if the object name ended up having to be: Form.en_This.Company.Name — which is quite a valid ‘variable or expression’. The simple solution is for there to be a way to get at the value of the form object, as per: >> PRETTY_FORMAT ( Object Get Name )—— instead of Self And for PRETTY_FORMAT( ) to thereafter be able to manipulate the value of that Object. [I hate the ambiguity of ‘Object’ in 4D; too many conflicting meanings]. - Chris > On Apr 30, 2020, at 2:45 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: > > Did you actually test this?, any kind of a get pointer on a form object > having a dot notation source will return a Nil pointer, regardless of the > name matching or not. > > If you are using matched names, you could use the following: > > Form[Object get name(object current)]:=DoWhatever(Form[Object get name(object > current)]) > > But that is not quite what we need to be truly generic > > Lahav > > -Original Message- > From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via 4D_Tech > Sent: Thursday, April 30, 2020 2:29 PM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: kculotta > Subject: Re: Object notation replacement for use of Self in a script — v18 > > This example does not avoid having to carefully name form objects and the > form object must have "matching" variable and object names: variable > entity.MyName with its object name of "MyName" > > // the object method > a_test (OBJECT Get name(Object current)) > > // a_Test > $ent:=OBJECT Get pointer(Object named;$1)-> $s:=$ent[$1] > ALERT($s) // the value entered into the text area > > Keith - CDI > >> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech >> <4d_tech@lists.4d.com> wrote: >> >> I don’t wish to imply that I ‘prefer’ pointers; in fact, I am not using a >> single process variable, interprocess variable, or any other ‘vestiges’ of >> 4D Classic. I am ‘fully committed’ to object notation. I also use Storage >> extensively for system-wide values, and really love it. >> The problem I describe is that I need a way to generically ‘get’ and ’set’ >> the value of an object (meaning an entry variable on the form). >> >> 1) A variable is placed on the form. It’s “variable or expression” is: >> Form.LB.Browser_JobForms.en_edit.RigFrom. It has an object name of >> “enLSDFromRigDispatch” >> >> I have given it this name because it gives me a simple methodology to >> SHOW/HIDE a whole group of objects on the screen with OBJECT SET >> VISIBLE(*; “enLSD@“;…) >> >> Now I wish to use a standard project method to ‘pretty-format’ this variable. >> With ‘4D Classic’ this is easily achieved by making a project method that >> takes a POINTER in $1. >> The OBJECT SCRIPT would be something simple, like: >> PRETTY_FORMAT(Self) >> [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of >> the variable and do any formatting options needed] >> >> With ‘4D DOT NOTATION’ … >> — How do I create a simple OBJECT SCRIPT that would do something >> similar to that in 4D Classic? — I don’t feel that I should have to resort >> to using the ‘variable or expression’ name in every single script; because >> what happens if I change that variable for some reason and it totally screws >> up the object script? And it also makes it very complicated. >> THE OBJECT METHOD should be something as simple as: >> PRETTY_FORMAT ( Object Get Name )—— instead of Self >> >> The PRETTY_FORMAT( ) should be able to get at and set the value of the form >> object from that name. >> >> Alternatively, if one wants to not bother having scripts for every input >> variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD: >> Case of >> :( Form event code = on load ) >> Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 >> ) … // objects that need to be ‘Pretty Formatted' >> >> : ( Form event code = on losing focus ) >> $curObjectName:= Form Event.objectName >> … see if is in the list of .col_toPrettyFormat … >> PRETTY_FORMAT( $curObjectName ) >> >> … >> >> So how would one implement something like: >> PRETTY FORMAT ( Object Get Name ) in a script; or PRETTY FORMAT ( >> Form Event.objectName ) >> ??? >> >> Thanks, >> Chris >> >> p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create >> classes. That is very intriguing and a necessary development in 4D, as is >> C_VARIANT( ). >> If one wanted to be able to have the script be: >> >> (Object get name).prettyFormatHow would that be achieved? >> >> Even if in the script one could use “This”, but it is null. >> I think that ’This’ should be perfectly valid
Re: Object notation replacement for use of Self in a script — v18
Sorry, meant to say the pointer that results from the Object Get name is to the entity > On Apr 30, 2020, at 3:59 PM, kculotta via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > 18.1 > > The pointer OBJECT Get name(Object current) is to the entity instead of the > to the entity attribute. > > The field is eg, MyEntity.MyName, but the pointer to the form object ends up > being ->MyEntity > >> On Apr 30, 2020, at 3:52 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: >> >> Sorry, Are you saying that you can get a valid pointer with Object get >> pointer() on a dot notation object of a form?, if so what version? >> >> Lahav >> >> -Original Message- >> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via >> 4D_Tech >> Sent: Thursday, April 30, 2020 2:50 PM >> To: 4D iNug Technical <4d_tech@lists.4d.com> >> Cc: kculotta >> Subject: Re: Object notation replacement for use of Self in a script — v18 >> >> Yes, I'm using it, but it really seems like an artificial way to get an >> entity field's displayed contents. >> >> I'll explore your example. >> >> Keith - CDI >> >>> On Apr 30, 2020, at 3:45 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: >>> >>> Did you actually test this?, any kind of a get pointer on a form object >>> having a dot notation source will return a Nil pointer, regardless of the >>> name matching or not. >>> >>> If you are using matched names, you could use the following: >>> >>> Form[Object get name(object current)]:=DoWhatever(Form[Object get >>> name(object current)]) >>> >>> But that is not quite what we need to be truly generic >>> >>> Lahav >>> >>> -Original Message- >>> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via >>> 4D_Tech >>> Sent: Thursday, April 30, 2020 2:29 PM >>> To: 4D iNug Technical <4d_tech@lists.4d.com> >>> Cc: kculotta >>> Subject: Re: Object notation replacement for use of Self in a script — >>> v18 >>> >>> This example does not avoid having to carefully name form objects and the >>> form object must have "matching" variable and object names: variable >>> entity.MyName with its object name of "MyName" >>> >>> // the object method >>> a_test (OBJECT Get name(Object current)) >>> >>> // a_Test >>> $ent:=OBJECT Get pointer(Object named;$1)-> $s:=$ent[$1] >>> ALERT($s) // the value entered into the text area >>> >>> Keith - CDI >>> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> wrote: I don’t wish to imply that I ‘prefer’ pointers; in fact, I am not using a single process variable, interprocess variable, or any other ‘vestiges’ of 4D Classic. I am ‘fully committed’ to object notation. I also use Storage extensively for system-wide values, and really love it. The problem I describe is that I need a way to generically ‘get’ and ’set’ the value of an object (meaning an entry variable on the form). 1) A variable is placed on the form. It’s “variable or expression” is: Form.LB.Browser_JobForms.en_edit.RigFrom. It has an object name of “enLSDFromRigDispatch” I have given it this name because it gives me a simple methodology to SHOW/HIDE a whole group of objects on the screen with OBJECT SET VISIBLE(*; “enLSD@“;…) Now I wish to use a standard project method to ‘pretty-format’ this variable. With ‘4D Classic’ this is easily achieved by making a project method that takes a POINTER in $1. The OBJECT SCRIPT would be something simple, like: PRETTY_FORMAT(Self) [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of the variable and do any formatting options needed] With ‘4D DOT NOTATION’ … — How do I create a simple OBJECT SCRIPT that would do something similar to that in 4D Classic? — I don’t feel that I should have to resort to using the ‘variable or expression’ name in every single script; because what happens if I change that variable for some reason and it totally screws up the object script? And it also makes it very complicated. THE OBJECT METHOD should be something as simple as: PRETTY_FORMAT ( Object Get Name )—— instead of Self The PRETTY_FORMAT( ) should be able to get at and set the value of the form object from that name. Alternatively, if one wants to not bother having scripts for every input variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD: Case of :( Form event code = on load ) Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 ) … // objects that need to be ‘Pretty Formatted' : ( Form event code = on losing focus ) $curObjectName:= Form Event.objectName … see if is in the list of .col_toPrettyFormat … PRETTY_FORMAT( $curObjectName ) … So how would
Re: Object notation replacement for use of Self in a script — v18
18.1 The pointer OBJECT Get name(Object current) is to the entity instead of the to the entity attribute. The field is eg, MyEntity.MyName, but the pointer to the form object ends up being ->MyEntity > On Apr 30, 2020, at 3:52 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: > > Sorry, Are you saying that you can get a valid pointer with Object get > pointer() on a dot notation object of a form?, if so what version? > > Lahav > > -Original Message- > From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via 4D_Tech > Sent: Thursday, April 30, 2020 2:50 PM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: kculotta > Subject: Re: Object notation replacement for use of Self in a script — v18 > > Yes, I'm using it, but it really seems like an artificial way to get an > entity field's displayed contents. > > I'll explore your example. > > Keith - CDI > >> On Apr 30, 2020, at 3:45 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: >> >> Did you actually test this?, any kind of a get pointer on a form object >> having a dot notation source will return a Nil pointer, regardless of the >> name matching or not. >> >> If you are using matched names, you could use the following: >> >> Form[Object get name(object current)]:=DoWhatever(Form[Object get >> name(object current)]) >> >> But that is not quite what we need to be truly generic >> >> Lahav >> >> -Original Message- >> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via >> 4D_Tech >> Sent: Thursday, April 30, 2020 2:29 PM >> To: 4D iNug Technical <4d_tech@lists.4d.com> >> Cc: kculotta >> Subject: Re: Object notation replacement for use of Self in a script — >> v18 >> >> This example does not avoid having to carefully name form objects and the >> form object must have "matching" variable and object names: variable >> entity.MyName with its object name of "MyName" >> >> // the object method >> a_test (OBJECT Get name(Object current)) >> >> // a_Test >> $ent:=OBJECT Get pointer(Object named;$1)-> $s:=$ent[$1] >> ALERT($s) // the value entered into the text area >> >> Keith - CDI >> >>> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech >>> <4d_tech@lists.4d.com> wrote: >>> >>> I don’t wish to imply that I ‘prefer’ pointers; in fact, I am not using a >>> single process variable, interprocess variable, or any other ‘vestiges’ of >>> 4D Classic. I am ‘fully committed’ to object notation. I also use Storage >>> extensively for system-wide values, and really love it. >>> The problem I describe is that I need a way to generically ‘get’ and ’set’ >>> the value of an object (meaning an entry variable on the form). >>> >>> 1) A variable is placed on the form. It’s “variable or expression” is: >>> Form.LB.Browser_JobForms.en_edit.RigFrom. It has an object name of >>> “enLSDFromRigDispatch” >>> >>> I have given it this name because it gives me a simple methodology to >>> SHOW/HIDE a whole group of objects on the screen with OBJECT SET >>> VISIBLE(*; “enLSD@“;…) >>> >>> Now I wish to use a standard project method to ‘pretty-format’ this >>> variable. >>> With ‘4D Classic’ this is easily achieved by making a project method that >>> takes a POINTER in $1. >>> The OBJECT SCRIPT would be something simple, like: >>> PRETTY_FORMAT(Self) >>> [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of >>> the variable and do any formatting options needed] >>> >>> With ‘4D DOT NOTATION’ … >>> — How do I create a simple OBJECT SCRIPT that would do something >>> similar to that in 4D Classic? — I don’t feel that I should have to resort >>> to using the ‘variable or expression’ name in every single script; because >>> what happens if I change that variable for some reason and it totally >>> screws up the object script? And it also makes it very complicated. >>> THE OBJECT METHOD should be something as simple as: >>> PRETTY_FORMAT ( Object Get Name )—— instead of Self >>> >>> The PRETTY_FORMAT( ) should be able to get at and set the value of the form >>> object from that name. >>> >>> Alternatively, if one wants to not bother having scripts for every input >>> variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD: >>> Case of >>> :( Form event code = on load ) >>> Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 >>> ) … // objects that need to be ‘Pretty Formatted' >>> >>> : ( Form event code = on losing focus ) >>> $curObjectName:= Form Event.objectName >>> … see if is in the list of .col_toPrettyFormat … >>> PRETTY_FORMAT( $curObjectName ) >>> >>> … >>> >>> So how would one implement something like: >>> PRETTY FORMAT ( Object Get Name ) in a script; or PRETTY FORMAT ( >>> Form Event.objectName ) >>> ??? >>> >>> Thanks, >>> Chris >>> >>> p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create >>> classes. That is very intriguing and a necessary
RE: Object notation replacement for use of Self in a script — v18
Sorry, Are you saying that you can get a valid pointer with Object get pointer() on a dot notation object of a form?, if so what version? Lahav -Original Message- From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via 4D_Tech Sent: Thursday, April 30, 2020 2:50 PM To: 4D iNug Technical <4d_tech@lists.4d.com> Cc: kculotta Subject: Re: Object notation replacement for use of Self in a script — v18 Yes, I'm using it, but it really seems like an artificial way to get an entity field's displayed contents. I'll explore your example. Keith - CDI > On Apr 30, 2020, at 3:45 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: > > Did you actually test this?, any kind of a get pointer on a form object > having a dot notation source will return a Nil pointer, regardless of the > name matching or not. > > If you are using matched names, you could use the following: > > Form[Object get name(object current)]:=DoWhatever(Form[Object get > name(object current)]) > > But that is not quite what we need to be truly generic > > Lahav > > -Original Message- > From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via > 4D_Tech > Sent: Thursday, April 30, 2020 2:29 PM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: kculotta > Subject: Re: Object notation replacement for use of Self in a script — > v18 > > This example does not avoid having to carefully name form objects and the > form object must have "matching" variable and object names: variable > entity.MyName with its object name of "MyName" > > // the object method > a_test (OBJECT Get name(Object current)) > > // a_Test > $ent:=OBJECT Get pointer(Object named;$1)-> $s:=$ent[$1] > ALERT($s) // the value entered into the text area > > Keith - CDI > >> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech >> <4d_tech@lists.4d.com> wrote: >> >> I don’t wish to imply that I ‘prefer’ pointers; in fact, I am not using a >> single process variable, interprocess variable, or any other ‘vestiges’ of >> 4D Classic. I am ‘fully committed’ to object notation. I also use Storage >> extensively for system-wide values, and really love it. >> The problem I describe is that I need a way to generically ‘get’ and ’set’ >> the value of an object (meaning an entry variable on the form). >> >> 1) A variable is placed on the form. It’s “variable or expression” is: >> Form.LB.Browser_JobForms.en_edit.RigFrom. It has an object name of >> “enLSDFromRigDispatch” >> >> I have given it this name because it gives me a simple methodology to >> SHOW/HIDE a whole group of objects on the screen with OBJECT SET >> VISIBLE(*; “enLSD@“;…) >> >> Now I wish to use a standard project method to ‘pretty-format’ this variable. >> With ‘4D Classic’ this is easily achieved by making a project method that >> takes a POINTER in $1. >> The OBJECT SCRIPT would be something simple, like: >> PRETTY_FORMAT(Self) >> [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of >> the variable and do any formatting options needed] >> >> With ‘4D DOT NOTATION’ … >> — How do I create a simple OBJECT SCRIPT that would do something >> similar to that in 4D Classic? — I don’t feel that I should have to resort >> to using the ‘variable or expression’ name in every single script; because >> what happens if I change that variable for some reason and it totally screws >> up the object script? And it also makes it very complicated. >> THE OBJECT METHOD should be something as simple as: >> PRETTY_FORMAT ( Object Get Name )—— instead of Self >> >> The PRETTY_FORMAT( ) should be able to get at and set the value of the form >> object from that name. >> >> Alternatively, if one wants to not bother having scripts for every input >> variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD: >> Case of >> :( Form event code = on load ) >> Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 >> ) … // objects that need to be ‘Pretty Formatted' >> >> : ( Form event code = on losing focus ) >> $curObjectName:= Form Event.objectName >> … see if is in the list of .col_toPrettyFormat … >> PRETTY_FORMAT( $curObjectName ) >> >> … >> >> So how would one implement something like: >> PRETTY FORMAT ( Object Get Name ) in a script; or PRETTY FORMAT ( >> Form Event.objectName ) >> ??? >> >> Thanks, >> Chris >> >> p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create >> classes. That is very intriguing and a necessary development in 4D, as is >> C_VARIANT( ). >> If one wanted to be able to have the script be: >> >> (Object get name).prettyFormatHow would that be achieved? >> >> Even if in the script one could use “This”, but it is null. >> I think that ’This’ should be perfectly valid to use in an OBJECT SCRIPT, in >> a TRIGGER (referring to the record/entity being operated on), etc. But it is >> not, and I have trouble understanding
Re: Object notation replacement for use of Self in a script — v18
Yes, I'm using it, but it really seems like an artificial way to get an entity field's displayed contents. I'll explore your example. Keith - CDI > On Apr 30, 2020, at 3:45 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: > > Did you actually test this?, any kind of a get pointer on a form object > having a dot notation source will return a Nil pointer, regardless of the > name matching or not. > > If you are using matched names, you could use the following: > > Form[Object get name(object current)]:=DoWhatever(Form[Object get name(object > current)]) > > But that is not quite what we need to be truly generic > > Lahav > > -Original Message- > From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via 4D_Tech > Sent: Thursday, April 30, 2020 2:29 PM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: kculotta > Subject: Re: Object notation replacement for use of Self in a script — v18 > > This example does not avoid having to carefully name form objects and the > form object must have "matching" variable and object names: variable > entity.MyName with its object name of "MyName" > > // the object method > a_test (OBJECT Get name(Object current)) > > // a_Test > $ent:=OBJECT Get pointer(Object named;$1)-> $s:=$ent[$1] > ALERT($s) // the value entered into the text area > > Keith - CDI > >> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech >> <4d_tech@lists.4d.com> wrote: >> >> I don’t wish to imply that I ‘prefer’ pointers; in fact, I am not using a >> single process variable, interprocess variable, or any other ‘vestiges’ of >> 4D Classic. I am ‘fully committed’ to object notation. I also use Storage >> extensively for system-wide values, and really love it. >> The problem I describe is that I need a way to generically ‘get’ and ’set’ >> the value of an object (meaning an entry variable on the form). >> >> 1) A variable is placed on the form. It’s “variable or expression” is: >> Form.LB.Browser_JobForms.en_edit.RigFrom. It has an object name of >> “enLSDFromRigDispatch” >> >> I have given it this name because it gives me a simple methodology to >> SHOW/HIDE a whole group of objects on the screen with OBJECT SET >> VISIBLE(*; “enLSD@“;…) >> >> Now I wish to use a standard project method to ‘pretty-format’ this variable. >> With ‘4D Classic’ this is easily achieved by making a project method that >> takes a POINTER in $1. >> The OBJECT SCRIPT would be something simple, like: >> PRETTY_FORMAT(Self) >> [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of >> the variable and do any formatting options needed] >> >> With ‘4D DOT NOTATION’ … >> — How do I create a simple OBJECT SCRIPT that would do something >> similar to that in 4D Classic? — I don’t feel that I should have to resort >> to using the ‘variable or expression’ name in every single script; because >> what happens if I change that variable for some reason and it totally screws >> up the object script? And it also makes it very complicated. >> THE OBJECT METHOD should be something as simple as: >> PRETTY_FORMAT ( Object Get Name )—— instead of Self >> >> The PRETTY_FORMAT( ) should be able to get at and set the value of the form >> object from that name. >> >> Alternatively, if one wants to not bother having scripts for every input >> variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD: >> Case of >> :( Form event code = on load ) >> Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 >> ) … // objects that need to be ‘Pretty Formatted' >> >> : ( Form event code = on losing focus ) >> $curObjectName:= Form Event.objectName >> … see if is in the list of .col_toPrettyFormat … >> PRETTY_FORMAT( $curObjectName ) >> >> … >> >> So how would one implement something like: >> PRETTY FORMAT ( Object Get Name ) in a script; or PRETTY FORMAT ( >> Form Event.objectName ) >> ??? >> >> Thanks, >> Chris >> >> p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create >> classes. That is very intriguing and a necessary development in 4D, as is >> C_VARIANT( ). >> If one wanted to be able to have the script be: >> >> (Object get name).prettyFormatHow would that be achieved? >> >> Even if in the script one could use “This”, but it is null. >> I think that ’This’ should be perfectly valid to use in an OBJECT SCRIPT, in >> a TRIGGER (referring to the record/entity being operated on), etc. But it is >> not, and I have trouble understanding why not. >> >> >> >> >>> On Apr 29, 2020, at 10:14 AM, Keisuke Miyako via 4D_Tech >>> <4d_tech@lists.4d.com> wrote: >>> >>> my feeling is that generic coding is very much possible in object >>> notation, but we need to accept that the approach is different. >>> >>> if you prefer to use pointers such as "Self", I think it's best to >>> avoid object notation, at least if your goal is to make the code >>> generic. >>>
RE: Object notation replacement for use of Self in a script — v18
Did you actually test this?, any kind of a get pointer on a form object having a dot notation source will return a Nil pointer, regardless of the name matching or not. If you are using matched names, you could use the following: Form[Object get name(object current)]:=DoWhatever(Form[Object get name(object current)]) But that is not quite what we need to be truly generic Lahav -Original Message- From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via 4D_Tech Sent: Thursday, April 30, 2020 2:29 PM To: 4D iNug Technical <4d_tech@lists.4d.com> Cc: kculotta Subject: Re: Object notation replacement for use of Self in a script — v18 This example does not avoid having to carefully name form objects and the form object must have "matching" variable and object names: variable entity.MyName with its object name of "MyName" // the object method a_test (OBJECT Get name(Object current)) // a_Test $ent:=OBJECT Get pointer(Object named;$1)-> $s:=$ent[$1] ALERT($s) // the value entered into the text area Keith - CDI > On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > I don’t wish to imply that I ‘prefer’ pointers; in fact, I am not using a > single process variable, interprocess variable, or any other ‘vestiges’ of 4D > Classic. I am ‘fully committed’ to object notation. I also use Storage > extensively for system-wide values, and really love it. > The problem I describe is that I need a way to generically ‘get’ and ’set’ > the value of an object (meaning an entry variable on the form). > > 1) A variable is placed on the form. It’s “variable or expression” is: > Form.LB.Browser_JobForms.en_edit.RigFrom. It has an object name of > “enLSDFromRigDispatch” > > I have given it this name because it gives me a simple methodology to > SHOW/HIDE a whole group of objects on the screen with OBJECT SET > VISIBLE(*; “enLSD@“;…) > > Now I wish to use a standard project method to ‘pretty-format’ this variable. > With ‘4D Classic’ this is easily achieved by making a project method that > takes a POINTER in $1. > The OBJECT SCRIPT would be something simple, like: > PRETTY_FORMAT(Self) > [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of > the variable and do any formatting options needed] > > With ‘4D DOT NOTATION’ … > — How do I create a simple OBJECT SCRIPT that would do something > similar to that in 4D Classic? — I don’t feel that I should have to resort > to using the ‘variable or expression’ name in every single script; because > what happens if I change that variable for some reason and it totally screws > up the object script? And it also makes it very complicated. > THE OBJECT METHOD should be something as simple as: > PRETTY_FORMAT ( Object Get Name )—— instead of Self > > The PRETTY_FORMAT( ) should be able to get at and set the value of the form > object from that name. > > Alternatively, if one wants to not bother having scripts for every input > variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD: > Case of > :( Form event code = on load ) > Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 > ) … // objects that need to be ‘Pretty Formatted' > > : ( Form event code = on losing focus ) > $curObjectName:= Form Event.objectName > … see if is in the list of .col_toPrettyFormat … > PRETTY_FORMAT( $curObjectName ) > > … > > So how would one implement something like: > PRETTY FORMAT ( Object Get Name ) in a script; or PRETTY FORMAT ( > Form Event.objectName ) > ??? > > Thanks, > Chris > > p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create > classes. That is very intriguing and a necessary development in 4D, as is > C_VARIANT( ). > If one wanted to be able to have the script be: > > (Object get name).prettyFormatHow would that be achieved? > > Even if in the script one could use “This”, but it is null. > I think that ’This’ should be perfectly valid to use in an OBJECT SCRIPT, in > a TRIGGER (referring to the record/entity being operated on), etc. But it is > not, and I have trouble understanding why not. > > > > >> On Apr 29, 2020, at 10:14 AM, Keisuke Miyako via 4D_Tech >> <4d_tech@lists.4d.com> wrote: >> >> my feeling is that generic coding is very much possible in object >> notation, but we need to accept that the approach is different. >> >> if you prefer to use pointers such as "Self", I think it's best to >> avoid object notation, at least if your goal is to make the code >> generic. >> >> it's not a defect of object notation, but the way to write generic >> code is different. >> >> if you want to make your code generic in object notation, I think you >> need to fully commit. >> >> what I mean by that, is that you need to think of objects and classes, >> properties and methods. >> >> basically, instead of >> >> doIt(Self) >> >> you would write >> >>
Re: Object notation replacement for use of Self in a script — v18
Is there a "Get edited text without having to type anything first" kind of function. Does an entry area have an Object that contains its type and contents? > On Apr 30, 2020, at 2:58 PM, Chris Belanger via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > Exactly … that is my question. — Chris > >> On Apr 29, 2020, at 11:15 AM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: >> >> OK, so can we get a real example of how to replace the *old* way with the >> new? In a case where there are several entry objects: >> >> Form.Name >> Form.Address >> Form.Note >> >> I want to enforce a proper uppercase/lowercase on all three, so in the old >> days I created an object, set the method to "UpperLower(self)", duplicated >> it three times, change the object name and I'm done. For simplicity sake, >> lets say that UpperLower simply do $1->:=Uppercase($1->). >> >> How would you do the same while using object notation instead of a variable, >> dynamic or not? >> >> Thanks, >> >> Lahav >> >> >> -Original Message- >> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Keisuke Miyako via >> 4D_Tech >> Sent: Wednesday, April 29, 2020 10:14 AM >> To: 4D iNug Technical <4d_tech@lists.4d.com> >> Cc: Keisuke Miyako >> Subject: Re: Object notation replacement for use of Self in a script — v18 >> >> my feeling is that generic coding is very much possible in object notation, >> but we need to accept that the approach is different. >> >> if you prefer to use pointers such as "Self", I think it's best to avoid >> object notation, at least if your goal is to make the code generic. >> >> it's not a defect of object notation, >> but the way to write generic code is different. >> >> if you want to make your code generic in object notation, I think you need >> to fully commit. >> >> what I mean by that, is that you need to think of objects and classes, >> properties and methods. >> >> basically, instead of >> >> doIt(Self) >> >> you would write >> >> $obj.doIt() >> >> where the doIt() formula works on "This". >> >> in my opinion, to take full advantage of object notation, it is pretty much >> mandatory to use >> >> This >> Signal >> Formula >> Form >> >> extensively, as well as >> >> Storage >> New shared object >> New shared collection >> >> strategically. >> >> simply replacing interprocess/process variables with object notation, may >> semantically look like object based coding, but at that level you may be >> losing major advantages of classic code, while not gaining much from what >> the new way of coding has to offer. >> >>> On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech >>> <4d_tech@lists.4d.com> wrote: >>> And v18r3 does not even have a solution to this in its documentation. >> >> ** >> 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 > ** ** 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 **
Re: Object notation replacement for use of Self in a script — v18
This example does not avoid having to carefully name form objects and the form object must have "matching" variable and object names: variable entity.MyName with its object name of "MyName" // the object method a_test (OBJECT Get name(Object current)) // a_Test $ent:=OBJECT Get pointer(Object named;$1)-> $s:=$ent[$1] ALERT($s) // the value entered into the text area Keith - CDI > On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > I don’t wish to imply that I ‘prefer’ pointers; in fact, I am not using a > single process variable, interprocess variable, or any other ‘vestiges’ of 4D > Classic. I am ‘fully committed’ to object notation. I also use Storage > extensively for system-wide values, and really love it. > The problem I describe is that I need a way to generically ‘get’ and ’set’ > the value of an object (meaning an entry variable on the form). > > 1) A variable is placed on the form. It’s “variable or expression” is: > Form.LB.Browser_JobForms.en_edit.RigFrom. It has an object name of > “enLSDFromRigDispatch” > > I have given it this name because it gives me a simple methodology to > SHOW/HIDE a whole group of objects on the screen with OBJECT SET VISIBLE(*; > “enLSD@“;…) > > Now I wish to use a standard project method to ‘pretty-format’ this variable. > With ‘4D Classic’ this is easily achieved by making a project method that > takes a POINTER in $1. > The OBJECT SCRIPT would be something simple, like: > PRETTY_FORMAT(Self) > [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of the > variable and do any formatting options needed] > > With ‘4D DOT NOTATION’ … > — How do I create a simple OBJECT SCRIPT that would do something similar to > that in 4D Classic? — > I don’t feel that I should have to resort to using the ‘variable or > expression’ name in every single script; because what happens if I change > that variable for some reason and it totally screws up the object script? And > it also makes it very complicated. > THE OBJECT METHOD should be something as simple as: > PRETTY_FORMAT ( Object Get Name )—— instead of Self > > The PRETTY_FORMAT( ) should be able to get at and set the value of the form > object from that name. > > Alternatively, if one wants to not bother having scripts for every input > variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD: > Case of > :( Form event code = on load ) > Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 > ) … // objects that need to be ‘Pretty Formatted' > > : ( Form event code = on losing focus ) > $curObjectName:= Form Event.objectName > … see if is in the list of .col_toPrettyFormat … > PRETTY_FORMAT( $curObjectName ) > > … > > So how would one implement something like: > PRETTY FORMAT ( Object Get Name ) in a script; or PRETTY FORMAT ( > Form Event.objectName ) > ??? > > Thanks, > Chris > > p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create > classes. That is very intriguing and a necessary development in 4D, as is > C_VARIANT( ). > If one wanted to be able to have the script be: > > (Object get name).prettyFormatHow would that be achieved? > > Even if in the script one could use “This”, but it is null. > I think that ’This’ should be perfectly valid to use in an OBJECT SCRIPT, in > a TRIGGER (referring to the record/entity being operated on), etc. But it is > not, and I have trouble understanding why not. > > > > >> On Apr 29, 2020, at 10:14 AM, Keisuke Miyako via 4D_Tech >> <4d_tech@lists.4d.com> wrote: >> >> my feeling is that generic coding is very much possible in object notation, >> but we need to accept that the approach is different. >> >> if you prefer to use pointers such as "Self", >> I think it's best to avoid object notation, >> at least if your goal is to make the code generic. >> >> it's not a defect of object notation, >> but the way to write generic code is different. >> >> if you want to make your code generic in object notation, >> I think you need to fully commit. >> >> what I mean by that, is that you need to think of objects and classes, >> properties and methods. >> >> basically, instead of >> >> doIt(Self) >> >> you would write >> >> $obj.doIt() >> >> where the doIt() formula works on "This". >> >> in my opinion, to take full advantage of object notation, >> it is pretty much mandatory to use >> >> This >> Signal >> Formula >> Form >> >> extensively, as well as >> >> Storage >> New shared object >> New shared collection >> >> strategically. >> >> simply replacing interprocess/process variables with object notation, >> may semantically look like object based coding, >> but at that level you may be losing major advantages of classic code, >> while not gaining much from what the new way of coding has to offer. >> >>> On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech >>>
Re: Object notation replacement for use of Self in a script — v18
Exactly … that is my question. — Chris > On Apr 29, 2020, at 11:15 AM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote: > > OK, so can we get a real example of how to replace the *old* way with the > new? In a case where there are several entry objects: > > Form.Name > Form.Address > Form.Note > > I want to enforce a proper uppercase/lowercase on all three, so in the old > days I created an object, set the method to "UpperLower(self)", duplicated it > three times, change the object name and I'm done. For simplicity sake, lets > say that UpperLower simply do $1->:=Uppercase($1->). > > How would you do the same while using object notation instead of a variable, > dynamic or not? > > Thanks, > > Lahav > > > -Original Message- > From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Keisuke Miyako via > 4D_Tech > Sent: Wednesday, April 29, 2020 10:14 AM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: Keisuke Miyako > Subject: Re: Object notation replacement for use of Self in a script — v18 > > my feeling is that generic coding is very much possible in object notation, > but we need to accept that the approach is different. > > if you prefer to use pointers such as "Self", I think it's best to avoid > object notation, at least if your goal is to make the code generic. > > it's not a defect of object notation, > but the way to write generic code is different. > > if you want to make your code generic in object notation, I think you need to > fully commit. > > what I mean by that, is that you need to think of objects and classes, > properties and methods. > > basically, instead of > > doIt(Self) > > you would write > > $obj.doIt() > > where the doIt() formula works on "This". > > in my opinion, to take full advantage of object notation, it is pretty much > mandatory to use > > This > Signal > Formula > Form > > extensively, as well as > > Storage > New shared object > New shared collection > > strategically. > > simply replacing interprocess/process variables with object notation, may > semantically look like object based coding, but at that level you may be > losing major advantages of classic code, while not gaining much from what the > new way of coding has to offer. > >> On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> >> wrote: >> And v18r3 does not even have a solution to this in its documentation. > > ** > 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 **
Re: Object notation replacement for use of Self in a script — v18
I don’t wish to imply that I ‘prefer’ pointers; in fact, I am not using a single process variable, interprocess variable, or any other ‘vestiges’ of 4D Classic. I am ‘fully committed’ to object notation. I also use Storage extensively for system-wide values, and really love it. The problem I describe is that I need a way to generically ‘get’ and ’set’ the value of an object (meaning an entry variable on the form). 1) A variable is placed on the form. It’s “variable or expression” is: Form.LB.Browser_JobForms.en_edit.RigFrom. It has an object name of “enLSDFromRigDispatch” I have given it this name because it gives me a simple methodology to SHOW/HIDE a whole group of objects on the screen with OBJECT SET VISIBLE(*; “enLSD@“;…) Now I wish to use a standard project method to ‘pretty-format’ this variable. With ‘4D Classic’ this is easily achieved by making a project method that takes a POINTER in $1. The OBJECT SCRIPT would be something simple, like: PRETTY_FORMAT(Self) [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of the variable and do any formatting options needed] With ‘4D DOT NOTATION’ … — How do I create a simple OBJECT SCRIPT that would do something similar to that in 4D Classic? — I don’t feel that I should have to resort to using the ‘variable or expression’ name in every single script; because what happens if I change that variable for some reason and it totally screws up the object script? And it also makes it very complicated. THE OBJECT METHOD should be something as simple as: PRETTY_FORMAT ( Object Get Name )—— instead of Self The PRETTY_FORMAT( ) should be able to get at and set the value of the form object from that name. Alternatively, if one wants to not bother having scripts for every input variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD: Case of :( Form event code = on load ) Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 ) … // objects that need to be ‘Pretty Formatted' : ( Form event code = on losing focus ) $curObjectName:= Form Event.objectName … see if is in the list of .col_toPrettyFormat … PRETTY_FORMAT( $curObjectName ) … So how would one implement something like: PRETTY FORMAT ( Object Get Name ) in a script; or PRETTY FORMAT ( Form Event.objectName ) ??? Thanks, Chris p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create classes. That is very intriguing and a necessary development in 4D, as is C_VARIANT( ). If one wanted to be able to have the script be: (Object get name).prettyFormatHow would that be achieved? Even if in the script one could use “This”, but it is null. I think that ’This’ should be perfectly valid to use in an OBJECT SCRIPT, in a TRIGGER (referring to the record/entity being operated on), etc. But it is not, and I have trouble understanding why not. > On Apr 29, 2020, at 10:14 AM, Keisuke Miyako via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > my feeling is that generic coding is very much possible in object notation, > but we need to accept that the approach is different. > > if you prefer to use pointers such as "Self", > I think it's best to avoid object notation, > at least if your goal is to make the code generic. > > it's not a defect of object notation, > but the way to write generic code is different. > > if you want to make your code generic in object notation, > I think you need to fully commit. > > what I mean by that, is that you need to think of objects and classes, > properties and methods. > > basically, instead of > > doIt(Self) > > you would write > > $obj.doIt() > > where the doIt() formula works on "This". > > in my opinion, to take full advantage of object notation, > it is pretty much mandatory to use > > This > Signal > Formula > Form > > extensively, as well as > > Storage > New shared object > New shared collection > > strategically. > > simply replacing interprocess/process variables with object notation, > may semantically look like object based coding, > but at that level you may be losing major advantages of classic code, > while not gaining much from what the new way of coding has to offer. > >> On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> >> wrote: >> And v18r3 does not even have a solution to this in its documentation. > > ** > 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:
Re: Object notation replacement for use of Self in a script — v18
I drank deeply from the “dynamic variables” Koolaid well with the release of V12. As soon as I started working with Form.foo, I ran headlong into the issue described above. The email thread "One Set of Code for Form Object Populated Forms as well as Field-Based Detail View Forms” may shed some light on the topic. -- Douglas von Roeder 949-910-4084 On Wed, Apr 29, 2020 at 10:15 AM lists via 4D_Tech <4d_tech@lists.4d.com> wrote: > OK, so can we get a real example of how to replace the *old* way with the > new? In a case where there are several entry objects: > > Form.Name > Form.Address > Form.Note > > I want to enforce a proper uppercase/lowercase on all three, so in the old > days I created an object, set the method to "UpperLower(self)", duplicated > it three times, change the object name and I'm done. For simplicity sake, > lets say that UpperLower simply do $1->:=Uppercase($1->). > > How would you do the same while using object notation instead of a > variable, dynamic or not? > > Thanks, > > Lahav > > > -Original Message- > From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Keisuke Miyako > via 4D_Tech > Sent: Wednesday, April 29, 2020 10:14 AM > To: 4D iNug Technical <4d_tech@lists.4d.com> > Cc: Keisuke Miyako > Subject: Re: Object notation replacement for use of Self in a script — v18 > > my feeling is that generic coding is very much possible in object > notation, but we need to accept that the approach is different. > > if you prefer to use pointers such as "Self", I think it's best to avoid > object notation, at least if your goal is to make the code generic. > > it's not a defect of object notation, > but the way to write generic code is different. > > if you want to make your code generic in object notation, I think you need > to fully commit. > > what I mean by that, is that you need to think of objects and classes, > properties and methods. > > basically, instead of > > doIt(Self) > > you would write > > $obj.doIt() > > where the doIt() formula works on "This". > > in my opinion, to take full advantage of object notation, it is pretty > much mandatory to use > > This > Signal > Formula > Form > > extensively, as well as > > Storage > New shared object > New shared collection > > strategically. > > simply replacing interprocess/process variables with object notation, may > semantically look like object based coding, but at that level you may be > losing major advantages of classic code, while not gaining much from what > the new way of coding has to offer. > > > On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > > And v18r3 does not even have a solution to this in its documentation. > > ** > 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 **
RE: Object notation replacement for use of Self in a script — v18
OK, so can we get a real example of how to replace the *old* way with the new? In a case where there are several entry objects: Form.Name Form.Address Form.Note I want to enforce a proper uppercase/lowercase on all three, so in the old days I created an object, set the method to "UpperLower(self)", duplicated it three times, change the object name and I'm done. For simplicity sake, lets say that UpperLower simply do $1->:=Uppercase($1->). How would you do the same while using object notation instead of a variable, dynamic or not? Thanks, Lahav -Original Message- From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Keisuke Miyako via 4D_Tech Sent: Wednesday, April 29, 2020 10:14 AM To: 4D iNug Technical <4d_tech@lists.4d.com> Cc: Keisuke Miyako Subject: Re: Object notation replacement for use of Self in a script — v18 my feeling is that generic coding is very much possible in object notation, but we need to accept that the approach is different. if you prefer to use pointers such as "Self", I think it's best to avoid object notation, at least if your goal is to make the code generic. it's not a defect of object notation, but the way to write generic code is different. if you want to make your code generic in object notation, I think you need to fully commit. what I mean by that, is that you need to think of objects and classes, properties and methods. basically, instead of doIt(Self) you would write $obj.doIt() where the doIt() formula works on "This". in my opinion, to take full advantage of object notation, it is pretty much mandatory to use This Signal Formula Form extensively, as well as Storage New shared object New shared collection strategically. simply replacing interprocess/process variables with object notation, may semantically look like object based coding, but at that level you may be losing major advantages of classic code, while not gaining much from what the new way of coding has to offer. > On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> > wrote: > And v18r3 does not even have a solution to this in its documentation. ** 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 **
Re: Object notation replacement for use of Self in a script — v18
my feeling is that generic coding is very much possible in object notation, but we need to accept that the approach is different. if you prefer to use pointers such as "Self", I think it's best to avoid object notation, at least if your goal is to make the code generic. it's not a defect of object notation, but the way to write generic code is different. if you want to make your code generic in object notation, I think you need to fully commit. what I mean by that, is that you need to think of objects and classes, properties and methods. basically, instead of doIt(Self) you would write $obj.doIt() where the doIt() formula works on "This". in my opinion, to take full advantage of object notation, it is pretty much mandatory to use This Signal Formula Form extensively, as well as Storage New shared object New shared collection strategically. simply replacing interprocess/process variables with object notation, may semantically look like object based coding, but at that level you may be losing major advantages of classic code, while not gaining much from what the new way of coding has to offer. > On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> > wrote: > And v18r3 does not even have a solution to this in its documentation. ** 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 **
Re: Object notation replacement for use of Self in a script — v18
*OBJECT Get pointer*(Object named;"")
does return the Form object.
If you standardise your naming convention of the form field objects you
could determine the sub object and attribute you're looking for.
example:
FormObj_Wrap_Trim("en_company";"name")
FormObj_Wrap_Trim:
$vT_Object:=*$1*
$vT_Attrib:=*$2*
$vT_FormObjName:=$vT_Object+"_"+$vT_Attrib
$vP_Field:=*OBJECT Get pointer*(Object named;$vT_FormObjName)
Trim($vP_Field->[$vT_Object][$vT_Attrib])
this will get you Form.en_company.name
As I don't know what you have in Trim I'll just leave it as is.
Adam Bevan
On Wed, 29 Apr 2020 at 15:53, 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).
>
> But with OBJECT NOTATION, that is all screwed up.
> You cannot get a PTR to, for instance, an object named ‘enCompany’ whose
> data source is Form.en_Company.Name
> So the script for it cannot be generic.
> It would seem to make sense to be able to do something like:
>
> TRIM ( Form Event.objectName ) — and have some way to actually do anything
> with what the user typed into this element on-screen.
>
> You can’t use TRIM ( Self ) because Self is nil
>
> And v18r3 does not even have a solution to this in its documentation.
>
> It seems we should have some way of getting the user-input data of a
> screen element even if we are using object notation.
>
> We would expect, at the least, something like OBJECT Get Value (
> ObjectName ) and OBJECT Set Value ( Object Name ) but no!
>
> Any input? Wait for version 20 of 4D?
>
> - Chris
> **
> 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
**
Re: Object notation replacement for use of Self in a script — v18
quite simple actually, just get a pointer to the actual form element in the object method just call: OBJECT GET POINTER (object current) you can even go one further und just put all that into the form method: If (Form event code=On Data Change) $p_entry:=OBJECT Get pointer(Object with focus) If ((Type($p_entry)=Is text) | (Type($p_entry)=Is alpha field)) $p_entry->:=Trim($p_entry->) End if End if careful here, you will need to switch to OBJECT GET POINTER(Object with focus) as you are not in the objects method anymore... HTH Alex > Am 29.04.2020 um 07:55 schrieb Chris Belanger via 4D_Tech > <4d_tech@lists.4d.com>: > > 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). > > But with OBJECT NOTATION, that is all screwed up. > You cannot get a PTR to, for instance, an object named ‘enCompany’ whose data > source is Form.en_Company.Name > So the script for it cannot be generic. > It would seem to make sense to be able to do something like: > > TRIM ( Form Event.objectName ) — and have some way to actually do anything > with what the user typed into this element on-screen. > > You can’t use TRIM ( Self ) because Self is nil > > And v18r3 does not even have a solution to this in its documentation. > > It seems we should have some way of getting the user-input data of a screen > element even if we are using object notation. > > We would expect, at the least, something like OBJECT Get Value ( ObjectName > ) and OBJECT Set Value ( Object Name ) but no! > > Any input? Wait for version 20 of 4D? > > - Chris > ** > 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 **
Object notation replacement for use of Self in a script — v18
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). But with OBJECT NOTATION, that is all screwed up. You cannot get a PTR to, for instance, an object named ‘enCompany’ whose data source is Form.en_Company.Name So the script for it cannot be generic. It would seem to make sense to be able to do something like: TRIM ( Form Event.objectName ) — and have some way to actually do anything with what the user typed into this element on-screen. You can’t use TRIM ( Self ) because Self is nil And v18r3 does not even have a solution to this in its documentation. It seems we should have some way of getting the user-input data of a screen element even if we are using object notation. We would expect, at the least, something like OBJECT Get Value ( ObjectName ) and OBJECT Set Value ( Object Name ) but no! Any input? Wait for version 20 of 4D? - Chris ** 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 **
