Can't detect CTRL_INS

[alidzi]

Hi!

I have tried to move my old Clipper (5.01) program, which works perfectly under WinXP CMD,
to a newer Win7x64 machine. It worked fine, until I had to press CTRL+INSERT keys (used to
insert some new stuff), which are not detectable under vDOS.

Then I have tried other program, specially designed to show the codes of the pressed keys,
and CTRL+INS,  CTRL+DEL are not working at all (they work under XP CMD).

CTRL+HOME/END, CTRL_PGUP/DN, CTRL_LEFT/RIGHT work fine (CTRL_UP/DN does not!).

Does anyone know the reason or some fix?
I do have the source code of these programs so I can reprogram it, but I'd like not to, if it's possible.

EDIT: I have also tried the vDOSplus, but it is the same thing - doesn't work.

[Jos]

SCODE.COM shows the same results in vDos and NTVDM…

Attachments:

SCODE.COM (2.97 KB)

[Herman]

For me, the same result is obtained in dBase 5 both in NTVDM MS-DOS and vDos 20190501.
The combinations as mentioned do indeed not work.
For me is that not a problem because, I do not use these key combinations.

INKEY() and LASTKEY() do not respond indeed. That works in Clipper, I think, the same as in dBase.

In XP I can not test it, because I have released it completely.

For me, the most important thing is that the reference with NTVDM MS-DOS is the same as in vDos.

That seems to me the most important starting point for the operation in vDos
There will always be some differences, but what is the reference to vDos?

MS-DOS version?, NTVDM MS-DOS (version?)

MS-DOS is a certified system that underpins everything.


Regards Herman

[Jos]

dBase and Clipper will call the BIOS to get a single keystroke.
For special keys like Insert and Delete, that will be the only way. While dBase Inkey() works the same in XP and vDos.

Jos

[alidzi]

So is there a solution to my problem except
digging in the source and changing old code?

My program for checking uses simple inkey(0)
wait to press the key, then it writes its
code. When I press CTRL+INS/DEL it gives me
back 403 & 402 as result, but only under
pure DOS or 32bit NTVDM.

In vDOS I don't get nothing, nothing pressed.

[Jos]

Not what vDos concerns.
Inkey(0) in dBaseV returns -404 for both Ctrl+Ins and Ctrl+Del, under NTVDM as well as vDos.
Other DOS programs have no trouble with those key combinations, for instance WPDOS uses both. While SCODE.COM clearly shows vDos returning the correct values.

Maybe it is caused by Clippers keyboard buffer, it has his one of its own. Maybe there’s an option to turn that off.

Jos

[alidzi]

Ok, thanks for quick reply.

I'll go to digg in this old code
and will report here if I do sometihing
more interesting than just replacing
CTRL+INS to other key combination.

Thanks again!

[Jos]

You will have to figure this out yourself.

Clippers own keyboard buffer already caused troubles for vDos. Pasting text to DOS application didn’t use the BIOS keyboard buffer: If that was empty and text to paste, vDos still returned a (keyboard) character was actually available when a program inquired that. As fast a program could accept keystrokes, the text was pasted. Some programs accepted large text fragments nearly instantly. Clipper however constantly polls if a keystroke is available, then transfers that to its own buffer. If full, Clipper keeps polling the keyboard, dropping any additional keystrokes. The pasting routine of vDos had to be adjusted (crippled with pauses), only to accommodate Clipper. Instant pasting of all text became a sequence of repeated 16 characters with pauses in between.

Jos

[alidzi]

Well, I have made simple version of SCODE.COM, where I can compare
Clipper's INKEY function with SCANKEY (from 3rd part library
Nantucket Tools II).

vDOS - ibb.co/f48wTV

NTVDM - ibb.co/c93Khq

The main problem is that Clipper's functions like DBEDIT (which is
one of the main functions to browse/edit databases) obviously use
INKEY function for keyboard pooling, as it is a part of Clipper itself.
SCANKEY is not used, since this is a part of a commercial 3rd party library).

The only solution is to change CTRL_INS combination to something else in code.

But what confuses me is that it works perfectly under NVTDM!
Obviously, you have a different approach to keyboard than NTVDM.

But anyway, vDOS looks great, I hope there will be no more suprises for me.
I didn't even had to change my code since I've remembered that CTRL+INS is a
shortcut in my program to speed up some data entry, but there is still "the
normal" way to enter data (just a few keypresses more).

[Jos]

As said, Clipper programs have their own internal keyboard buffer. That is in the background constantly updated by polling the ‘real’ keyboard buffer.
So your INKEY (or even SCANKEY) doesn’t use BIOS calls (like SCODE.COM and other DOS programs) to fetch keystrokes, but inquires the Clipper keyboard buffer.

Besides not considering keyboard buffer overflow, something else seems to be off with Clipper updating its own keyboard buffer.
Don’t know why/how this is vDos specific, could be a timing issue; for instance checking for the ‘real’ (out-of-sync) control key being down.

I doubt your test programs will even help/reveal something. Best would probably be (in time…) to just disable/bypass the Clipper own keyboard buffer management.

Jos