Kirk,
Hi. Thanks for that lengthy response! You make a lot of useful points in
regards to v17 for sure and in fact I have already been reading up and
digesting the implications of the new ways of working in 4D, particularly Form
and ORDA. And yes, it totally makes sense to re-think ones approach for future
new 4D development.
Of course re-factoring legacy code is a rare opportunity with the vast majority
of clients due to cost implications regardless of the benefits so lots of that
code will stick around for years to come!
As ever, learning to wield the new features in 4D by experimenting is the order
of the day.
Regards,
Narinder Chandi,
ToolBox Systems Ltd.
--
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.
**********************************************************************
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]
**********************************************************************
