RE: Would anybody know of a way, from a CL program, . . .

midrange-l-request@xxxxxxxxxxxx wrote:

>   9. RE: Would anybody know of a way, from a CL program, . . .
>      (Dan Bale)
>
>Still feeling the need to play devil's advocate here... <g>
>
>Who will maintain this after you move on / retire / buy the farm?
>
>I have plenty of skeleton templates for different types of DDS-based display
>applications, so I'd debate the relative merits of having the same type of
>template for *PNLGRP.

Who will maintain it? I'd guess almost anyone could who was generally 
competent. Like every comparable tool, UIM has defaults as well as details. For 
many uses, most details aren't needed. If this is a first attempt at creating a 
UIM panel group, I wouldn't expect a lot that was outside easy comprehension.

Figures 16-2, 16-5, 16-9 and 16-11, in the Application Display Programming 
guide provide example 'templates' that can give something of an overview of any 
panel group source. The simple lists in Appendix A-4, Panel Group Organization, 
give a somewhat different view. With those, the general organization should be 
understandable. After that, the details of the tags themselves following in the 
appendix is not really different from reading the DDS manual details for what 
the SFLDROP keyword does.

Keep in mind that James did this in couple days for his first time from 
_nothing_ but IBM documentation. Given that James also has already coded the 
calls to the APIs to display the panels and react to any actions, I wouldn't 
expect much more maintenance trouble than with most applications. Trouble, yes, 
simply because it's different.

But I've seen an awful lot of apps that should never be turned over to another 
programmer and they consisted of nothing but RPG, CL and DDS.


>Don't get me wrong.  I love how UIM "enforces" a common user interface.  But
>the lack of a design tool and the near-total lack of information when errors
>occur make UIM development "persona non gratis" (or is it just "non gratis"?
><g>) in my shop.

Interesting combination... "common user interface" and "design tool". It'd be 
nice to think that the first would obviate the second, but of course it doesn't.

With UIM, you have the .im control word that's similar to /COPY, including 
nesting to numerous levels. I've created a bunch of ".im" UIM source members 
that I plug into panel groups as I go along. (For the majority of UIM apps that 
I do, the CL or RPG is essentially the same for all of them -- mostly 
information displays or prompt for values.) For example, when you execute the 
DSPJOB command, the menu that appears has a job/user/number data group across 
the top. I've got that in a ".im" member, so I just plug ".im #jobgrp" in as a 
source line where I want it.

Since UIM source is essentially free-form and since .im's get included 
apparently during the first pass(es) through the source, you can imbed(/COPY) 
even syntax punctuation such as closing delimiters if you really want to. Very 
flexible -- and quickly, once you create your set of .im members. (Aye, there's 
the rub.)

Unfortunately, .im's and "design tool" seem conflicting. If the design tool 
included a way to generate and use .im members, especially multi-level nesting, 
now that would be cool!

Start with the basic "templates" beginning with the figures noted above and 
expand from there. Sure _sounds_ simple... but somehow I keep imagining a UIM 
version of RLU!

Tom Liotta

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp