Hi Edmund, I have a couple more cents to throw in.
You said, "
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)"
I personally have no use for the Indicators grouping, but I do like having Files, Data Structures, and Constants separate. My reasoning is that "indicator" is just another variable data type so in my mind it belongs under Fields, while the other groupings are structurally different (aka not just another data type).
Thanks for asking everyone's input!
Kurt Anderson
Sr. Programmer/Analyst - Application Development, Service Delivery Platform
-----Original Message-----
From: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Edmund Reinhardt
Sent: Monday, April 11, 2016 2:00 PM
To: Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries <wdsci-l@xxxxxxxxxxxx>
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.
--
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
