It's great that it's finally working for you. And yes, ptccrt supports most alt and ctrl key combinations, but if you find some key combination missing, please report it - it is easy to add.

I could really use F11 and F12 including shift, alt, and crtl if possible from the prccrt graphics window. I suspect there is some fundamental reason why F11 and F12 aren't usable, because F11 and F12 don't work in crt either. But here is what does work in crt that would be great if would also work in ptccrt.

F11 - no code but toggles the console window full screen and back- If F11 could not be caputed I would rather it NOT try to change full screen on the ptcgraph window F12 - Extended: #134
Shift F11 - Extended: #135
Shift F12 - Extended: #136
CTRL F11 - Extended: #137
CTRL F12 - Extended: #138
ALT F11 - Extended: #139
Alt F12 - Extended: #140

Interestingly ATL-F4 does not close the ptcgraph window, it returns extended #107 followed by #3 I also notice that hitting the X on ptcgraph window sends a #3 which I like MUCH better than just closing the window. I am going to use these to initiate my exit sequence and properly exit the program instead of terminating it. It would be great to not get the #3 after the #107 for ALT-F4 just to make it completely different than hitting the X, but it's workable to trap #107 then ignore the #3 if I want Alt-F4 to be different than X or ignore #107 if I want Alt-F4 to be the same as X, so maybe best to leave it the way it is.

Here are some keys that work in CRT and their codes, I personally don't have an immediate use for them but it they were available I might think of something CTRL Insert - Extended: #146
CTRL Delete - Extended: #147
ALT Delete - Extended: #163
ALT Home - #7
ALT END - #1
ALT = - Extended #131
ALT ~ - Extended #41
CTRL ~ - Extended #41 * CTRL + and ALT + are the same, would be nice if they were not. The following are from the numbers above letters on keyboard CTRL 1 - Extended #2
Yes CTRL 2 already works and produces Extended #3
CTRL 3 - Extended #4
CTRL 4 - Extended #5
CTRL 5 - Extended #6
CTRL 6 - Extended #7 - ptcgraph produces Extended #30 instead CTRL 7 - Extended #8
CTRL 8 - Extended #9
CTRL 9 - Extended #10
CTRL 0 - Extended #11
CTRL - - Extended #12 - ptcgraph produces Extended #31 instead CTRL = - Extended #13

The following are from numeric keypad
CTRL 1 - Extended #117
CTRL 2 - Extended #145
CTRL 3 - Extended #118
CTRL 4 - Extended #115
CTRL 5 - Extended #143
CTRL 6 - Extended #116
CTRL 7 - Extended #119
CTRL 8 - Extended #141
CTRL 9 - Extended #132
CTRL 0 - Extended #146
CTRL . - Extended #147

I'm not sure about these, it seems kind of like more of a test than real keycodes, but this is what CRT does ALT 1 - #1
ALT 2 - #2
ALT 3 - #3
ALT 4 - #4
ALT 5 - #5
ALT 6 - #6
ALT 7 - #7
ALT 8 - #8 * Backspace
ALT 9 - #9 * Tab
ALT . - Extended #163

The following are the operators from the numeric keypad CTRL / - Extended: #149
ALT / - Extended: #164
CTRL * - Extended: #150
ALT * - Extended: #55
CTRL - - Extended: #142
ALT - - Extended: #74
CTRL + - Extended: #78
ALT + - Extended: #78 *CTRL + and ALT + are the same, would be nice if they were not.

James

James Richters wrote

> It's great that it's finally working for you. And yes, ptccrt supports most alt and ctrl key combinations, but if you find some key combination missing, please report it - it is easy to add. I could really use F11 and F12 including shift, alt, and crtl if possible from the prccrt graphics window. I suspect there is some fundamental reason why F11 and F12 aren't usable, because F11 and F12 don't work in crt either. But here is what does work in crt that would be great if would also work in ptccrt. <snip>lots of missing keys</snip>

