Hello!!

On one of our servers it is possible to do a copy-paste using control-C and control-V respectively, as usual.

However, on a client's server this sequence does not work because the paste is not executed. We're using the same program (same hash) and the same version of A-Shell (7.0.1756.3). Curiously, right-clicking and clicking on the "paste" options, works correctly. We're using SBXINP. Is there any configuration missing? The case was tested with different PCs and the result is consistent: it works on our server but on the client's it doesn't.

Thanks in advance for your help!

Best regards.

Hi René -

Based on your description, the problem seems specific to the keyboard operation (Control-V) within INFLD (for which SBXINP is a wrapper), and not to the clipboard/paste itself. That points the finger towards one of the INFLD Type codes that may affect the paste operation. Browsing the Type Code Summary Table I see the following two possibilities...

• ||p Disables the paste operation
• |K Select Data Entry Convention

The latter reference is a bit vague, but looking in the Keyboard Commands table it does say for CTRL+V : If |K paste contents of clipboard, else delete word (Note INFLD predates Windows, so it's default control key command associations are those of VUE, where CTRL+V is delete word.)

So the first thing I'd check is whether either of those Types codes have been activated. Presumably you aren't doing it directly or all the sites would work the same, but INFLD also supports a mechanism for setting default type codes, either in the miame.ini (see SBR=INFDEF), or using SET.LIT (SET INFDEF). The easiest way to check the end result for a particular input field (i.e. the active combination of type codes, however they were set) is to use the CTRL+\ command, which will pop up a message box listing the complete list of active type codes. If you're missing the |K or are specifying the ||p then you know what needs to be done.

Otherwise I'd check to see if CTRL+V works in the Settings > Misc Settings dialog. (The input fields there are using standard Windows input controls, not INFLD, and although they only accept numbers, you'll be able to tell whether it's trying to paste or not.) If CTRL+V doesn't work there, then it doesn't seem like an A-Shell issue, maybe something related to the Windows regional settings or keyboard layout that's different at that site? Another possible test would be to use XCALL ACCEPT to see if CTRL+V transmits an ASCII 22.

Hi Jack,

One important thing is that the program is the very same in both servers, with the same hash.

REGPED RUN ? 173 661-567-030-224 3.0(303) DSK2:[152,0]

On our server control-V does work, but on the client's it doesn't.

Control-\ displays the same result in both servers:

INFLD Rev 7.0U[795] Types: A]BIW=:456%)||}m|[ - . 1993-2022 MicroSabio

The exact code is:

XCALL SBXINP,"",SXI_DSPEDT,14,13,42,COMEMB$,"`|K","",0,260,&
"Comentario para el area de embarques",0,EXITCODE,&
-1,0,0,-1,"fld260","lbl260"


The Ashell version:

-- A-Shell 7.0.1756.3 Up and Running --

In the misc settings I copied a number and it was pasted correctly with control-V in both servers.

Thank you in advance for your help.

Best regards.

Hmmm...

According to your XCALL SBXINP statement you are explicitly specifying |K, but it doesn't show up in the CTRL+V display? And the fact that it works in generic Windows edit controls seems to rule out the possibility of some strange regional or keyboard configuration. So what's left? The only two possibilities I can think of are:

• Different SBR=INFDEF (or SET INFDEF) settings on server
• Different versions of SBXINP.SBX

The first one was already discussed, but you didn't reference it in your response so that remains to be checked. Regarding the SBXINP.SBX version (on the server), I think the most commonly distributed version is 2.3(10) (although some developers have their own versions).

Trying that version with your XCALL SBXINP parameters here on an -el7 machine, I get these type codes in the CTRL+\ display...

Types: A]13456TkWhsg|G|E|K`|K|}]|&|f

Unfortunately, SBXINP complicates matters by using its own logic to supply type codes to INFLD, but we should be able to resolve this with digging into the code.

Hi Jack,

Mystery solved!!

The culprit was a very old version of SBXINP installed in the data directory instead of of BAS:

Thank you very much for your help.

Regards.

Glad to hear it. And I guess we can add this to the classic tech support playbook:

• Try turning it off and on.
• If that doesn't fix it, check the versions!