Bernd, On Wed, Oct 10, 2018 at 11:49 PM Bernd Fröhlich via 4D_Tech < 4d_tech@lists.4d.com> wrote:
> there are no globals required for menus (I assume here that you are > talking about popup menus in the form). > So true. This deserves its own thread. In fact unless you have some extended lookups to do building menus is fast, (has been) fast enough to do on-the-fly in response to a user click for a long time. I think a lot of us learned about installing menu bars a long time ago and never stopped to look at alternatives. There are good reasons to move form controls onto the Form instead of maintaining controls and commands in the menu bar. Off the top of my head: * large/multiple screens: it's a complete PITA to have a form open on the lower right of a big screen and have to mouse to the far upper left corner for some command. * easier for users to see commands relevant to their immediate action on the form. * easier for you to keep track of. * easier to adjust menus to specifics of user permission, form state, user prefs, etc. * easier to make menus context sensitive. Granted I'm assuming the overall design of the project has a modern look: multiple windows and responsive design. If you're still using MODIFY SELECTION/RECORD type design it probably doesn't matter as much aesthetically though I stand by the issues of managing them. Just give them an objectname, get a pointer in the "on load" phase with > Object Get Pointer and define the array using that pointer. > Works great. > So true. And you can release a menu immediately after you use it, there's no particular advantage to keeping them. $menu:=Create menu - build it - $result:=Dynamic pop up menu($menu) // present to user RELEASE MENU($menu) Case of // manage the choice :($result="doThis") ... End case I do this this response to user clicks and contextual clicks all the time and I've never had a memory leak. It makes popping up menus on listboxes, buttons or any active object (that's a picture too) very easy to manage. And you can also use Dynamic pop up menu to present a menu designed in the menu editor. > I LOVE it that there are no longer ANY global variables necessary when > working with forms, even if the form has to give some information back to > the calling method. > Just put that information in the Form-object and you get it back in the > object that you passed into the form with the DIALOG command. > Agree completely. I find it useful to have a single process variable - an object (I call it 'prosObject') which I use for persisting data. Pre v17 this can be used like (not equivalent to) the new Form object - it's just there all the time. Very handy for passing parameters to a dialog I popup for information, for example. Or for complex forms with many subforms where each subform provides details, lookups or whatever for the larger data object. Plus this makes it easy to have a single subform object and simply install the relevant subform when needed. I adopted Canon's OBJ Module to make set/get method to this object for convenience. eg. ProsObj_SET_TEXT("some.property";"some value for it"). Code using this approach translates well to v17 and the technique can work going back to v14. I also very much like being able to look at it. It's a huge advantage when working with some complex data structure to be able to open a dialog and see all the elements. Possible but not easy if each element were its own process var. Plus I like being able to copy it to my text editor. > > I think this is the best change since making pointers to local variables > available. > Yes. -- Kirk Brooks San Francisco, CA ======================= *We go vote - they go home* ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************