Hi Narinder, I have some thoughts. To start, with v17 the whole concept of what a form is in 4D is fundamentally different. I'm talking about building new forms, here, not tweaking existing ones. One important change is ditching process variables as form elements. Just stop. Buttons, fields, variables, and so forth do not need to be in process variables any longer. In fact using them becomes a liability if you attempt to use the new DIALOG(*) command. And you should be using this because unlike our previous best-practice of opening new windows in new processes the thinking now is to have few, like 1, process for displaying data and opening multiple windows as needed within that process. I still see a lot of examples coming out of 4D, even 4D technical support, that use this old approach. I think it's old hands still doing what's worked and they are in a hurry. Process vars are just not a good idea on new forms.
But what about the Current Selection and table locking and all? These are not concerns with ORDA. And if you start opening multiple forms in the same process and these forms use process vars for buttons or things the value of all those buttons (but not the Form event) all change each time you change one. So, ditch the process vars on forms. In fact with an ORDA database I rarely have more than a handful of process vars at all. What I do always have is a single object process var and I use this for any process level data that needs to persist. I use this as my own process data-store instead of dozens (hundreds) of distinct vars. A lot of code I look at shows an almost superstitious view of variable handling in 4D that seems to suggest there is a hierarchy of variable stability starting with IP vars (most stable) down to local vars (most volatile). I do not believe that has any basis beyond very old programming habits of 4D devs. But we can probably have another discussion about that topic alone. ;-) The other truly radical change in forms is Form. https://doc.4d.com/4Dv17R5/4D/17-R5/Form.301-4128553.en.html The significance of Form to the way you setup a 4D form can not be overstated. And very little of your understanding of forms from pre v17 programming really applies. It will still work, of course, but using Form and ORDA you can achieve results on a form that would require a lot of coding to manage using 4D classic. Sometimes I sat back after getting something to work and just marveled because the actions were so profound and there was no code - only the setup of the form and the data it worked with. The blog has some good examples. One I studied a lot is here: https://blog.4d.com/multilevel-collection-in-different-listboxes/ But getting back to some specifics of your question, I have argued for a long time about the value of using a 'form controller' method on forms. I put all the code for the form into that project method and include that single method in any form object and the form method. You can identify what object invoked the method using OBJECT get name. It's basically one big Case of statement with each object identified by name with whatever code that object needs. And you can add other actions shared by objects on the form. I still use this on complicated forms but I've noticed much less need for object level code with ORDA. Having a single method is also useful, pretty much required, to take advantage of Dynamic Forms since the 'method' property of a dynamic form only accepts a project method, you can't include code. Dynamic Forms are quite useful. They can be applied to a subform object or a form opened with DIALOG. Managing various complex listboxes, for example, is a lot easier with dynamic forms than building them in code. Faster too. For example, I can design my listboxes in a temporary form and then use FORM Convert to dynamic to get the code for it, save it to a file and then load it into a subform when needed. Switching between various listboxes in the same subform becomes simple. And there is no data loading because the data are already referenced in Form. In classic 4D accomplishing this sort of thing would require large methods to build the listboxes and lots and lots of arrays to manage. And it would be really difficult to change later on. I really encourage you to take advantage of coming back to 4D to approach it as a new environment. Unless you are angling to support old projects don't worry about how we were doing things 15 years ago. Focus on the new stuff and run with it. That's where the platform is headed. And it's just a lot more fun, too. On Thu, Jun 20, 2019 at 7:48 AM Narinder Chandi via 4D_Tech < [email protected]> wrote: > I'm wondering, who out there is still actively developing using selector > methods? > > For a long time now (way back since v6, perhaps even before that...) I > have tended to encapsulate all of my code into Project Methods such that > Form and Object level methods consist of nothing more than a Case...End > Case block of Form Events that then then call an appropriate Project > Method. We all pretty much work at some time or another with legacy code > that usually has no conventions whatsoever. Any new code I add to such a > codebase will follow the selector method convention. > > Do you still adhere to the selector method philosophy or have you moved > onto an alternative 4D programming style? If so, can you describe it and > why you have found it a better approach than selector methods? It's easy to > stick with old ways and not adapt to better approaches so I'm interested to > learn and explore better techniques within 4D. > > One of the reasons I am asking this question is that many years ago there > was the wonderful QuickCode Pro plugin written by Aparajita which sadly > ceased working with 4D v6, I think. As I recall, prior to that Aparajita > had privileged access to the 4D source code to enable QCP to work its magic > but at some point that access was rescinded and QCP sadly reached EOL. QCP > was perfect for navigating selector methods using the Case tool as this > technique often results in large methods. > > With 4D 2003, I started to write my own QCP toolbar replacement using > native 4D, at the time using the DynamicStructure plugin (that too has > disappeared now I think) and some other tricks to read and parse method > source code. With newer versions of 4D some new possibilities have opened > up and I am considering re-visiting this project in theory without needing > to rely on any external plugins. Does anybody already have something like > this that that they have written for their own use? Would anybody be > interested in such a 4D component? > > Thanks for your thoughts and input. > > Regards, > > Narinder Chandi, > ToolBox Systems Ltd. > -- > > > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** -- Kirk Brooks San Francisco, CA ======================= What can be said, can be said clearly, and what you can’t say, you should shut up about *Wittgenstein and the Computer * ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
