× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I was under the impression your time was worth more than this. These attributes are not available with the usual command (DSPMNUA). There is no API to get this information. And these are not specified in the source. When you use SDA to create a menu, although you specify these options there, they are merely passed on to the CRTMNU command, I assume.

The only way to do this programmatically is to use a command called DMPOBJ to put the byte-content of the menu into a spooled file - I forget if a user space can be used. Then you'd need to reverse engineer where these attributes are kept. Doable, and maybe even a little fun.

But if you are willing to go through the one-time pain - seems you are - and put the appropriate commands in a CL, you're done down the road.

As for change management systems, there are 3 players who've been around awhile - ACMS at www.aldon.com, TurnOver at www.softlanding.com - same as the SoftMenu folks (and we use this one at RJS), and Implementer at www.mks.com (IIRC - David Gibbs works on this one - please correct me if you need to, David). There is now at least one more in the mix, Tight As A Drum, being marketed by www.unbeatenpathintl.com

At 04:39 PM 3/18/2005, you wrote:
Thank you

It is easy to determine the attributes. The easiest way is to display the
menu GO xxxx and observe whether the command line is short, long, or none
and to observe whether function keys are displayed or not.  Then write that
down and use later when compiling.

It just seems like these settings (CMDLIN and DSPKEY) are as much a part of
the menu as the commands and display text are.
 (CRTMNU could easily derive these from the menu source)
So it seems like this information is 'lost' when using SDA in that SDA
ignores this information.
I suppose this is a feature. :-)   It just uses the options you used
last time when using SDA.

I have 100 menus to make small changes to and recompile so what I am doing
is to display the menu before I change it and note how the CMDLIN and
Function Keys are set and then when I compile the menu, change the options.
The menus were not all compiled with the same options originally.

Do you have a web site for a change management system?

Dave Pate
----------------------------------------------------------------------------

Either you get a change management system (mucho bucks) or you write some CL
build programs that set the parameters as you want them. There is no command
or API that will show you these attributes - you COULD, I suppose, dump the
object and try to figure out where this information is set, but that sounds
like work.

HTH
Vern
-------------- Original message --------------

> It seems that when you recompile a menu it would be nice if it
> remembered how the menu was compiled last time (CMDLIN and DSPKEY options)

> without you having to check how the menu displays currently and
> then having to change the prompt options for each menu on the CRTMNU
> command.
> It is easy to compile the menu the 'wrong' way and have lines 19
> and 20 not show up where they did show up before.
>
> So is that the way you have to do it or is there something I'm
> missing.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.