How can I resolve a LNK2019 error from using FInputKeyManager?

Development Programming & Scripting
1

I’m using FInputKeyManager.GetKeyCodeFromKey() to get keycodes to pass to CoherentUI, but I’m getting that annoying linker error:

CoUITestFPSCharacter.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: unsigned short const * __cdecl FInputKeyManager::GetKeyCodeFromKey(struct FKey)const " (__imp_?GetKeyCodeFromKey@FInputKeyManager@@QEBAPEBGUFKey@@@Z) referenced in function "public: virtual void __cdecl ACoUITestFPSCharacter::Tick(float)" (?Tick@ACoUITestFPSCharacter@@UEAAXM@Z)

Usually this is because something hasn’t been included in the build file dependencies, but I’m including the InputCore module, which seems to be the relevant one. Is there a way to fix this? Or is this something that needs to be solved on Epics end?

My code looks like this:

int keyCode = *FInputKeyManager::Get().GetKeyCodeFromKey(cPressedKey);
2

#Key Code

if want you want is the key code, you can do this instead! no strange dependency issues

FKey MyKey = EKeys::S;
const int32 KeyHash = GetTypeHash(MyKey);

//Is this a letter?
if(KeyHash <= 787 && KeyHash >= 762) 
{
  //return lower case version of letter
  ClientMessage( MyKey.GetDisplayName().ToString().ToLower() );
}

PS: you should never use plain int, always int32, uint8, etc. This is a coding standard of UE4.

3

I think that works, but I actually have no way to confirm it since I can’t seem to select forms on my hud to input text, I’ll mark it as the answer once I ensure it works.

4

Apologies about that Ineni. It was recently pointed out that I neglected to actually implement that function.

You can see a proposed fix to fill that function in and the change I made for 4.2 to fix it here: https://github.com/EpicGames/UnrealEngine/pull/105

The KeyHash solution suggested by Rama won’t be stable. The type hash of an FKey is just the Hash of the FName stored in it and the Hash of a FName is its index. Since the FName indices are, for the most part, unstable (unless they are explicitly defined in UnrealNames.h) from run to run those indices might change.

KeyHashes exist, primarily, for efficient lookups in when using the object as the key in maps, putting them in sets, and the like, which is an inherently runtime behavior so it isn’t important that it be stable from run to run.

5

Dear Marc,

What then is the best way to isolate out which keys are “only numbers” or “only letters” ?

I cant use a switch case any more since the change to EKeys

Thanks!

Rama

6

No worries, I thought that might be the case Marc, do you know of any workarounds to get the key code or will I just have to wait?

7

Probably worth putting that in a separate question Rama, it’s not really relevant to this question and it’ll get more attention that way.

8

thanks for the suggestion Ineni!

But I was hoping to hear from Marc specifically, hoping he gets updates on this thread :slight_smile:

Yay for Marc Audy!

:slight_smile:

Rama

9

Alright, so as a workaround, I’m trying to use FInputKeyManager.GetKeyFromCodes() instead, and simply running through each integer to create my own keymap.

Here’s the code I’m using:

for (int i = 0; i < 2000; i++)
	{
		FKey tempKey = (FInputKeyManager::Get().GetKeyFromCodes(i, i));

		if (&tempKey != NULL)
		{
			keyCodeMap.Add(tempKey,i);
		}
}

My problem at the moment is that not every key seems to be found. For instance, the backslash and left bracket keys don’t show up for some reason…

Here’s the complete list of keycodes I get.

10

very interesting!

Thanks for sharing!

:slight_smile: