Announcement

**Richard Angell** · 24 Oct 2008, 04:50 PM

(removed)

**Michael Mattias** · 24 Oct 2008, 05:29 PM

What is this "console window?" Some kind of dialog? Just a single STATIC or edit control?

There may already be a really easy way to determine what key(s) have been pressed in that 'console' window, rather than hoping and praying an unsupported use of the GRAPHIC INKEY/INKEY$ will work.

Not that I want to talk you out of Win/9, since so far I think it's pretty neat and I haven't really been all that excited about a new release since, oh, PB/DLL v 5 (welcome to 32-bit Windows!).

Oops, I take that back: I WAS really excited about PB/WIN 6.11, because that allowed the much much larger individual source code files. Let me cut one application down from thirty-some #INCLUDE files to five, all #INCLUDEd only because it was convenient, not because it was necessary based on capacity limitations.

**William Martin** · 24 Oct 2008, 05:51 PM

Originally posted by Michael Mattias View Post

What is this "console window?" Some kind of dialog? Just a single STATIC or edit control?

A console window is the text window you get with "AllocConsole". An example of its use can be found from Babakhanov at http://www.powerbasic.com/support/pb...ad.php?t=23272

There may already be a really easy way to determine what key(s) have been pressed in that 'console' window, rather than hoping and praying an unsupported use of the GRAPHIC INKEY/INKEY$ will work.

If you know of such a way I'd be interested to hear. I'm not much of a PB programmer, but all I know of involves a lot of screwing around with Windows APIs and such. Personally, I'd rather have the compiler take care of all that and just give me a simple INKEY$ to use like in the bad old days.

Bill

**Richard Angell** · 24 Oct 2008, 06:01 PM

I removed the former post because I had misread your earlier post.

You said " plain console window", which would indicate that you are not using a Graphic Window. Is that correct?

If so then the new GRAPHIC INKEY$ and GRAPHIC INSTAT functions are likely not going to help. This is because the GRAPHIC WINDOW, which works with these functions has its own internal callback function.

If you could post some code showing how you create the "plain console window", I mean is it a true console window created with SDK style programming or ?; then we could be of more help.

That said, there are plenty of posts in the PBCC forum showing how users are turning the Graphic Window to uses that you might have. If you are using a GRAPHIC WINDOW as if it were a "console window", then by all means use GRAPHIC INSTAT to see if the keyboard buffers has something that you can them remove and test with GRAPHIC INKEY$.

**Richard Angell** · 24 Oct 2008, 06:06 PM

Bill,
I see our posts crossed. So you will need to take another route and actually detect the key presses. I have to run, but there should be some code here or in POFFS. Check back later...

**Michael Mattias** · 24 Oct 2008, 06:12 PM

>If you know of such a way I'd be interested to hear.

You can detect a keystroke or mouse click using...
Wait for key, click or clock for PB/WIN and PB/CC

Should be all the code you need.

MCM

**Michael Mattias** · 24 Oct 2008, 06:16 PM

Or if you want to 'go deluxe'...

Use Listview control as a console. September 13 2003.

Just add a few lines of code for WM_NOTIFY/NM_CLICK and WM/NOTIFY/NM_KEYDOWN

MCM

**Richard Angell** · 24 Oct 2008, 06:45 PM

another small slice of console functions, Michael's may be more appropriate but just for compare, noting that you may want to look at these and related console functions and structures, including SetStdHandle ... as well as use a bit more logic than this simple demo does.

Code:

#COMPILE EXE
#DIM ALL
#INCLUDE "win32api.inc"

