RawInput /Raw Input / WM_INPUT Examples
Moderator: Moderators
RawInput /Raw Input / WM_INPUT Examples
This ftp site contains examples of how to access the 3Dx devices via Raw Input (WM_INPUT).
ftp:/ *** ***
login: ***
password: ***
Moderator Edit: the sample code is no longer available from the FTP service. Please contact 3Dconnexion API Support if you need further assistance.
ftp:/ *** ***
login: ***
password: ***
Moderator Edit: the sample code is no longer available from the FTP service. Please contact 3Dconnexion API Support if you need further assistance.
-
- Posts: 1
- Joined: Mon Jan 21, 2008 9:11 am
Connection closed by remote host.
Hi Ziva,
Is your FTP server still down? Or is it me?
Dan
Is your FTP server still down? Or is it me?
Dan
Hi,
I downloaded your examples and got an application working with the WM_INPUT and GetRawInputData technique.
Just out of curiosity, has anyone gotten GetRawInputBuffer working?
I coded it as best I could from the MSDN examples/documentation, but it only returns 0. There is very little additional information posted on other forums.
Dan
I downloaded your examples and got an application working with the WM_INPUT and GetRawInputData technique.
Just out of curiosity, has anyone gotten GetRawInputBuffer working?
I coded it as best I could from the MSDN examples/documentation, but it only returns 0. There is very little additional information posted on other forums.
Dan
Re: RawInput /Raw Input / WM_INPUT Examples
Hmm ... I could reach the ftp site with these details. When did you try it? Are you using an ftp client?ftp:/ *** ***
login: ***
password: ***
Moderator Edit: the sample code is no longer available from the FTP service. Please contact 3Dconnexion API Support if you need further assistance.
Uta
3Dconnexion
3Dconnexion
I would also be very much interested in an example for GetRawInputBuffer().
The problem with the SpaceNavigator, providing input data is, that it sends a lot of data, so using GetRawInputData() makes applications go on executing on this data from 1 up to 5 seconds after you pulled your hand of the device.
Does anyone have experience with this?
The problem with the SpaceNavigator, providing input data is, that it sends a lot of data, so using GetRawInputData() makes applications go on executing on this data from 1 up to 5 seconds after you pulled your hand of the device.
Does anyone have experience with this?
What about the Microsoft examples?
http://msdn.microsoft.com/en-us/library ... fered_read
You do have to structure your program so that you don't do something time consuming everytime you get a data packet. The device will flood you with data at about 60Hz and you will quickly fall behind. You need to eat through all that data before you go do something complicated.
http://msdn.microsoft.com/en-us/library ... fered_read
You do have to structure your program so that you don't do something time consuming everytime you get a data packet. The device will flood you with data at about 60Hz and you will quickly fall behind. You need to eat through all that data before you go do something complicated.
In some cases doing complex calculations can't be avoided.
If so, it shouldn't be a problem, if the RawInput is always read as the complete available Buffer and everything is processed together.
Using the buffer we can work all waiting input reasonably together to one input command and then process simply this command.
The problem I have right now is, how to access this Buffer. Using the example from Microsoft doesn't work for me as the method always returns zero (like drstine also mentioned).
If so, it shouldn't be a problem, if the RawInput is always read as the complete available Buffer and everything is processed together.
Using the buffer we can work all waiting input reasonably together to one input command and then process simply this command.
The problem I have right now is, how to access this Buffer. Using the example from Microsoft doesn't work for me as the method always returns zero (like drstine also mentioned).
I don't know what is wrong with their example (but there do seem to be some guesses in there about the amount of memory needed for the final call to GetRawInputBuffer). You'll have to take it up with them.
It does seems that they are just sitting in a loop collecting all the WM_INPUT events into an array for you each time you call GetRawInputBuffer. You could do that yourself, each time you get a WM_INPUT event (that is what we do in all our code).
if event == WM_INPUT
{
eventData = 0
while still WM_INPUT events in the message queue
{
eventData += next event data
}
Now that the message queue is empty, do something time consuming with eventData.
}
It doesn't seem much different from:
GetRawInputBuffer( buffer )
foreach(bufferEvent in buffer)
{
eventData += bufferEvent
}
Now do something time consuming with eventData.
You still have to go through all the events individually.
It does seems that they are just sitting in a loop collecting all the WM_INPUT events into an array for you each time you call GetRawInputBuffer. You could do that yourself, each time you get a WM_INPUT event (that is what we do in all our code).
if event == WM_INPUT
{
eventData = 0
while still WM_INPUT events in the message queue
{
eventData += next event data
}
Now that the message queue is empty, do something time consuming with eventData.
}
It doesn't seem much different from:
GetRawInputBuffer( buffer )
foreach(bufferEvent in buffer)
{
eventData += bufferEvent
}
Now do something time consuming with eventData.
You still have to go through all the events individually.