After Ctl+Alt+Delete is pressed, continous Alt key is sent

[lassar]

Did Ctrl+Alt+Delete, to get to task manager, to check memory use.

Been using multikey to detect Alt key press.

Either Windows 10 has a bug after pressing Ctrl+Alt+Delete, or there is
a problem with multikey.

I tried several other alt key combinations, and can't get any continuous
alt key presses.

It only does it on Ctrl+Alt+Delete.

The work around is to press the same Alt key you used in Ctrl+Alt+Delete.

Here's the test code.

After the program is running, press Ctrl+Alt+Delete, then bring the test
window back up.

Let me know what results you get.

Code: Select all

#LANG "fblite"

ScreenRes 640, 480, 8
Do
    Dummy% = GetMouse (x%, y%, , Button%)
    ControlKey% = MultiKey(&h38)
    PRINT "ControlKey% = ";ControlKey%
Loop UNTIL Button% > 0
SLEEP 7000
End

[fxm]

Same behavior with Win10.

[badidea]

Can't reproduce on linux. Whats happens on e.g. ALT+TAB?

[fxm]

Whats happens on e.g. ALT+TAB?

No problem.

[grindstone]

No problems here with WinXP and "Process hacker" (instead of task manager) installed.

[coderJeff]

Same behaviour with win7. On windows, MULTIKEY is really just a call to short GetAsyncKeyState(int vkey). There's no magic; it's as close to the WIN API as you can get. It appears that ALT key gets "stuck", if ctrl+alt+delete is followed by Task Manager, or Lock This Computer. And not a problem if ctrl+alt+delete, followed by Cancel or Switch User. I don't think there will be any fix for this behaviour.

[Pierre Bellisle]

On my Seven machine,
if the MultiKey console window have focus,
the LeftMenu(Alt) pushed key down is detected,
the going up key release is not always detected,
probably because it occur while the ctrl-alt-del screen is active and it's a barrier to MultiKey.

If the focus is on another window,
the LeftMenu(Alt) key up seems to be always detected on my pc.
Using GetAsyncKeyState(VK_MENU) always return a good status.

Code: Select all

#Include Once "Windows.bi"
#LANG "fblite"
ScreenRes 640, 480, 8
Do
    Dummy%      = GetMouse (x%, y%, , Button%)
    'SLEEP 2
    ControlKey& = MultiKey(&h38) 'LeftMenu(Alt) 56dec 0x38: 20380001-LeftMenuDown, C0380001-LeftMenuUp
    PRINT "ControlKey& = "; ControlKey&, " GetAsyncKeyState"; GetAsyncKeyState(VK_MENU)
Loop UNTIL Button% > 0
SLEEP 2000
End

[coderJeff]

Thanks, Pierre. I missed seeing the real problem and your tests helped me realize that.

There are several versions of MULTIKEY.

CONSOLE uses GetAysncKeyState() - OK
FBGFX/GDI uses GetKeyboardState() - OK

FBGFX/DirectX uses IDirectInputDevice_GetDeviceState() - Not OK

I think problem appears to be only with FBGFX/DirectX version.
Which might be used if running fbc-32bit on win-64bit.

[fxm]

BTW:
For Windows, why not set GDI by default for fbc-32bit because it's the only one available for fbc-64bit?

[St_W]

Probably because GDI is usually considerably slower than DirectX/OpenGL. I don't know however, how that influences the speed of FB's gfxlib2. Did anyone do some benchmarks of the different rendering backends?

[coderJeff]

Currently, for our gfxlib2, looks like
fbc-32 on win32 - DirectX - OK
fbc-32 on win64 - DirectX - breaking
fbc-64 on win64 - DirectX - broken, I think. See here

Maybe a run-time check? Is there a win32 api call that can determine if the host windows is 32 or 64bit?
GDI should be the default always in 64bit until we have an alternative I think.

[jj2007]

Is there a win32 api call that can determine if the host windows is 32 or 64bit?

- is any 64-bit process is running, e.g. C:\Windows\SysWOW64\cmd.exe?
- folder C:\Windows\SysWOW64 exists?
- environment variable %PROCESSOR_ARCHITEW6432% is AMD64?
- environment variable %ProgramFiles(x86)% is set?

Somewhat simpler:

Code: Select all

#include "Windows.bi"
function Os64() as ulong
  Dim as integer hKernel=LoadLibrary("Kernel32")
  Dim as integer Is64=GetProcAddress(hKernel, "IsWow64Process")
  FreeLibrary(hKernel)
  return Is64
end function

if Os64() then
	print "it's a 64-bit OS"
else
	print "it's a 32-bit OS"
endif
sleep()

[paul doe]

Somewhat simpler:

Nice! A very small correction if I may, to avoid a myriad of warnings:

FbTemp.bas(3) warning 5(0): Implicit conversion
FbTemp.bas(4) warning 1(1): Passing scalar as pointer, at parameter 1 of GETPROCADDRESS()
FbTemp.bas(4) warning 5(0): Implicit conversion
FbTemp.bas(5) warning 1(1): Passing scalar as pointer, at parameter 1 of FREELIBRARY()

Code: Select all

function Os64() as boolean
  var hKernel = LoadLibrary( "Kernel32" )
  var Is64 = GetProcAddress( hKernel, "IsWow64Process" )
  FreeLibrary( hKernel )
  
  return( cbool( Is64 <> cptr( any ptr, 0 ) ) )
end function

[jj2007]

Nice!

Thanks, Paul. Unfortunately, I just found out that it won't work, see Detect if your Windows version is 32- or 64-bit for the reasons and alternatives. Umpffff....

[Josep Roca]

In Windows, WMI is a great technology to retrieve all kind of hardware information. Using the CWmiServices class of my WinFBX framework, it has been a piece of cake to write a function to retrieve the OS bitness.

Code: Select all

' ========================================================================================
' Returns the address width of the operating system.
' On a 32-bit operating system, the value is 32 and on a 64-bit operating system it is 64.
' ========================================================================================
PRIVATE FUNCTION AfxGetWindowsBitness (BYREF wszServerName AS WSTRING = ".") AS LONG
   DIM pServices AS CWmiServices = $"winmgmts:{impersonationLevel=impersonate}!\\" & wszServerName & $"\root\cimv2"
   IF pServices.ServicesPtr = NULL THEN RETURN 0
   pServices.ExecQuery("SELECT AddressWidth FROM Win32_Processor")
   pServices.GetNamedProperties
   RETURN pServices.PropValue("AddressWidth").ValLong
END FUNCTION
' ========================================================================================