SiGrabDevice vs. the driver

Post questions, comments and feedback to our 3Dconnexion Windows Development Team.

Moderator: Moderators

Post Reply
KalleKoenig
Posts: 7
Joined: Fri Feb 14, 2014 7:49 am

SiGrabDevice vs. the driver

Post by KalleKoenig » Tue Jul 28, 2015 10:40 am

Hi support and developers,

The latest drivers for the space mouse have a new feature, as it seems: Whenever you click on an application that doesn't know the 3DxMouse interface, the driver will feed this application with scroll wheel events, if the mouse is hovering over the window of the application. As it seems. This means, that the driver does remove its focus from the previous 3DxMouse-aware application.
From my point of view, this somehow counteracts against the calls from the 3DxMouse aware application asking for focus by SiGrabDevice...

I've described our use case before, here is a copy of these two lines:
we have an application that consists of multiple executables, some of them are 3dx Mouse aware. In particular, we still have 32bit executables and 64bit executables representing the same part in our application and it might happen that the one or the other gets started. But there are also multiple 3D components that share tasks of displaying a model - depending on the view and users choice.

So this time, it is about those components that are not 3Dx Mouse aware. Those should not get the events (not even scroll wheel)... So actually, I've implemented in those components, that the other, 3D mouse aware application is triggered to ask for SiGrabDevice, whenever the focus is on that other component. But this somehow did not have the right effect.
Then, just for testing, I started to ask for SiGrabDevice every second.
I used the "3Dconnexion Properties" Dialog for verification, to which application the driver thinks to talk to.
Two observations:
a) By mimizing and unminimizung our framework (the outermost part is not 3D Mouse aware), the focus shifted to that framework executable. And it stood there, even though SiGrabDevice was triggered every second by the inner, 3D Mouse aware application. No events were received after unminimizing (clicking the application at the taskbar).
b) I also saw cases in which the "3Dconnexion Properties" Dialog did tell us that it is talking to the outer framework, still: events ended happily at the inner, 3D Mouse aware application.

With this scenario, here are my questions:
Should SiGrabDevice actually still work, despite the behavior of the driver, to switch its focus every time, another application gains the mouse and keyboard focus? Should it definitely work, if we call SiGrabDevice each second (we won't do this for the release, just for testing - I do observe a gap in response after each call - and this is totally understandable...)
Is there something, we can do in our setup? Does the "3Dconnexion Properties" Dialog always show the correct target?

Many thanks!
Cheers,
Kalle

jwick
Moderator
Moderator
Posts: 2544
Joined: Wed Dec 20, 2006 2:25 pm
Location: USA
Contact:

Re: SiGrabDevice vs. the driver

Post by jwick » Tue Jul 28, 2015 11:16 am

Hi Kalle,

I've found that SiGrabDevice only works correctly fairly recently. Make sure to download the latest driver (May-ish).
And also only a hard grab works. You should see log messages in the log file (3DxService.log) that explain what is happening. Your hard grab will stay in effect until either you release it or the registered (SiOpen) window goes away.

Jim

ThomasHenn
Posts: 2
Joined: Fri Aug 07, 2015 4:35 am

Re: SiGrabDevice vs. the driver

Post by ThomasHenn » Fri Aug 07, 2015 5:18 am

Hi,

we still work on the issue described by Kalle. As SiGrabDevice doesn't seem to work for us we are trying to find another solution.

Is it possible to remove the newly introduced default behavior from a non-3DxMouse-aware app so that no Mouse Wheel events are sent to it?

I observed that some 3Dconnexion apps behave that way. For example 3DxHome never receives Spacemouse nor Mouse Wheel events. So even if 3DxHome is active all Spacemouse events still go to the app that was active before 3DxHome was activated. And the 3Dconnexion Properties dialog still shows the former app's name.

If we could teach this behavior to all our non-3DxMouse-aware apps our problem would be solved.
...most likely...
...modulo unwanted side-effects...

Cheers,
Thomas

jwick
Moderator
Moderator
Posts: 2544
Joined: Wed Dec 20, 2006 2:25 pm
Location: USA
Contact:

Re: SiGrabDevice vs. the driver

Post by jwick » Mon Aug 10, 2015 11:24 pm

I would like to know why SiGrabDevice isn't working for you.

3DxHome and a few other applications have Cfgs that tell the driver to ignore them:

Code: Select all

	<CfgProperties>
		<Access>
			<ReadOnly>true</ReadOnly>
			<Hidden>true</Hidden>
			<Ignore>true</Ignore>
		</Access>
	</CfgProperties>
You can create Cfgs like this for any application. Save your cfg in %PROGRAMDATA%\3Dconnexion\3DxWare\Cfg and it will get used instead of the Cfg installed with the driver.

ThomasHenn
Posts: 2
Joined: Fri Aug 07, 2015 4:35 am

Re: SiGrabDevice vs. the driver

Post by ThomasHenn » Tue Aug 11, 2015 9:12 am

I don't know why SiGrabDevice doesn't work for us. It returns without an error but shows no effect. It only shows some effect if I call it with the exclusive flag.

I tried your Cfgs and they worked quite good. At least until I stopped and restarted the driver (using 3DxService.exe). Afterwards the driver simply ignored the Cfgs.

jwick
Moderator
Moderator
Posts: 2544
Joined: Wed Dec 20, 2006 2:25 pm
Location: USA
Contact:

Re: SiGrabDevice vs. the driver

Post by jwick » Tue Aug 11, 2015 11:38 pm

As mentioned above, only the hard grab (exclusive) works the way you expect. We use it in quite a few circumstances when a window is used for communication that is not a top level window. Since the window doesn't get focus it is difficult to determine which connection should be used.

As long as you accurately keep track of focus, having a hard grab is harmless. Even if you don't release the grab when your application exits, the window notices that your window disappears and deletes the grab.

Post Reply