qnamespace.h enum Key needs Key_None

Discuss anything related to product development
Post Reply
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

qnamespace.h enum Key needs Key_None

Post by seasoned_geek »

All,

The Key enum in qnamespace.h needs either a Key_None or Key_NULL with value 0x00000000.

It's an initialization thing. These things are all getting thumped into integers and C/C++ developers long ago made peace with no negative enums (well, some did) but without a Key_None or Key_NULL there is no safe initialization value. One has to initialize with a key that was never hit when using only enum values.
barbara
Posts: 447
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: qnamespace.h enum Key needs Key_None

Post by barbara »

The value Key::Key_unknown is normally used as the initial value to represent an invalid key. Is there any reason this will not work for you?

Barbara
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: qnamespace.h enum Key needs Key_None

Post by seasoned_geek »

barbara wrote: Sun Sep 11 2022 7:16 pm The value Key::Key_unknown is normally used as the initial value to represent an invalid key. Is there any reason this will not work for you?

Barbara
The short answer is yes.

Most everything else one interfaces with needs an enum value of 0 for "unknown". I understand the concept of wanting to use HIGH-VALUES for a boundary. I used it in COBOL a lot. The rest of the world doesn't know COBOL so it uses 0x00 for uninitialized scan codes. When you get into various Mandarin or extreme gamer, or specialty (think Point of Sale) keyboards, it is entirely possible to run into HIGH-VALUES as a valid scan code. It's not possible to run into a NULL. I forget the reason. Something to do with the drivers for the various chip sets. They do not allow a NULL or it has a special purpose. At any rate, last time I went that close to the hardware there was a legit reason to not allow NULL through, just don't remember what it is.
Post Reply