FUNCTION PBMAIN () AS LONG
    
    LOCAL dwIB,dwSB,recs AS DWORD, kbkeys AS INPUT_RECORD,thekey AS KEY_EVENT_RECORD
    LOCAL result AS LONG
    LOCAL msg AS ASCIIZ * 256
    AllocConsole
    dwIB = GetStdHandle(%STD_INPUT_HANDLE)
    dwSB = GetStdHandle(%STD_OUTPUT_HANDLE)
    msg = "Press a key to quit"
    WriteConsole(dwSB,msg,LEN(msg),LEN(msg),recs)
    DO
         PeekConsoleInput(dwIB,kbkeys,1,recs )
         IF kbkeys.EventType = %KEY_EVENT  THEN EXIT LOOP
    LOOP
    result = ReadConsoleInput(dwIB,kbkeys,1,recs )
    TYPE SET thekey = kbkeys.Event
    ? "you pressed a key with the value :" + FORMAT$(thekey.uChar) + $CRLF + CHR$(thekey.uChar)
    FreeConsole
END FUNCTION

**William Martin** · 24 Oct 2008, 10:31 PM

Originally posted by Michael Mattias View Post

>
You can detect a keystroke or mouse click using...
Wait for key, click or clock for PB/WIN and PB/CC

The thing is, this is literally 4 pages of code on my printer. INKEY$ used to be a one line solution. I'm sure that dinking with APIs lets one do strange and wonderful things. But I'm really just looking for dead simple - has a key been hit or not? And not wait for a key.

Nothing more than...

Code:

Do
  { Code Block }
loop while inkey$ = ""

I guess I'm coming from a different world view.

Bill

**William Martin** · 24 Oct 2008, 10:35 PM

Originally posted by Richard Angell View Post

Code:

    DO
         PeekConsoleInput(dwIB,kbkeys,1,recs )
         IF kbkeys.EventType = %KEY_EVENT  THEN EXIT LOOP
    LOOP

I'll look into this Richard. I don't know enough to understand it yet, but let me play with it some. It looks like what I'm after.

Thanks.

Bill

**William Martin** · 24 Oct 2008, 10:59 PM

Richard,

I copied your code to PB8. It compiles without complaint. When I execute, it brings up a console with the message "Press a key to quit", but then just loops forever. It does not seem to detect any key stroke.

Apparently I'm doing something wrong. I'm running PB8 under XP for what that's worth.

Bill

**William Martin** · 24 Oct 2008, 11:23 PM

Ok, I broke down and did what I should have tried to start with. I played with the GRAPHIC statements, even though I only need text. They do seem to work simply and are more direct than using the console. However it's not apparent to me how to get the text to scroll within the window.

If I GRAPHIC PRINT out more lines of text than fit the window, it seems to disappear off the bottom of the window rather than scrolling. Is this an inherent limitation of the GRAPHIC window, or have I overlooked a control somewhere?

Thanks.

Bill

**Dave Biggs** · 24 Oct 2008, 11:56 PM

I needed to make a couple of small changes to Richard's code when I tried it..

Code:

#COMPILE EXE
#DIM ALL
#INCLUDE "win32api.inc"
FUNCTION PBMAIN () AS LONG
 
    LOCAL dwIB,dwSB,recs AS DWORD, kbkeys AS INPUT_RECORD,thekey AS KEY_EVENT_RECORD
    LOCAL result AS LONG
    LOCAL msg AS ASCIIZ * 256
    AllocConsole
 '    dwIB = GetStdHandle(%STD_INPUT_HANDLE)
    dwSB = GetStdHandle(%STD_OUTPUT_HANDLE)
    msg = "Press a key to quit"
    WriteConsole(dwSB,msg,LEN(msg),LEN(msg),recs)
    dwIB = GetStdHandle(%STD_INPUT_HANDLE)            ' _After_ write operation
    FlushConsoleInputBuffer(dwIB)                     ' Add
    DO
         PeekConsoleInput(dwIB,kbkeys,1,recs )
         IF kbkeys.EventType = %KEY_EVENT  THEN EXIT LOOP
    LOOP
    result = ReadConsoleInput(dwIB,kbkeys,1,recs )
    TYPE SET thekey = kbkeys.Event
    ? "you pressed a key with the value : " + FORMAT$(thekey.uChar) + $CRLF + CHR$(thekey.uChar)
    FreeConsole
END FUNCTION

