This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
As you can see from the vote count on this RFE, the "not woth the benefit" is an incorrect opinion and it should be reconsidered.
;(
If the cost to implement it is too high, then either I'm not seeing where the cost would be or perhaps the techniques selected to implement were not optimal?
1) Add the %FKEY or %FN built-in function with 1 parameter a character.
2) Allow that character to be either a built-in Figurative Constant, like *F3 or a 1-byte value that is the AID Byte value for the various Fn keys.
3) At runtime compare that value to the WSDS value returned in position 369.
That's like 10 lines of code (okay not really "10 lines" but you get my point). It doesn't need to be a new capability. Please reconsider as the number of votes indicates that it is something that is desired by the community.
IBM does not intend to provide a solution to this request at this time, so it is being closed.
The cost to implement this request would not be worth the benefit, since there is already more than one way to accomplish the goal of determining whether a particular function key was pressed.
The INDDS allows you to use descriptive names.
Example:
DCL-DS WSDS QUALIFIED;
Exit IND POS(3);
SearchEntry IND POS(4);
Refresh IND POS(5);
NewEntry IND POS(6);
CommandLine IND POS(9);
Cancel IND POS(12);
JumpTop IND POS(17);
JumpBottom IND POS(18);
SubfileClear IND POS(30);
SubfileDisplayControl IND POS(31);
SubfileDisplay IND POS(32);
SubfileMore IND POS(33);
END-DS;
Select;
When WSDS.Exit;
// Do stuff
EndSl;
So i think this option is much better than a %FKEY(*F3) or similar.
@eckersleyd, please correct me if I'm mistaken, but I believe mouse events are reported in the AID byte of the INFDS as whatever function key F1, F2 etc they are mapped to in the display file. If so, it would not be possible for RPG to know whether it was a mouse event or a function key that caused that particular value.
If you chose to implement this then please make it possible to set and disable it.
For example:
eval %FKEY(*F12) = '0'
eval %FKEY(*ENTER) = '1'
eval %FKEY(*F3) = *ON
I'm sure that the mouse events can be used with this as well? if %fkey(*E01), for example?
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Power Systems
Product - IBM i
Component - Languages - RPG
Operating system - IBM i
Source - None
For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - Power Systems
Product - IBM i
Component - Application Development
Operating system - IBM i
Source - None
Using a *F3 *PAGEUP *PAGEDN *ROLLUP *ROLLDN *ENTER *PRINT, *HOME (don't forget the HOME key) and so in is perfect.
EXFMT Display;
IF %FKEY(*F3);
return;
endif;
// Happy Days!
Please note that although the *xx (leading asterisk) is acceptable, since I assume IBM will just map *F3 to X'33' and the built-in will simply test the equivalent of the WSDS for X'33'. This would mean *F3... *ENTER etc. should be available as figurative constants outside of the %FKEY() built-in function, correct?
IBM has received the requirement and is evaluating it. IBM will provide a response after evaluation is complete.
If this is implemented, the syntax would use special values like *F3: %FKEY(*F3), %FKEY(*F24), %FKEY(*PRINT)
I'm assuming the definition of a function key would also include the Page Up/Down keys, Enter key, etc.
I don't enjoy dismissing comments, but clearly as the guy who documented the X'33' and all the Fn key values/scan codes back in 1987 and showed how position 369 of the WSDS can be used, I'm verify familiar with the WSDS approach. The other suggestion of "mapping indicator array" cause me the throw up in my mouth a little. Who would do that if they didn't have to? (and you don't have to.)
By adding the %FKEY() built-in, it becomes standard and available to everyone as the standard way to code and respond to Fn keys. Is it better than "your way"? Of course it is.
This request doesn't add anything to readability.
Overlay the indicator array with an array of named indicators and give them proper names. That would add some readability to it. And that can already be done with adding more **** to the compiler.
What's wrong with...
Dcl-C F3 Const(X'33');
If WInfDS.Key = F3;
The readability is almost identical.