Greetings Kirk,
I have been programming in 4D since version 2 back in the early 1990’s. Though
v14 was possibly going to become the end of my ‘career’ with 4D. And then v17
came out with ORDA. I love it.
I have a fresh enthusiasm for 4D again.
I am using 4D v17r4; getting right up-to-speed on orda and the use of objects
and . notation. Programming is so exciting now with 4D. Can’t wait for all the
new features coming up and love the ’scaled’ approach of 4D now.
I have been exploring the features you referred to and appreciate the methods
you discussed, including the use of a ‘form controller’ method.
I love the new DIALOG ( form object) approach and agree with your suggestions.
It makes everything so much simpler. I am trying to progressively get a
collection of useful forms of that nature.
Regarding Classic; I am trying to divest myself of all need to use it. For the
very reasons you express too. In fact, my current 2 projects I have made the
design decision to ’throw out’ all the classic coding I formerly used and make
a new development methodology solidly founded on the new 4D features, including
ORDA.
I am simultaneously **finally** working on also making a component at the same
time to store code I will want to use in new projects.
And I finally found out how to make CONSTANTS with 4D POP; something I should
have done a long time ago instead of using <>Constant approach.
INTERPROCESS VARIABLES? Turfing them.
Storage. ? putting key data into that instead using interprocess vars.
Process variables? Form. object is where it’s at now. That is probably my
favorite new feature: Form.[objects] is a game-changer for me. It makes
everything so much simpler. I tie everything into that object now. I don’t have
a single process variable in my new projects.
Objects? I created a ‘class definition’ -> ‘object creation’ form {called UI
DESIGNER} by which I can define new CLASSes and then create OBJECTS based on
those classes. I find this helpful in may aspects: I can set up static and
dynamic choiceLists and pop menus and system menus; they are PRIVILEGE-enabled
in that I can specify what privilege a user must have to see/use the object,
etc..
I set up a class type I call ‘ordaList’ that I use to specify the data class,
selection method, ordering, etc. for what becomes a hierarchical list
maintained within STORAGE.
I have another CLASS for sysMenu that replaces the menu editor in 4D; and a
number of other UI - related classes.
I managed to do this with two tables: [UIClass] and [UIObjects].
Menus? These are now going to be ‘OBJECTS’ defined through the above mechanism,
and I will not use any MENU BAR( ) code again. I found that SET MENU BAR( ) had
been very buggy anyway.
SubForms? I avoided these for years; but now I am getting into them. My UI
DESIGNER makes excellent use of subforms now. I really need to get to
understand their proper use.
I experimented with DYNAMIC FORMS: it was pretty neat how in one of my ‘old’
CLASSIC-based programs, I mocked up a form by which I could select a ‘Classic’
form (from a listbox of them) and poof! Instantly it was recreated in a subform
using a dynamic form. It will take me a while to fully grasp how to use these
most effectively.
Using OBJECTS to exchange data is an excellent option; I wish all 4D commands
supported that (and that the ones that use ARRAYS would also use COLLECTIONS
instead). But that is probably coming.
the For each … end For Each is awesome; I love split string( ).
it is exciting to come across someone else who is embracing the new programming
techniques and from whom I could learn a lot. Thank you for sharing your tips.
I am actually currently trying to make a design decision on how to handle
addresses — I think using an object field is a very intriguing idea. I was also
wondering about that for phone numbers too.
——
to pass on something that may be useful to you in return:
I had been frustrated at how ComboBoxes and popMenus store a VALUE and not the
REFERENCE (array[0]). I thereafter realized that using a CHOICE LIST for the
object is ideal.
For example, say that the form needs to have a CUSTOMER combobox and the
customer’s ID needs to be stored into an Invoice.Customer field to create the
relational link.
I create a hierarchical list [choice list] (ordaList) that has CUSTOMER
NAME:KEY [for value:itemRef in the hierarchical list].
Then I assign that as a choice list to the combo object using OBJECT SET LIST
BY REFERENCE( ).
I have a method cboxDo put into the object’s script that clairvoyantly lets the
user type in the customer name, and the KEY automatically gets updated into
Invoice.Customer field as they enter it.
So to set this up, naturally it just requires a couple parameters to tell 4D
how to manage it for any given situation.
— chris
> On Apr 25, 2019, at 11:15 AM, Kirk Brooks via 4D_Tech <[email protected]>
> wrote:
>
> 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]
> **********************************************************************
**********************************************************************
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]
**********************************************************************