**Richard Angell** · 25 Oct 2008, 08:01 AM

Bill,

The code I posted always exits here. PBWin9.0/WinME

Rick

**Richard Angell** · 25 Oct 2008, 08:28 AM

Adding FlushConsoleInputBuffer(dwIB) can't hurt, if it is before the loop, but note that the input buffer can have more than keystrokes. I can hang the code by clicking or moving the mouse, for example, so the buffer would probably need to be flushed regularly

KEY_EVENT, MOUSE_EVENT, WINDOW_BUFFER_SIZE_EVENT, MENU_EVENT and FOCUS_EVENT are possibilities the code might need in some apps to cope with. In the simplified code below, I added the flush in the loop, but Bill what is going on in the program while you are waiting to see if the user has hit a key? If you are trying to trap a specific key or keys, then move the read inside the loop and examine there. See if this hangs on your system. note the SLEEP to allow the buffer to flush and not clog

Code:

#COMPILE EXE
#DIM ALL
#INCLUDE "win32api.inc"

FUNCTION PBMAIN () AS LONG

    LOCAL dwIB,dwSB,recs AS DWORD, kbkeys AS INPUT_RECORD,thekey AS KEY_EVENT_RECORD
    LOCAL result AS LONG
    LOCAL msg AS ASCIIZ * 256
    AllocConsole

    dwSB = GetStdHandle(%STD_OUTPUT_HANDLE)
    msg = "Press a key to quit"
    WriteConsole(dwSB,msg,LEN(msg),LEN(msg),recs)
    dwIB = GetStdHandle(%STD_INPUT_HANDLE)
    FlushConsoleInputBuffer(dwIB)
    DO
         PeekConsoleInput(dwIB,kbkeys,1,recs )
         IF kbkeys.EventType = %KEY_EVENT    THEN EXIT LOOP
         result = FlushConsoleInputBuffer(dwIB)
         'IF result = 0 THEN SLEEP 10    'PBWin 8
         SLEEP 0                        'PBWin 9
    LOOP
    result = ReadConsoleInput(dwIB,kbkeys,1,recs )
    TYPE SET thekey = kbkeys.Event
    ? "you pressed a key with the value :" + FORMAT$(thekey.uChar) + $CRLF + CHR$(thekey.uChar)
    FreeConsole
END FUNCTION

**Michael Mattias** · 25 Oct 2008, 09:12 AM

>The thing is, this is literally 4 pages of code on my printer

So instead of four pages make it one line:

Code:

#INCLUDE "WaitForKeyClickOrClock.inc"

The whole ideal of #INCLUDE files and libarary DLLs is that they contain fully-debugged code you never have to print out.

MCM

**William Martin** · 25 Oct 2008, 11:40 PM

The control structure I posted was definitely not looking to wait around for a key. It just wanted to know if one had been hit (i.e. was in the buffer) in order to exit a routine.

I'm going with the GRAPHIC INKEY$ approach I believe. I've ordered the software update, and when it comes I'll know for sure.

Thanks all...

Bill

**Michael Mattias** · 26 Oct 2008, 08:29 AM

>even though I only need text.

That being the case, you may wish to eschew the GRAPHIC WINDOW and just use a multi-line edit control instead.

Demo here: http://www.powerbasic.com/support/pb...ad.php?t=37555

**Richard Angell** · 26 Oct 2008, 11:42 AM

Bill,

If you have PBWin 8, you can do the Console Window in the interim. It will translate as-is with little if any changes into PBWin 9. However, from PBWin, you do have to use the API approach for trapping a keypress. Windows is even driven so you do need you check for events.

It just wanted to know if one had been hit (i.e. was in the buffer) in order to exit a routine.

So post the routine's code. It would seem that the routine might be looping so you could just do (or call a function to do) a check in that routine to exit. Or you could have a separate thread doing so, but I suspect that may be more than you want to deal with. So please show your routine's code and more help should be forthcoming.

Announcement

Graphic Inkey$

Graphic Inkey$

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment