Windows 10 Window Close

[k6sti]

My 32-bit console program detects the two-character window-close signal INKEY$ returns. It works in Windows XP but not Windows 10. In Windows 10, clicking on X closes the window without sending anything to INKEY$. The program uses QB mode. Is something special needed to make this work in Windows 10?

Brian

[fxm]

Can you provide a short code to highlight your problem?

I thought if clicking on the close button of the window, <Chr(255) + "k"> was returned only if a graphics mode had been defined via the Screen[Res] instruction.

[counting_pine]

Could it be that you're checking for Chr$(255)+"k" instead of Chr$(0)+"k"? QB has historically used 0, but FB switched to 255, due to quirks with the Null character.
This code should work:

Code: Select all

'$lang: "qb"
screen 13
print "Press the X to close"
do
    sleep
loop until inkey$ = chr$(0) & "k"

If you plan to work in other dialects (e.g. fblite/fb), I guess a portable way of checking for a specific extended code like this would be to check if e.g. mid$(inkey$, 2, 1) = "k".

[k6sti]

INKEY$ returns nothing when I click on window close in Windows 10. I do not have a SCREEN statement because I do not need graphics mode. I tried adding SCREEN 0. It did not help.

Brian

[counting_pine]

OK.. Can you post some example code, as fxm suggests? That would help us all to be on the same page.
For me on Windows 7, the console 'X' button actually just closes the program immediately. I'm not even sure if it has a chance to register the button is clicked.

[fxm]

I thought if clicking on the close button of the window, <Chr(255) + "k"> was returned only if a graphics mode had been defined via the Screen[Res] instruction.

[counting_pine]

I tried adding SCREEN 0. It did not help.

Oh, I forgot to mention - Screen 0 exits the graphics screen (if any) and uses the console, so it doesn't actually count as a Screen mode.

[k6sti]

This is the routine that waits for a keystroke or mouse event. (The indenting doesn't display as written.) If I add code to print key$ with a 1-second delay so that I can see it, any key I press gets displayed. However, clicking on window close prints nothing and closes the window.

I commented out everything between DO and key$ = INKEY$ in case it was somehow gobbling up the window-close sequence. That didn't help.

This routine works fine in Windows XP but not Windows 10.

Brian

Code: Select all

getmk:	DO
	  __SLEEP 1		' Give up time slice
	  jlb = ilb
	  jrb = irb
	  jwb = iwb
	  wlast& = w&
	  IF __GETMOUSE(x&, y&, w&, b&) = 0 THEN
	    ilb = b& AND 1
	    irb = b& AND 2
	    iwb = b& AND 4
	    icl = ilb AND NOT jlb	' Left click
	    icr = irb AND NOT jrb	' Right click
	    icw = iwb AND NOT jwb	' Wheel click
	    iwhl = w& - wlast&
	  END IF
	  key$ = INKEY$
	  IF MID$(key$, 2) = "k" THEN RETURN quit
	LOOP WHILE (icl OR icr OR icw OR iwhl OR LEN(key$)) = 0
	RETURN

[fxm]

I do not remember how it worked precisely on Windows XP (for a console window).

[k6sti]

The reason the program detects window close is so it can write its state to a small binary file. When restarted, the program reads the file to restore the previous state. For now I've decided to just write the file any time the state changes. That's a kludge, but the overhead is negligible and it solves the problem.

Brian

[counting_pine]

Hmm, I guess Microsoft may have changed their policy on terminating console programs over different versions over the years..
Searching the wider Internet finds questions like https://stackoverflow.com/questions/285 ... ole-window, which generally seem to suggest using SetConsoleCtrlHandler in C-like languages.

Searching our forum for that function turns up a thread about handing abnormal termination.

I think the main takeaway there is from dkl: basically, that FB is apparently already using this function to generate Inkey events, but that it may not be reliable, and he suggests trying to create an hidden window for this purpose.

[counting_pine]

Actually, looking at https://stackoverflow.com/questions/285 ... ole-window, you can do processing/cleanup in the error handler, but when the program closes when the handler finishes, so FB's handler that sends keys to the Inkey buffer would be ineffectual.

Anyway, I've done a crude FB example based on the code in the question:

Code: Select all

#include "windows.bi"

function ctrl_handler(byval event as DWORD) as BOOL
    select case event
    case CTRL_CLOSE_EVENT:
        '...
    'case ...
    '...
    end select
    messagebox 0, "Bye!", 0, 0
    return FALSE
end function

SetConsoleCtrlHandler(@ctrl_handler, TRUE)
do: sleep 1: loop

On Windows 7, when exiting I get a message box saying "Bye!".
If I clicked the 'X', it will only stay up for about 5 seconds; if I terminated with Ctrl-C, it will stay up for longer. I haven't tested other methods (e.g. logoff).

[counting_pine]

Hmm, lang qb doesn't allow me to declare SetConsoleCtrlHandler() properly (it requires '__extern "Windows"', which apparently isn't allowed).
Therefore, lang qb code will probably have to use a second file for the error handler.

Code: Select all

'' handler.bas
#lang "fb" '' override '-lang qb' parameter

declare sub cleanup() '' must implement a cleanup() subroutine in main program

#include "windows.bi"

function ctrl_handler(byval event as DWORD) as BOOL
    cleanup()
    return FALSE
end function

sub setup_handler() constructor
  SetConsoleCtrlHandler(@ctrl_handler, TRUE)
end sub

Should be able to compile this with something like: fbc -lang qb mymainprogram.bas handler.bas