I am currently evaluating Remote Buddy, and the only thing that's preventing me from purchasing this wonderful program is the inability to use the Virtual Keyboard in combination with the Wii IR mouse mode.

I can activate and see the keyboard on the screen. The problem is that by default, and however much I customize the Virtual Keyboard behaviour, using the A button on the Wiimote never actually press the key that is being pointed at by the cursor; it presses the key that has the blue outline.

I can press the keys without any problem using my physical mouse to click on them, but the same cannot be done using the Wiimote.

I should note that when I'm not using the Virtual Keyboard, I can use the A button as a normal left click, or whatever I customize it to. And I have also attempted to set the A button as a left click in the Virtual Keyboard behaviour, as well as clearing the definition for the A button altogether, but I always get the same results.

Please let me know if I'm doing something wrong.

Other than that problem I'm having, it's a wonderful utility. 

thanks for asking.

In Remote Buddy, Actions can claim some button exclusively - which 
is, what the Virtual Keyboard does to allow users to

a) map every button for the virtual keyboard (i.e. cursor keys) while 
the Virtual Keyboard is not shown.

and at the same time

b) when the Virtual Keyboard is active, be able to navigate it and 
press keys - "A" in particular is assigned to press the selected key 
(surrounded by a blue border).

So, when the Virtual Keyboard is active, the navigation cross on top 
of the remote and its A and B buttons are overridden by it. The rest 
of the buttons can still be mapped however you want to map them, though.

By default, the left mouse button on the Wiimote is assigned to the 
"-" button next to the "Home" button on the Wiimote. So, if you press 
that button while hovering over a key, will press it.

That of course assumes, you did not change the mapping of that button 
in the global mapping table (=> you can reset it to defaults with one 
click in Preferences >Hardware > Ninte... > Globla mapping).

Hope that helps.

Best regards, 
Felix 

Okay, well after your explanation, I reset all of the mappings to their default. It worked precisely as you have described it and as I would expect it to. So hooray for that!

I do believe however, there is a bug with how the virtual keyboard interprets key presses if you have changed the global mapping of the Wii remote buttons. You see, I prefer to always use the A button as left click, and under both circumstances listed below, I cannot achieve the desired effect (to use the A button as left click).

Here is what I did:

- In the Virtual Keyboard behaviour button mapping: cleared the Button Mapping for the A button

- In the Global Mapping for the Wiimote to use the "A / Play/Pause" as a Left Click.

When I do this, and pull up the Virtual Keyboard, even when I'm pointing at a key, and press the A button, it still activates the highlighted key (which seems to be "P" by default).

I also tried the following (after reverting to default mappings):

- In the Global Mapping for the Wiimote: cleared all button mappings except for B (Open Remote Buddy menu) and Home (IR mouse mode on/off)

- In the Virtual Keyboard behaviour button mapping: changed the Button Mapping for the A button to "Left Click".

And then it still functions the same way.

In fact, no matter what I change the Button Mapping to in the Virtual Keyboard behaviour, it will ignore what I set the keys to, and behave like the default mappings. Even after restarting the app.

So I hope that helps: the app works fine with the defaults, which I find uncomfortable, and if I try to change the Virtual Keyboard behaviour mappings in several different ways, Remote Buddy always uses the default button mappings, even after I've changed them.

Thanks again! Hope I've been clear enough. 

This is not a bug, though, but a feature.

As soon as you reveal the virtual keyboard, it installs a hook in the 
mapping kernel to take over control over some buttons exclusively, 
ignoring any mappings. The background is that this way you can map 
your button as you wish while the virtual keyboard is hidden - and 
then to use the virtual keyboard intuitively with the buttons when 
the virtual keyboard is being shown.

So, this is what happens

Button press => 
Virtual Keyboard (active) - directly filtering out left, right, up, 
down, A, B buttons => 
BehaviourCore handles the rest of buttons, executing the actions as 
mapped.

Button press => 
[Virtual Keyboard (inactive) - no filtering, no hooks] => 
BehaviourCore handles the all of the buttons, executing all actions 
as mapped.

Meanwhile, even programming an exception for the Wiimote's B button 
(which is easy as each action also knows which remote control the 
button press comes from) would not be a generally workable solution, 
as there are lots of users out there not using the IR mouse mode at 
all, who'd no longer be able to use the VK then.

I'll keep thinking about solutions, though.

Best regards, 
Felix 

I have to admit, I find it unfortunate that the key mappings one enters for the Virtual Keyboard behaviour are only partially active when actually using the on-screen keyboard. To me this is what caused the most confusion because there was nothing that notified me as the user that this is the case.

The reason I feel it is important to set those key mappings is that by default, in all the Wii games I've played, the "A" button is for all intents and purposes the "Left-click" when pointing and clicking, and for selecting letters in on-screen keyboards. It's simply what I'm used to, and what I imagine other Wii players are as well.

I can understand the need for using the directional pad for those who don't use the IR mouse mode. But I have two ideas I'd like to propose as a middle ground:

A) Include a preference panel or additional behaviour which defines the keys which the "hook" reserves for the keyboard when it is active. Basically you would have "Virtual Keyboard (Open)" and "Virtual Keyboard (Closed)" behaviours, or whatever you would prefer calling them.

or:

B) If mouse movement is detected while the virtual keyboard is open, then the virtual key which is moused over automatically becomes "highlighted" (given the blue outline). This way, "A" and the other keys included in the "hook" can continue to have their default behaviour.

Well, that's it. Thank you for hearing me out, and I hope I've given you some ideas on how to solve this issue and keep all your users happy.

Thanks again! Take care!

Last edited: 14.06.2007 22:28:02 

Best regards, 
Felix 

- Rick 

Best regards, 
Felix