Unfortunately, all of the missing keys and differences from ptccrt (including the very odd ones) stem from the fact that ptccrt behaves _exactly_ like the crt unit in Turbo Pascal 7 under DOS, with a 100% IBM compatible keyboard and BIOS. This includes the lack of support for extended keys (like F11 and F12). The Windows crt unit doesn't conform strictly to that, however, so that's why there are differences. I don't want to sacrifice the DOS/TP7 crt unit compatibility, so I'll have to think of something, but it'll take a little time. Perhaps I'll add different keyboard compatibility "modes" or something like that.

Nikolay

Having some kind of Keyboard Mode selection Variable that defaults to TP compatibility would be a great option.

James

Follow the instructions in docs/INSTALL.txt to compile the package. Then add units\i386-win32 from the snapshot directory to the unit search path of your compiler.

Can I have instructions on how to compile ptcpas for x86_64-win64?

I tried guessing that I might need fpcmake -r -Tx86_64-win64

when I try that I get :
Processing Makefile.fpc
x86_64-win64 requires: rtl
Writing Makefile
Processing demos/Makefile.fpc
x86_64-win64 requires: rtl
Writing Makefile
Processing examples/Makefile.fpc
x86_64-win64 requires: rtl
Writing Makefile
Processing test/Makefile.fpc
x86_64-win64 requires: rtl
Writing Makefile

But when I try to run make I get:

Makefile:208: *** The Makefile doesn't support target i386-win32, please run fpcmake first. Stop.

I tried looking at command line options for make but I don't see how to change the target to x86_64-win64, and anyway I might be doing it completely wrong so I think it's best to just ask

I also notice that the changes in https://sourceforge.net/p/ptcpas/code/742 list 'dead key support under Windows and X11 (via XIM)' in the comments. are the missing keys now working and if so do I need to enable them somehow? I haven't tried compiling this yet, I'm still using r715. I thought I would ask if it was ready first.

Thanks,

James

maybe try:

make CPU_TARGET=x86_64 OS_TARGET=win64

Not yet. I'm still working on it. I ended up revamping all the keyboard input support in ptcpas, because I discovered there are some differences between linux and windows in the keycodes for some keys. Since, these are OEM-specific keys, so they differ between keyboard layouts, I tried different keyboard layouts and I discovered that dead keys don't work. So, I started digging in order to find out why that's the case. So, after a lot of changes, I got them working under both windows and linux. After that, I figured out it's time to prepare a new ptcpas release, because there are many other changes, since the last release and I want to get it in time for the new release to be included into fpc 3.0.4. So, suddenly, I'm working on a whole lot more things on ptcpas (relative mouse movement, better unicode support for the keyboard input under both windows and linux, merging several other fixes into upstream fpc libraries, for which ptcpas carries a forked version) :) But, please be patient, it'll get there, maybe in a few week's time. If you're impatient, you can temporarily patch ptcgraph/ptccrt.pp, lines 120..309. These convert the ptcpas key events to crt readkey codes.

Best regards,
Nikolay

maybe try: make CPU_TARGET=x86_64 OS_TARGET=win64

Here is what I have now:

H:\ptcpas-code-715-trunk>make CPU_TARGET=x86_64 OS_TARGET=win64 J:/Programming/FPC/3.0.2/bin/i386-Win32/ppcrossx64.exe -Twin64 -Px86_64 -XPx86_64-win64- -Xr -Fuhermes -Fuptcwrapper -Fuptcgraph -Fux11 -Fuwin32/directx -Fiptcgraph/inc -FE. -FUunits/x86_64-win64 -dx86_64 ptc.pp Warning: Option "-Xr" is ignored for the current target platform. Free Pascal Compiler version 3.0.2 [2017/02/13] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Win64 for x64
Compiling ptc.pp
ptc.pp(125,21) Fatal: Can't find unit glext used by ptc Fatal: Compilation aborted
make: *** [ptc.ppu] Error 1

It seems like it can't find my units but it specifies -FUunits/x86_64-win64 maybe I need to give it the full path to my units for 64bit?

please be patient, it'll get there, maybe in a few week's time

I will be happy to be patient 😊 Thank you for all your hard work on this!

James

James Richters wrote

> please be patient, it'll get there, maybe in a few week's time I will be happy to be patient 😊 Thank you for all your hard work on this!

Ok, I've implemented implemented this. ptccrt now has a KeyMode variable, which can be set to these values:

