My biggest pain points with the outline, and I use it constantly, are:
1. When in sorted order, internal structure of keys and data structures are sorted that way as well. I usually want to see fields and procedures sorted alphabetically, but never data structure and key internals. And never parameters. So I have to find a data structure, or procedure, or file, and then I have to resort to find the structure of the thing I just found. And to top it all off, once I find it, and expand it, sometimes if gets compressed back up, but fortunately it keeps the highlight.
2. When I have a display file format, and sometimes a printer file format, the contents of that format is incorrect. Because I have a mix of display and printer files that use INDARA, or not, I have to go to the display or printer file to find out if the indicators belong in the record format or not. Without INDARA if I clear a record format with indicators, the indicators on that record format are cleared as well, but with INDARA, this is not the case as the indicators are not really a part of the record format, they are handled separately. It is much harder to track this down. In addition every data structure that is defined like one of these records is incorrect, so the outline carries indicators down into other structures where there really don't exist.
3. Filtering the outline is a little painful as well because sub-procedure parameters are filtered as well. I would prefer that all parameters of a sub-procedure that appears in a given filter be visible rather than just the ones that satisfy the filter. So I go find a sub-procedure using the filter, and now sometimes I have to clear the filter to see the parameters so now I have to remember the sub-procedure name (it is usually still highlighted), resort, and then go find it, and open up the parameter list. This mostly happens for prototypes because we have a large number of sub-procedures in service programs, and just a handful of copy books containing them. Might be helpful to be able to see the prototypes grouped by copy book, or source file name. Which source file directly brought it in. This could be a bit messy with nested copy books, but I would only want to see the copy books that are references directly by the program source as groupings, and the copy book that initially resulted in the prototype being brought in. This second part isn't as big a deal for me with prototypes as my nested copy books rarely if ever contain prototypes, Those are generally just data definitions, and I don't need to see that broken down. Associated with this, it would be helpful to filter prototypes and definitions by whether or not they are used by the program source.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----"Edmund Reinhardt" <edmund.reinhardt@xxxxxxxxxx> wrote: -----
To: Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries <wdsci-l@xxxxxxxxxxxx>
From: "Edmund Reinhardt" <edmund.reinhardt@xxxxxxxxxx>
Date: 04/11/2016 02:07PM
Subject: Re: [WDSCI-L] Poll of users of live ILE RPG outline view
So far the sense I am getting (from the comments) is that people have the
following requirements
i) When they edit code with numeric indicators they would like to see
- all of the uses of the same indicator whether it is reference by number
or name
So for the following code
dcl-f file workstn indds(myinds);
dcl-ds myinds;
invokeHelp POS(1);
exitNow POS(3);
end-ds;
*in(01)=*off;
exfmt panel;
if (*in01)
showHelp(invokeHelp);
end-if
We could show the following in the indicators section - all pre-defined
indicators sorted alphabetically and all aliases shown on the line that is
referencing it
- Indicators
- 01
3 - invokeHelp
6 - *IN(01)
8 - *IN01
9 - invokeHelp
-03
4 - exitNow
ii) Other people would like to consider all declarations as 1 easily
searchable list, sorted by occurrence in the source (merge together data
structures, fields, constants, indicators, maybe even files)
What I am understanding is that pre-defined indicators merit a different
section because they are provided by the compiler and can be aliased in
these ways (and are really hard to find lexically)
Is there any business case that supports them being sorted by the source
order?
Would people actually want the predefined indicators lumped in the "All
declarations list" under (ii) above, all sorted in source order? Of course
the pre-defined indicators would mostly be at the end because they were
referenced first in the Calcs.
Is there any business case that supports named indicators being lumped in
with pre-defined indicators?
Do people really want a lot of different preferences that they may never
discover and then have to figure out whether they are useful and might only
be there because of the historical evolution of the product? (Just doesn't
feel clean and easy to learn). It would be nice if we had options that
helped people accomplish certain tasks easier, so they measurably improve
productivity.
Another thing I am wondering, is there a use for an I Specs and O Specs
entry in the outline view to take people to those sections of the code?
Again, I am listening, educate me.
Edmund
From: Paul Bailey <PaulBailey@xxxxxxxxxx>
To: Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries <wdsci-l@xxxxxxxxxxxx>
Date: 11/04/2016 11:41 AM
Subject: Re: [WDSCI-L] Poll of users of live ILE RPG outline view
Sent by: "WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx>
1) C
2) C
I'd like the indicator names given by INDDS (and maybe those BASED on the
address of *IN) data structures to also be in the indicator list, with
indicator name and related number having all usages for both. I do *a lot*
of legacy/DSPF/PRTF maintenance and any little extra help is always
appreciated.
-Paul.
-----Original Message-----
From: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Edmund
Reinhardt
Sent: 08 April 2016 20:56
To: WDSC
Subject: [WDSCI-L] Poll of users of live ILE RPG outline view
Since you are the active community in support of this product, you get to
have the power to help me make design decisions.
I have received feedback on two issues about indicators and how they used
to behave differently with the static outline then they do now with the
live outline.
1) Named indicators now appear under the Indictors heading when they used
to appear under fields as just another named field with indicator type.
People have complained and want to have only the numbered indicators until
the Indicators heading.
2) Numbered indicators used to appear in numerical order which was easier
to find, now they appear in the order that they occurred in the source
(similar to all the other declarations).
I have 3 options.
A) I can change to the original behaviour with no preferences.
B) I can add a preference, but set it to the original behaviour (so people
will see the product change to the original behaviour when this is
released)
C) I can add a preference and set it to the current behaviour
So submit your votes to me
A vote of
1A
2A
Means named indicators will now appear under fields and numbered indicators
will appear in numeric order - no additional preferences
A vote of
1C
2C
Means the product will behave just as it does today, but there will be 2
additional preferences that will enable the old behaviour
Vote away, let your voice be heard :-)
Edmund
--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list To post a message
email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list
options,
visit:
http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/wdsci-l.
---------------------------------------------------------------------------------------
Important This email transmission and any files with it are strictly
confidential to the intended recipient and may be legally privileged. Any
views or opinions presented are solely those of the author and do not
necessarily represent those of BHSF. If you are not the intended recipient,
you must not copy, disclose or distribute its contents in any way.
If you have received this email in error, please notify the sender and
delete the email from your system. We have taken steps to ensure this email
and attachments are free from any virus but do not accept any
responsibility once this e-mail has been transmitted. You should scan any
attachments for viruses. No contract may be concluded on behalf of BHSF
Group Limited or its subsidiary companies by email.
Registered Office: BHSF Group Limited, Gamgee House, 2 Darnley Road,
Birmingham B16 8TE. Registered in England number 04767689. BHSF is
authorised and regulated by the Financial Conduct Authority and Prudential
Regulation Authority.
This email has been scanned for email related threats and delivered safely
by Mimecast. For more information please visit
https://www.mimecast.com
---------------------------------------------------------------------------------------
--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/wdsci-l.
midrange.com
