Jody, Nice post. I've also implemented several of these ideas but you're really going more deeply than I have. My motivation didn't have anything to do with bleed through. They came about as I was working more and more with objects and dynamic variables.
On Sat, Jun 17, 2017 at 2:35 PM, Jody Bevan via 4D_Tech < 4d_tech@lists.4d.com> wrote: > 1. On all forms we never use variables. > Assuming you're talking about process variables. I agree mostly but there are some times when they are still useful. Most recently as a dataChanged flag. But that could be stored in the process object you touch on later. > > 2. We have a generic form that has several objects on it. At runtime we > will make objects visible or not, and change their titles, positions, etc. > This permits us to have one form that handles Alerts, Requests, and > Confirms. We provide more features than that with these dialogs (like help > buttons, trace, etc). This means this dialog gets used extensively. > I've played with this idea a bit too. Could you talk more about what kinds of forms or records you're using this for? They are easy enough to implement in concept but to make them look nice and such has been a challenge for me. 4. Dialogs that a process call up though will need to get the input from > the user. We accomplish this through an object we call our Process Object. > Inside the process object a object is created for every running process. > When a form is opened within the process an object is created for that > form. When a dialog is opened an object is created within that form object. > There we set what all the dialog objects are to be, and we also return the > results from the user input. The form that called the dialog gets the > information it is looking for from this object. Once the information is > obtained that dialog object is deleted from memory. > I caught a lot of flak last year when I suggested process variables had become passe in favor of a single process object for managing the random bits of information they are usually used for. I must admit I hadn't thought about this approach. I like it. The form becomes more like a reflection of the data (stored in the object) instead of the data actually residing on the form. Are you willing to talk about how you manage the fields and data in the process object? This opens up a lot of options for things like inherited forms too as I think of it. Instead of having different inherited forms in different sizes there can be one and the objects simply sized as appropriate. > > It seems complex and it would be if we had to write the code each time. We > have written nice generic methods for its use. We also created macros as we > do for all this stuff that makes it very quick to build a request dialog > (for example) in our code. > What are some examples of the generic form methods you are using? You know, this also allows for you to create a hell of an error log - you could write the process object to the error record in addition to the other stuff. -- Kirk Brooks San Francisco, CA ======================= *The only thing necessary for the triumph of evil is for good men to do nothing.* *- Edmund Burke* ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
