Arnaud, It looks like we are doing very similar things.
On Sun, Jan 8, 2017 at 8:26 AM, Arnaud de Montard <[email protected]> wrote: > > • $1, $2…? > before v12, a friend of mine and I used form event as 1st entry point in > our Form managers, and optional pointer on the source object as $2. > There's no need to pass the form event to the method - I can just read it there. The form event may or may not be relevant to whatever 'action' is being run. $1 is optional. without it the default 'action' (what code we need to run) is the name of the object that called it. So the method can be put into any form object. This is so helpful when designing a form and duplicating objects - just changing the object name changes it's 'call' to the form controller. But I can pass a specific 'action' as well. This may have no corollary with a form object per se but be some actions relevant to the form. Loading listboxes, lists, subforms, printing, stuff like that. $2 is included just as a way to occasionally pass more information. > $1=text. In a FM, the "main" code is based on a big Case of. When the > event is used as 1st entry point, parts of code for the same object are > spread in pieces at line x, y and z: bad, it is much more efficient on > debug to start from the object than the event. > I agree. My idea isn't to respond to an event but rather to handle an object or action. > • FM calls > <https://www.screencast.com/t/g6UniM6Ri2ep> > All object method are the same: call the manager with no parameter. > Passing the object name or event is not necessary. Form method is the only > exception, I use Current form name (since v14). > Line 67: the form manager can be used as its own launcher in a new > process. Nice for conception/debug. > Exactly. Having the code for all the form objects available in a single place can be a real time saver when trying to see how those objects interact with the overall purpose of the form. Plus there are frequently very similar actions being carried out by various objects that can be consolidated and optimized. Most of all I can't imagine how difficult it would be to manage a complex form using dynamic variables when you are attempting to manage all that within each form object script. • I use a pointer as $3. Nice in re entrance use/re use of part of code; > for example: > It's also a great place for using a c-object. For instance you can put a hidden c-obj var on the form and use that for a temp buffer (I hadn't stumbled on the issue Canon pointed out about the minimum size for such an object - good to know). For subforms I will make the subform object a text type var (c-obj type is in v16?) and stringify the c-obj to it. This makes passing data from the host to the subform and back again really easy. • Assignment operator with form locales: > (OBJET Get pointer(named object;"myObjectname"))->:="something" > 32 chars before writing the object name. Ouch. > Definitely a good place for a set of 'tools' for dealing with form objects. I went in a slightly different direction: OBJECT_SET_TEXT("objectName";"text value to set") $text:=Object_get_text("objectName") OBJECT_SET_toPointer("objectName";$pointer) // handles any data type The hardest thing for me when I started working with dynamic variables and the new form options was getting past my old, old habits about making forms in 4D. Probably as recently as v2004 these sorts of things would have been too computationally 'expensive' to be viable options. -- Kirk Brooks San Francisco, CA ======================= ********************************************************************** 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:[email protected] **********************************************************************