kmTP7 - behaves like Turbo Pascal 7's CRT unit under DOS. This is the default value. Previous versions of ptccrt always behaved this way. Since TP7's CRT unit doesn't support the Enhanced Keyboard, several keys (e.g. F11 and F12) and key combinations are intentionally not recognized for compatibility reasons.
kmGO32 - behaves like Free Pascal's CRT unit under DOS (GO32V2). It has Enhanced Keyboard support.
kmFPWINCRT - behaves like Free Pascal's CRT unit under Windows. Similar to kmGO32, but emulates several incompatibilities that the Windows CRT unit has with the GO32V2 CRT unit. Not all of them are emulated though, since some of them can be considered bugs.

I've also committed this into FPC trunk and I've proposed it to be merged into FPC 3.0.4, so please test and report any bugs that you found. :)

Enjoy!
Nikolay

Ok, I've implemented implemented this. ptccrt now has a KeyMode variable

Excellent solution!

kmFPWINCRT - behaves like Free Pascal's CRT unit under Windows. Similar to kmGO32, but emulates several incompatibilities that the Windows CRT unit has with the GO32V2 CRT unit. Not all of them are emulated though, since some of them can be considered bugs.

I had patched wincrt a while back because it was missing a lot of ctrl keys. I tried to submit changes to freepascal but never did figure out how to do it properly. My attempt is here: https://mantis.freepascal.org/view.php?id=30599

I got confused with 'Please create a proper patch and against development (trunk) version of FPC' and at the time I just didn't have the time to try to figure it out. I wonder if I should try to send it in again. I added a lot of ctrl keys but I never did figure out how to get ANY alt keys working. Even though I will use ptccrt now because I like ptcgraph better, someone else might benefit from having improved functionality of wincrt. Perhaps adding the 'keymode' variable for compatibility reasons should be used here as well? My changes to WinCRT are here: https://github.com/Zaaphod/freepascal/tree/Fix_WinCRT

I've also committed this into FPC trunk and I've proposed it to be merged into FPC 3.0.4, so please test and report any bugs that you found. :)

I'll be happy to do testing with all keymodes and report back any issues I find. I'm curious if there is any estimate on when FPC 3.0.4 will be released?

I've downloaded the snapshot at https://sourceforge.net/p/ptcpas/code/785/tree/trunk/ and built it using the instructions in docs\install.txt for i386 and have it working.. so far it's working well in my little keytest program.

I still do not know how to build this for x64. I've tried

fpcmake -r -Tx86_64-win64

I'm not sure this is correct, it appears to work, and I don't get any errors, but then: make CPU_TARGET=x86_64 OS_TARGET=win64

gives me the following output:
J:/Programming/FPC/3.0.2/bin/i386-Win32/gmkdir.exe -p units/x86_64-win64 J:/Programming/FPC/3.0.2/bin/i386-Win32/ppcrossx64.exe -Twin64 -Px86_64 -XPx86_64-win64- -Xr -Fuhermes -Fuptcwrapper -Fuptcgraph -Fux11 -Fuwin32/directx -Fiptcgraph/inc -FE. -FUunits/x86_64-win64 -dx86_64 ptc.pp Warning: Option "-Xr" is ignored for the current target platform. Free Pascal Compiler version 3.0.2 [2017/02/13] for x86_64 Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Win64 for x64
Compiling ptc.pp
Compiling .\hermes\hermes.pp
Compiling .\win32\directx\p_ddraw.pp
ptc.pp(125,21) Fatal: Can't find unit glext used by ptc Fatal: Compilation aborted
make: *** [ptc.ppu] Error 1

There is one thing I am wondering about, I'm not sure if it's something that could be (or maybe already is) addressed with pctcrt. That is the typmatic keyboard rate. I wish it to be much faster than it is. I seem to remember that on DOS systems there was a way to set it, but on windows systems the only thing I can find is a control panel setting, which I maxed out but it's still not fast enough. Is there a way to override the typmatic repeat rate?

James

we've always set that in the BIOS of the machine... it is generally in the same area where you would toggle the numlock on at boot...

we've always set that in the BIOS of the machine... it is generally in the same area where you would toggle the numlock on at boot...

Thanks for the suggestion! I did not even think to look there.

James