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
**********************************************************************
