219 replies to this topic

[evilc]

surely the function HID.HidP_GetCaps can return whatever I like?

	HidP_GetCaps(ByRef PreparsedData, ByRef Capabilities){
		/*
		https://msdn.microsoft.com/en-us/library/windows/hardware/ff539715%28v=vs.85%29.aspx
		
		NTSTATUS __stdcall HidP_GetCaps(
		  _In_   PHIDP_PREPARSED_DATA PreparsedData,
		  _Out_  PHIDP_CAPS Capabilities
		);
		*/
		Capabilities := new _Struct("WinStructs.HIDP_CAPS")
		r := DllCall("Hid\HidP_GetCaps", "Ptr", &PreparsedData, "Ptr", Capabilities[])
		if (r = this.HIDP_STATUS_SUCCESS){
			r := 0
		} else {
			MsgBox % r
			r := -1
		}
		If (r = -1) Or ErrorLevel {
			soundbeep
			ErrorLevel = %A_ThisFunc% call failed.`nReturn value: %r%`nErrorLevel: %ErrorLevel%`nLine: %A_LineNumber%`nLast Error: %A_LastError%
			Return -1
		}
		return r
	}

The Dll Call may return HIDP_STATUS_SUCCESS, but the function does not need to, surely?

[HotKeyIt]

Of course, sorry I have not seen your changes in CHID.ahk.

This should be ret not r, right? That is why I asked you what HidP_GetCaps returns:

    ret := HID.HidP_GetCaps(PreparsedData, Caps)
    if (r = -1){
        return
    }

I would rather suggest to return 1 on success and do

If !HID.HidP_GetCaps(PreparsedData, Caps)
  return

[evilc]

Oops, yeah, clearly a typo. Sorry. It doesn't stop the crashes though...

 

The reasoning behind keeping the Dll return value was that the functions which purely map to Dll Calls should return what the API call returned.

 

When I get around to adding helper classes to simplify the whole process, I will use proprietary return codes (ie 1 is success).

[HotKeyIt]

So back to my question does it return HIDP_STATUS_SUCCESS or something else and if so, what?

[evilc]

It currently returns 0 for success, -1 for fail.

[HotKeyIt]

There must be something wrong with the data or pointers.

Can you check all return values for dll functions. E.g: GetRawInputDeviceInfo.

 

 

Return value

Type: UINT
If successful, this function returns a non-negative number indicating the number of bytes copied to pData.
If pData is not large enough for the data, the function returns -1. If pData is NULL, the function returns a value of zero. In both of these cases, pcbSize is set to the minimum size required for the pData buffer.

So -1 means pData is not large enough which is never the case since we check the size before.

You need to check for all negative values instead!

  If (r < 1) Or ErrorLevel {
	soundbeep
	ErrorLevel = %A_ThisFunc% call failed.`nReturn value: %r%`nErrorLevel: %ErrorLevel%`nLine: %A_LineNumber%`nLast Error: %A_LastError%
	Return -1
  }

Also RegisterRawInputDevices returns true if successfull or 0 when failed so r = -1 should be if !r

[evilc]

Of course, what is going on is that the RAWINPUT struct is not working properly, as I have not yet addressed the issue of how to deal with the named "data" union.

Yes, I may be getting info out of it, but it is incorrect (as I observed with my "is it bit-shifted"?) comment.

This now seems incorrect. The only thing I am pulling from the RAWINPUT struct is the device handle, and seeing as the line if (!handle || handle != SelectedDevice){ checks if the message came from the device selected in the listview, we can be sure that data is correct.

No other part of the RAWINPUT struct is used.

 

We know GetRawInputDeviceInfo and later Dll Calls are good, as they are used earlier in the code to decode the joystick capabilities.

This is now under question.

 

It has also occurred to me of course that you don't need a joystick to be able to play with the code as long as you are willing to install the vjoy driver, of course.

The simple example script for CvJoyInterface lets you control the virtual stick with F10-F12.

 

I see you are online, so I am gonna post now and continue in another post...

[evilc]

OK, so going back and reading what you were saying about the data sub-union in a RAWINPUT structure, is there no way of avoiding having to name the properties like data_hid_bRawData ?

As I said, speed is not primary concern at the moment, readability / usability is - so is there any way to emulate this named sub-union such that I can use data.hid.bRawData?

[evilc]

Hmm, I just found something out that possibly explains why I was getting so confused here.

It seems that trying to debug this code with SciTE can cause it to crash, whereas the code may actually be OK.

So this was giving me false positives on what the cuases of the crashes were.

[evilc]

I also realized that AHKHID has previously done this part of the process (Performing a GetRawInputData call on a WM_INPUT's lParam), so I went and plugged AHKHID into the code for the first step, then handed off to my code for the next step (GetRawInputDeviceInfo passing RIDI_PREPARSEDDATA).

 

It works, no crashes.

 

So this proves that the problem lies with the GetRawInputData() function and/or the code that calls it.

 

Basically, the call that obtains the device handle is not working properly, as that is the only thing I replaced with AHKHID.

 

Commit is here. Gonna go to bed, will pick this up tomorrow.