VOIP while a dialog is up

[JB47394 30]

Can I control the way keyboard and mouse events pass through my dialog to ARMA, or will they always be blocked?  ARMA seems to let a couple keys through custom dialogs ("/" and "U"), but I can't find anything that lets me selectively pass key and mouse events.

 

I'm trying to make sure that players can continue to use game VOIP while looking at my dialogs.  Unfortunately, both keyboard and mouse buttons are being blocked.  So while they have a dialog up, they're unable to speak, which is unacceptable for a multiplayer mission.

 

I notice that the inventory interface uses some keys for inventory functions while letting others through (e.g. movement with the keyboard - and VOIP).  Can I do something to my dialogs to duplicate that behavior?

[das attorney 858]

Read this page:

 

https://community.bistudio.com/wiki/User_Interface_Event_Handlers

 

Specifically, the info under "Script defined events" and it's relationship to dialogs/controls

 

The bit you'll be interested in is the return from the function (shown there as _handled)

 

iirc correctly, false lets the keystroke do it's default arma keybinding (as well as whatever you code in), and true blocks it.  It's very handy.

 

 

[JB47394 30]

On 9/6/2017 at 5:22 PM, das attorney said:

iirc correctly, false lets the keystroke do it's default arma keybinding (as well as whatever you code in), and true blocks it.  It's very handy.

 

Would that it was that easy.  Dialogs are modal, interpreting inputs with a different set of bindings.  Those bindings are structured to permit navigation of the dialog's contents and nothing else - except as I noted above.

 

In contrast, Displays are not modal and so there's no change in bindings and VOIP works perfectly well.

 

Mostly, Bohemia just needs to correct this oversight as VOIP has nothing to do with the modality of an interface element.

[das attorney 858]

Yeah I just tried it and couldn't access voip either when in a dialog, but as you mention, typing messages works fine.

 

One for the feedback tracker then I suppose.

[soolie 189]

1 hour ago, JB47394 said:

 

Mostly, Bohemia just needs to correct this oversight as VOIP has nothing to do with the modality of an interface element.

Except that the caps lock button is the default for VOIP and also (possibly) necessary for dialog controls like RscEdit

[bad benson 1733]

the difference between the inventory and common script induced dialogs is that it is a display and not a dialog. don't expect that to make sense right away in terms of terminology. just look here.

 

https://community.bistudio.com/wiki/createDialog

 

VS

 

https://community.bistudio.com/wiki/createDisplay

 

i never fully tried this one except for some arma 2 experiments. but i remember it having certain quirks. should be easy to find out though.

 

as you have noted the inventory allows certain functions including movement. i think its behaviour is pretty much what you can expect from createDisplay. although there are some config parameters to research too that might allow you to disable movement but keep VOIP possibly, if needed.

[JB47394 30]

Here it is nearly a year later and I was revisiting this problem when @bad benson 's comments finally sunk in.  The solution is, indeed, to go with a display instead of a dialog.  I was tripping over the fact that I use cutRsc and createDialog throughout my current codebase, and always equated cutRsc with displays.  But they're not the same.  A cutRsc doesn't catch keyboard and mouse events at all.

 

So conceptually I just needed to switch from dialog to display.  At the code level, I had to change createDialog to createDisplay, and I also had to make sure that my control references were explicit to a specific display instead of implicit to the current dialog.  In other words, I had to convert things like "lbCurSel 1400" to "lbCurSel ((findDisplay 800) displayCtrl 1400)", where 800 is the IDD of my display.

 

Beyond that, there may be some gotchas that I haven't picked up on yet.  The keyboard events pass through the display if they're not explicitly intercepted, and that may mean that the player may be able to do certain things that aren't compatible with my display.

 

Belated thanks, @bad benson.