Retrieve the Function Key Used on a Display File

[Guest.Visitor]

Retrieve the Function Key Used on a Display File

Nope, not yet. And that's the point of my post: Anyone knows a little more about that? As far as applications falling apart on the next upgrade, don't worry: I wouldn't use this code in a business app. But I use it alot in my everyday tools...

[padshore@optonline.net]

Retrieve the Function Key Used on a Display File

I have also been using this technique for some time, however, I've just been asked the following question. Can other keys be captured For example ALT - Q together or CTRL - N together. Any help or pointers would be MUCH appreciated Alan Shore

[J.Pluta]

Retrieve the Function Key Used on a Display File

Not in a standard 5250 display. Joe

[David Abramowitz]

Retrieve the Function Key Used on a Display File

I think that the iseries access macro facility may be what you are looking for. A macro may be assigned to a set of keystrokes. I'm not tto sure about this Dave

[Terry Winchester]

Retrieve the Function Key Used on a Display File

As David pointed out, key combinations can be utilized by the Client Access emulator scripting facility but as far as the 5250 datastream understanding keystroke combinations and returning them to your program, Joe was correct...not possible...nor is it supported in the DSM API's Terry

[David Abramowitz]

Retrieve the Function Key Used on a Display File

Strangely enough, it is possible to capture certain keys in conjunction with mouse clicks by using the mousebutton keyword in DDS. Dave

[MCWebsite.Staff]

Retrieve the Function Key Used on a Display File

** This thread discusses the article: Retrieve the Function Key Used on a Display File **
** This thread discusses the Content article: Retrieve the Function Key Used on a Display File **
0

[Gordonrs]

Retrieve the Function Key Used on a Display File

** This thread discusses the article: Retrieve the Function Key Used on a Display File **
Hi all, I have used the QUSRJOBI to discover how a user left an SEU session (part of a program I wrote for automatically removing old comment lines), where I only want to continue if they pressed enter. This could be used following SNDRCVF. DCL VAR(&A_LEN) TYPE(*CHAR) LEN(4) DCL VAR(&A_RCV) TYPE(*CHAR) LEN(1000) STRSEU SRCFILE(QTEMP/TRPGSRC) SRCMBR(CHECK) + OPTION(5) /* option is display */ CHGVAR VAR(%BIN(&A_LEN 1 4)) VALUE(307) /* receiver + length */ CALL PGM(QUSRJOBI) PARM(&A_RCV &A_LEN 'JOBI0600' + '*' ' ') /* IF CA03 or CA12 selected then cancel */ IF COND(%SST(&A_RCV 103 1) *EQ '1' *OR + %SST(&A_RCV 104 1) *EQ '1') THEN(DO) SNDPGMMSG MSG('Copy and decomment cancelled') RETURN ENDDO Hope this may be of use to someone, somewhere! Regards, Gordon

[mscottx]

Retrieve the Function Key Used on a Display File

** This thread discusses the article: Retrieve the Function Key Used on a Display File **
I can't count the number of times I have seen: D AUTENT C CONST(X'3F') Don't be misled. This "auto-enter" is never returned as a result of auto-enter on your display file. What I am referring to is CHECK(ER) on a field or GUI-type objects on your display that have *AUTOENT or *AUTOENTENH specified on them. You will never know that your application returned control because of "auto-enter". Your application will only see that ENTER was pressed (x'F1'). Thus, I recommend checking the CSRFLD parameter of RTNCSRLOC keyword in conjunction with your WSDS keyPressed field to determine if the user interacted with the relevant "auto-enter" enabled field or object. Unfortunately, all you will see is ENTER, not space or click or any other method that will cause an "auto-enter" enabled object to return control to your application.

[ralph2339]

Retrieve the Function Key Used on a Display File

** This thread discusses the article: Retrieve the Function Key Used on a Display File **
I don't want to appear to be a neanderthal, but what is the difference between "when *in03 = *on" and "when fkey = f3?"

[fsuinnc]

Retrieve the Function Key Used on a Display File

** This thread discusses the article: Retrieve the Function Key Used on a Display File **
I don't understand how all the extra definitions help to make C EXFMT CustMaint C SELECT C When FKey = F12 C Callp previous() C When FKey = F3 C exsr Exit C When FKey = F5 C Callp Rollback(1) C endSL easier to read or understand than C EXFMT CustMaint C SELECT C When *INKL C Callp previous() C When *INK3 C exsr Exit C When *INKE C Callp Rollback(1) C endSL I agree that indicators can be confusing but to me there is a difference between RPGII C specs that have lots of them like C 01N5208 C A06N27 But when the language/system has provided special indicators that are automatically assigned to the function keys and you go out of your way to avoid using them it doesn't make sense. It's like saying that 'CHAIN' is passe because SQL can accomplish the same thing. If you want clarity, assign meaningful names to the *INK indicators and you should get ease of use and readability. (BTW, I rarely comment on your articles but always enjoy them. Dispite this comment and I am not strictly an old school stick in the mud. This solution just seems overly complex.)

---

Code

[rvanner@lear.com]

Retrieve the Function Key Used on a Display File

** This thread discusses the article: Retrieve the Function Key Used on a Display File **
I believe that the solution offers better readability to all programmers. The definitions are easy to implement. I have been using this in my code for years and love it. I tend to define my code like this. (See below) I would much rather read things like F3Key or F12Key than *INK3 and *INKL.

---

Code

[R.Cozzi]

Retrieve the Function Key Used on a Display File

** This thread discusses the article: Retrieve the Function Key Used on a Display File **
The difference is you are the only person in the universe (just kidding about the scope) who knows that "*IN03 = *ON" applies to CF03 in your DDS. Whereas if I am looking at your code and see "FKey = F3" I know what the code is doing.

[R.Cozzi]

Retrieve the Function Key Used on a Display File

** This thread discusses the article: Retrieve the Function Key Used on a Display File **
Greg, the use of *INKx indicators has long since been abandon by RPG programmers. You (hopefully) will never see them used in contemporary RPG III and never in RPG IV. "Kids today" don't know what those indicators are used for, and unless you've worked on S/3 and started with RPGII (even on the S/36) you probably never used them. One small goal in life is to ELIMINATE the use of ALL indicators--wipe out their usage. In fact, I wish IBM would give us an EXIT opcode so we didn't have to fake-out RPG with *INLR=*ON.

[fsuinnc]

Retrieve the Function Key Used on a Display File

** This thread discusses the article: Retrieve the Function Key Used on a Display File **
Don't get me wrong, in many ways (on the indicator issue and other issues) I agree with you. "Kids today" don't know what Hex code is either, at least not the ones I have been running into for the last ten years. I have had much better success explaining *INKx indicators to RPG beginners than I have had success explaining what "CONST(X'B7')" means and how that has any connection to pressing 'Shift + F7'. If F19 calls the item inquiry program then map *INKT to variable Item_inq and check for it to be *on. Is it modern? Maybe not, but it works and all the programmers can easily identify it and it's built in to the system. I'm not saying your wrong, I'm saying that as bad as indicators might be sometimes, I often find their use both easy and as elegant a solution as any other.