Long time no see and Input Capture

[cameron]

Hey everyone, long time no see. Long story short I've been struggling with health issues and been busy with school and such the past what? a year or so... So I haven't had much time for fooling around on the forums or for programming. But I am back at it once again for the time being at least.

So I started fooling around with an old project of mine to get back into c++ a bit and am having some issues to say the least lol.

About the project:
It is an application to capture and record input and be able to store each recording in a data file for later playback. I wrote this over a year ago besides the modifications I made to it today... some new c++ 17 features I was trying and moving code from win32 to c++ standard calls.

In the future, I might create a UI and add additional features such as playback speed and option to set mouse cursor pos at the start.

Q1 ) I am new to the github ext for vs. I tried creating a repo with it and my .gitignore was messed up. (Didnt exclude *.vs, *.db, *opendb, /.vs, etc....) I tried the VisualStudio and c++ presets. Do you guys just create your own .gitignores? Thats what I ended up doing.

P1) WIndows.c++ (line 341) I can't seem to figure out why windows won't register a VK_ESCAPE with WM_KEYDOWN is not triggered when ctrl is pressed. Every other key combo ive tried is a non-issue but the ctrl + esc just isnt behaving as expected. I thought at first that this might be keyboard ghosting or smth similar; however, other applications can handle a ctrl + sec combo just fine. It all seems odd.

P2) Can't seem to get the program to close properly without aborting.
RawInp.cpp line: 81 - PostMessage(wnd, WM_CLOSE, NULL, NULL); causes abort() has been caused debug error.

P3) Closing the program manually instead of using key combo leaves application hanging. I had tried to debug this once a long time ago and it got really bad... Almost got into kernel debugging cause the issue was so buried. The issue is with closing the rawinp thread/window if I remember correctly.

Feel free to leave comments, questions, or suggestions. Oh, and forgive the mess of the project and lack of documentation.

https://github.com/BobsCrabShack/Input-Capture

[albinopapa]

Hey stranger, welcome back, glad to see you are doing better. I'll have to check this out later, with fresher eyes.

[albinopapa]

Where's your TranslateMessage(&msg);


LOL, typedef needs to die

Code: Select all

template<typename Rtn, typename... Args>
struct FPHelper
{
	typedef Rtn(*Function)(Args...);
};

Long live C++ using

Code: Select all

template<typename Rtn, typename... Args>
struct FPHelper
{
	using Function = Rtn(*)(Args..);
};

Ok, the typedef for function pointers is pretty straight forward, though when I first saw it, it didn't make sense what the f'ing alias name was. Using though, has the alias right there, Function. The typedef for type aliases though are a different story for me, always mix up the order.

