Rif.: Has EVENT_KEYPRESS changed behavior with UTF-8 ?

[gdargaud]

Hello all,

I converted a project to UTF-8 to try it out.

Since then (I think), my callback functions that accept some keypresses don't work anymore. I haven't looked at all the options, but for instance, if I press [Ctrl-d], instead of receiving (VAL_MENUKEY_MODIFIER | 'd') in eventData1, I receive ((1<<29)|'d').

I see no reference to this 29th bit in the documentation nor the userin.h file.

Anybody noticed that ?

[RobertoBozzolo]

Hi, I stopped using macros to discriminate keys pressed when I got in touch with these functions:

virtualKey = GetKeyPressEventVirtualKey (eventData2);
modifierKey = GetKeyPressEventModifiers (eventData2);
if (virtualKey == 'd' && modifierKey == VAL_MENUKEY_MODIFIER) {	// Ctrl+D
    // Your code here
}

I'm not yet using UTF8 till now, but I would try and see if these functions work correctly in this scenario.

[gdargaud]

Hah, thanks, I never paid attention to those functions... But reading the help files (sometimes that helps!!!) about EVENT_KEYPRESS, the behavior has indeed changed with UTF-8, so even those functions need to be used differently.

So now the question becomes: how do I discriminate at runtime between UTF-8 and ANSI executable. I did not seen a macro for that, and neither a function, but I probably missed it. Just checking the version number is not sufficient (and why is version number of CVI 2020 being 2000 ?!?)

[rolfk]

---

@gdargaud wrote:

So now the question becomes: how do I discriminate at runtime between UTF-8 and ANSI executable. I did not seen a macro for that, and neither a function, but I probably missed it. Just checking the version number is not sufficient (and why is version number of CVI 2020 being 2000 ?!?)

---

It likely depends how you got this version number but I would not be surprised if this is an integer that is formatted a bit like this:

MM.m.f       with MM being the major version and m the minor and f the bugfix release. And it could be in hexadecimal format.

[gdargaud]

Well, I don't see how a _CVI_ equal to 2000 can be made to fit a 2020 version, even doing some weird MM.m.f hex tricks...

Anyway, that's not really the point, and I just found a macro called CVI_UTF8 active when UTF-8 is enabled, so I should be able to work with that.

[rolfk]

---

@gdargaud wrote:

Well, I don't see how a _CVI_ equal to 2000 can be made to fit a 2020 version, even doing some weird MM.m.f hex tricks...

---

Maybe you can't. I can!

If you program in Visual C there is a Macro called _MSC_VER, its value is an integer that when interpreted as hex integer tells the major and minor version of the Microsoft C compiler (which is not the same version as the Visual Studio version that you use the C compiler in).

Or the LabVIEW internal version number for instance is:

decimal:          402751505

hexadecimal:  0x18018011

and it means: version 18.0, subversion 1 (SP1), bugfix 4, build 17

In marketing language: LabVIEW 2018SP1 f4.

Which is why I asked which version number you were referring to. LabWindow\CVI uses a similar version scheme internally as LabVIEW, the 20xx version numbers were just a marketing naming scheme that came much later (around 2009 NI started with that, and since then the internal version corresponds to the year after the new millenium start).

So if you use one of the precompiler macros (_CVI_ maybe?) to determine the version number, you are NOT getting the year but a number whose first two digits in hex are the major version (that happens to correspond to the two digit year in the marketing version term but doesn't necessarily have to), and the next two digits indicate the minor version number and bugfix release. 

Read this link about the version identifier in LabWindows/CVI which explains why 2000 actually means LabWindows/CVI 2020.

[gdargaud]

Roberto, I think it's time to upgrade your keypress code !

The following works both in ANSI and UTF-8 (no need for a macro):

// Note, you can use the macro CVI_UTF8 to know if a CVI 2020 exe is in UTF-8
// but this code should work in both ANSI and UTF-8
int MyChar=0;
if (KeyPressEventIsLeadByte(eventData2)) return 0;
int modifierKey = GetKeyPressEventModifiers(eventData2);
if (modifierKey<0) return 1;
int virtualKey = GetKeyPressEventVirtualKey(eventData2);
if (virtualKey<0) return 1;
if (virtualKey==0) {
		int Key=GetKeyPressEventCharacter (eventData2);
		if (Key<=0) return 1;
		MyChar=(       Key | modifierKey);
}
else MyChar=(virtualKey | modifierKey);

switch (MyChar ) {
	// Ctrl-Shift--> or Ctrl-]
	case VAL_SHIFT_AND_MENUKEY | VAL_LEFT_ARROW_VKEY:
	case VAL_MENUKEY_MODIFIER | '[':
	...
}

[gdargaud]

---

So if you use one of the precompiler macros (_CVI_ maybe?) to determine the version number, you are NOT getting the year but a number whose first two digits in hex are the major version (that happens to correspond to the two digit year in the marketing version term but doesn't necessarily have to), and the next two digits indicate the minor version number and bugfix release. 

Thanks Rolfk. That's clear(ish). But nowhere in the link you give (and which I'd read before) does it mention this.

[rolfk]

---

@gdargaud wrote:

---

So if you use one of the precompiler macros (_CVI_ maybe?) to determine the version number, you are NOT getting the year but a number whose first two digits in hex are the major version (that happens to correspond to the two digit year in the marketing version term but doesn't necessarily have to), and the next two digits indicate the minor version number and bugfix release. 

Thanks Rolfk. That's clear(ish). But nowhere in the link you give (and which I'd read before) does it mention this.

---

Are you seriously telling me that after reading that link, you thought that _CVI_ being defined as 1500 means that the software was released in the year 1500? That would be a phenomenal time paradox. 😀

The real documentation about the predefined macros is here actually, which then links to the link I mentioned earlier and which explains about how the major.minor.tiny format still applies for year based versions. Yes there might be more extended prosa to explain all the versions that CVI has seen, but that would get also very wieldy quickly and be one more place that needs to be updated with each release, so sometimes less is more. The principle is quite clearly visible in those two links and requires not that much deductive ability to extend to other versions.