× 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.



Edmund,

- I would personally like all references to the indicators in its own section and also in the variables section.

- For better or worse I and O specs are still used. I believe that this should be a tool that caters to the real world. Calling up an older program that contains O specs is fairly common. *PRTF's are not universally used, even in new code. I see I specs much less often, but since it's still useful to write programs with level breaks, I think it's still relevant.

-mark

On 4/11/2016 1:59 PM, Edmund Reinhardt wrote:
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.



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.