typedef:
( I'm defining an alias for int, and you may refer to it as std::int32_t )
using:
( I'm defining an alias of std::int32_t for int )

[cameron]

Hey papa.

I don't have a TranslateMessage call in my message loop for handling raw input because I handle VK messages and don't want WM_CHAR messages appearing as well.

https://docs.microsoft.com/en-gb/window ... celeratora

If applications process virtual-key messages for some other purpose, they should not call TranslateMessage.

Regarding the typedefs, turns out I didn't even need those haha.

Code: Select all

template<typename Rtn, typename... Args>
using PFunc = Rtn(*)(Args...);

template<typename Rtn, typename O, typename... Args>
using PMFunc = Rtn(O::*)(Args...);

template<typename Rtn, typename O, typename... Args>
using PMFuncC = Rtn(O::*)(Args...) const;

Oh, and be careful running and recording something with this LOL. Sometimes key presses are still being held down and Ive done some strange crap to my pc because of it. Just yesterday that exact thing happened and now my audio sounds like it has some kind of mixer or equalizer on it... haha

-edit: It appears I have corrected this particular bug but who knows how many others there are.

[albinopapa]

I think you meant TranslateMessage, not TranslateAcceleratorA. Anyway, I've read that before, but I guess I never understood what it meant, cool.

Oh, snap, I had forgotten that typedef also didn't allow template aliases, that's why you needed the helpers, lol. Yeah, yet another reason C++ using was a better choice.

I have enough problems with my PC at the moment, not going to run some sketchy program . I'll still look through the code some more though.

[cameron]

Yeah, I meant TranslateMessage, not sure how I ended up copying the wrong link, but w/e lol

Haha, I don't blame you papa. Can't say this is the first time my own code has fowled up my pc tho. Back when I was working in D3D11 I got a black screen a few times with no way out of it. Had to reboot. *When your own code decides to screw up your pc* Wonder if anyone else has done silly stuff like this before lol.

I appreciate any insight you might have. Though, you won't get any issues if you don't record anything (and it is a lengthy process to do so atm, 4 key combo presses consecutively, so you won't end up doing it accidentally)

Hmm, turns out the non-termination issue with closing the window via the X was resolved by the WN32->c++ standard migration.

Just found the crash on program termination as well. Forgot PostMessage doesn't block. So the thread ended up dieing before resources could be freed.

Code: Select all

RawInp::~RawInp()
{
	PostMessage(wnd, WM_CLOSE, NULL, NULL);
	thrd.join();
}

That appears to fix the issue.

Now if I could just get the keyboard issue with certain keys resolved. In this last commit, I simply changed the key combo from VK_CTRL + VK_ESCAPE to VK_CTRL + VK_KEYDOWN and it works fine. It seems that the WM_KEYDOWN message for VK_ESCAPE appears after releasing it, which ofc makes ZERO sense. Maybe I'm missing something here... But I would like to figure out why it does not work and not simply work around it.

In the meantime, I'm gonna be thinking about where I want to take this project and perhaps refactor a lot of those messy classes (or possibly completely redo them). If you (or anyone) have any design ideas feel free to let me know. I'm hoping to scrap the text interface and implement a GUI but that will probably come last after I'm satisfied with the code and the bugs being fixed.

[Slidy]

I noticed for your StringHashMap class you're using an unordered_map with an EMPTY_STRUCT value type (https://github.com/BobsCrabShack/Input- ... hMap.h#L24).

Just wanted to point out that you can use unordered_set instead. It's just like unordered_map except it only stores keys, not values, so you won't need that EMPTY_STRUCT hack.

Another thing you could consider is removing the WinAPI directory traversal stuff and instead using the new std <filesystem> in File.cpp. The code will be a lot cleaner, but other than that I don't think there are any advantages so you'll have to decide whether it's worth your time to refactor it.

As for your Ctrl+Esc issue perhaps try using TranslateMessage and seeing if WM_CHAR messages have the same issue?

[cameron]

Done, and done. I figure its better to have native c++ code than win32 for the portability and readability. Didn't even know c++ had a filesystem library; goes to show how long I've been away. Thanks for the suggestions Slidy.

As far as the CTRL + ESC issue, I tried TranslateMessage and it didn't change anything. I am using rawinput anyways so it doesn't detect WM_CHAR messages.
Also, it seems that the program will not simulate certain key presses such as the windows key, alt + tab, etc...

-Edit: It turns out I forgot to handle the E0 prefix case for scan codes. Doing this made the windows key work. But others still don't work. I uploaded an image of the capture of trying alt + tab. It shows that a key down event is not being received but instead a key up event! This seems to be related to the CTRL + ESC issue.

Making progress!

[albinopapa]

Thought about mentioning the C++ filesystem, but didn't want you to feel like I was being nit picky, nice call.

What you have highlighted shows down is true, is this not what you wanted?
Are you caching results, as in first loop caches the ALT key, the second iteration checks for the Tab key? ( or same for Ctrl first iteration, Esc second iteration )?

[cameron]

Not exactly, the highlighted text just shows the first event in the alt + tab combo. SC 56 and 15 are alt and tab respectively. Regarding the caching, idk what you are asking.

I added the following debug tests to the top of the kbdProc and a tabkey down event is not seen when alt is being held down.

Code: Select all

	if (!(bool)(kbd.Flags & RI_KEY_BREAK) && (kbd.MakeCode == keys.VirtualKeyToScanCode(VK_TAB)))
	{

	}
	if (((kbd.Message == WM_KEYDOWN) || (kbd.Message == WM_SYSKEYDOWN)) && (kbd.VKey == VK_TAB))
	{

	}

On further review, it seems that checking the state of the tab key vs getasynckeystate will show the key as being up as well when the alt key is being held down. Is there something I am not understanding about windows input here?