Chris,
Thanks for the insight. It sounds like you are working with classic 4D code
(even if you're using v17). Let me encourage you to think about re-writing
your form using v17. I think most of the issues requiring elaborate
workarounds won't be necessary.
Positioning objects on the form. You mention this - that until the entire
On Load form event runs you don't know the final position of objects. This
can especially be a headache if you have subforms and a real headache if
you have nested subforms. The situation can be helped quite a bit by using
a 'form controller': a project method called by all the objects of a form.
I've talked about this a lot and done some presentations on it. It helps
manage complex forms in situations like this. Having all the objects
reference a single method makes managing them easier and helps keep clear
the order of execution:
subform objects -> subform -> parent form objects -> parent form
It's easy to forget the parent form's On Load event is actually the last
one to run. This has not changed.
For constructing and displaying complex forms the new Form function coupled
with Dialog is incredibly powerful. To begin with, you can build your data
object prior to even opening the form. If you have array or selection based
listboxes these are replaced with collection based listboxes - referring to
either data collections or entity selections. This change alone can prune
dozens of lines of code because so little code is required to manage them.
But you can setup all that data prior to displaying the form and then pass
that data object to the form using Dialog:
DIALOG("myForm";$dataObject)
This will populate the Form function with $dataObject.
Previously if you had a complex situation the form objects or subforms
might call code to configure themselves. And sometimes this had to follow a
specific order during On Load. I'm saying that's no longer necessary. All
the data assembly can be done at once and stored in Form or some other
variable, though Form is more modular and generic. With that scenario it
doesn't matter when or in what order form objects, including subforms, are
drawn.
The second new feature may be too new to actually use but I encourage you
to look at what you can do with it and that's Dynamic Forms. Jsut for
starters you have complete control over drawing a listbox. Complete. Have a
listbx you like? Use the FORM Convert to dynamic command to get the code -
which you can just paste in.
On Wed, Apr 24, 2019 at 9:37 PM Chris Belanger via 4D_Tech <
[email protected]> wrote:
> I prefer to reduce the number of Project Methods while, of course,
> creating ones that make logical sense (as they can be called in several
> places in my code). But you understand that as a programmer.
>
I agree with not creating project methods without good cause. But there's
no downside to creating them when needed. Indeed, ORDA encourages us to
create methods for queries and such. Though a lot of the examples of this
in the docs are totally specific it's not hard to make those method more
generic.
And having worked a lot with addresses I don't find very much about them
trivial. Looking at your example as a basic principle responses to user
actions are handled by various events. Assuming the address object or
entity is in Form:
Form: {
address:{
City:"San Francisco"
Provence:"CA",
postalCode: "94114",
cityLine: "San Francisco, CA, 94114"
}
}
The input fields will refer to:
Form.address.City
Form.address.Provence
Form.address.postalCode and so on
and fire On data change. I have, and suspect you do too, a method to
normalize and format my address objects. So I only need to pass the address
object to it for all the work to be done. So the On data change code is:
Adrs_configure_obj (Form.address)
Adrs_configure_obj does all the work on the object. Since I pass
Form.address that is the object the method updates. And since I'm using
Form and referencing it in the form inputs they update as well. I don't
have to do anything else.
This aspect of working with objects, that you can pass the object to a
method and the method changes the object is quite powerful. Previously we
accomplished this with pointers to variables. It's a similar concept but
actually much more dynamic. And faster. When I call, Adrs_configure_obj
(Form.address), the method doesn't get a copy of the data, it gets a
reference to the data. Form.address is itself a reference to the data. The
data, entity or object, is managed by 4D. So this is both fast and resource
efficient.
I have played with the new Formula command myself. I haven't found any
really compelling uses for it in my work yet. I see it as an indication of
more changes to come, though. Like actual data classes where the
transformations I just talked about are part of the dataclass instead of a
separate method. But that's probably v18R stuff.
Hope this gives you some ideas to play with.
--
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]
**********************************************************************
