Hi,
when I’m starting to develop a new app with different menus, what will be a good desgin?
Should I create a program for each “menu item” and pass the data through a GDA?
I could also create one Main program and all menu items as a subprogram. Data will be pass through PDAs.
What is th best Option?
Best regards,
Markus Wessjohann
I would recommend the second option you mentioned, namely a “driver” program (with the main menu), and separate subprograms for the various options.
Depending on the number of options, in the main menu, the GDA you mention in your first approach could become quite large. Also, maintenance of the GDA variables would be more annoying than would be the case with individual PDAs for each subprogram.
steve
Hi,
yes that I would also prever, but I have no expereince with this desgin. What is with memory or the callstack. Are there are limitations?
I don’t mean a application with 3 or 4 dialogs. I mean a application with more than 100 dialogs.
Best regards,
Markus Wessjohann
A robust menu/navigation subsystem will support PF keys for drill-down and transfer of control, and will allow or disallow access to functions for individual users or groups. Building this logic can be quite complex. If you build all functions as programs, then Natural Command Processor can be used to handle much of the navigational control. Also, it may be simpler to test and invoke programs “stand-alone”, as in batch.
Hi,
Yes, that is true, but I prefer to have the “Security”-Layer and “Navigation” in the natural-programs. I think it is more flexible and you have the controll in one hand. Another point is, that I don’t have to handles with GDAs.
They are diffcault to you and in a error-case hard th handle.
If you are using only one mainprogram it is easy to restart after a hard error. You start at the beginning. All varablies are correctly set.
In my case, it is easier to test subprograms than programs.
I can test the subprograms with our Test-Framework NatUnit http://sourceforge.net/projects/natunit/?source=directory very easily and retest them every day.
Next point is, that a subprogram give me the chance to make the subprogram “SOA”-enabled. With a program I can’t to this.
For a batchmode I musst write a wrapper programm, thats ok.
A subprogram gives me the oppertunity to use it in another workflow.
If I want to use it with programs, I found sometimes this ugly code:
IF MAINPRG EQ 'WRKFLW1' OR EQ 'WRKFLW2'
ESCAPE MODULE
ELSE
FETCH 'MENUITM3'
END_IF
But I have no experiance with this desgin and I wanted to know where are the contranits.
Best regards,
Markus Wessjohann
Hi Markus,
If you wish, you could have a common program serve up all main menu and sub-menu screens if the layout is the same and just the content is different. Typically the functionality on all main and sub-menus would be close to identical.
-Brian
Hi,
Yes that’s what I wanted, but what is about the max. Call stack in Natural?
How is the memory developing when I’m using subprogram instead of programs?
For the UI it isn’t relevant, but what are the technical constrains?
Best regards,
Markus Wessjohann
I can recall once being told the max depth of *LEVEL was about 7 but that was so long ago that 1) it could be ADALORE and 2) there may not be any significant max *LEVEL these days.
The menu system we have uses a main program that does a FETCH of itself to peruse menu levels though so we don’t consider *LEVEL (though we have a structure that only goes 4 deep anyway).
From the Description of *LEVEL
It’ll only ever be 99, although the max depth is 512, simply because *LEVEL is a N2, but I can herdly think of a scenario where one would go deeper than 99 anyway 
I once worked on a complex application in which a specific scenario resulted in a subprogram being executed at level 40. Very difficult to debug.
But even fairly simple applications can get you beyond level 99. You have to support typical PF3 logic - “take me back to where I was.” Combine this with 5 or 6 PF keys (on every screen) that “drill down” or take the user to related functions. Most users will repeatedly use those navigation keys and rarely use PF3. Whether you use FETCH RETURN or CALLNAT to drive the menu/navigation system, each transfer of control is another level deeper, and you will eventually exceed the maximum of 512.
If you build an application with programs instead of subprograms, you can set your own maximum and tell the user when he reaches or exceeds it.
hi,
yes, the desgin of the apllication would be complex. I musst ensure, that every dialog is everytime on the same level.
That will be easier with programs. With every Fetch I start at Level 1.
Best regards,
Markus Wessjohann
I believe you are on the right track using FETCH instead of FETCH RETURN or CALLNAT. An object that just fetches itself passing parameters stays at level 1 and has no issue finding its way around. We designed ours to use navigation codes (4 3-character codes, 1 for each submenu level), so based on the selection or function key, it FETCHes itself with the new set of codes which can be either selected or entered on a command line so people who know the codes can jump right to where they want to go. We display only the codes the user has access to and do not permit entry of a code that is also not on that user’s navigation profile.
Best of luck!
Hi,
thats ok for stateless programs, but if you have programs witch are statefull you can’t call them directly.
You must handle the context, as an example a police-number.
With programs you can use a GDA to do this, with subprograms you use PDAs.
In my opionen PDAs are easier to handle than GDAs, so I would prefer subprogams.
But I haven’t any experiance with this, so I wanted to know the technical risks to change all programs into subprogams.
Best regards
Markus Wessjohann
Why do you need to change the object type to subprogram just to maintain state? Programs accept parameters through the input stack.