ToolData::KeyboardInput
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 31/08/2006 at 20:11, xxxxxxxx wrote:
User Information:
Cinema 4D Version: 9.102
Platform: Windows ; Mac OSX ;
Language(s) : C++ ;---------
What use is this method - at all? It only seems to work if the tool is active and selected in the AM - otherwise there is an extremely successful probability of crashing C4D because the key does something else if these conditions aren't fully met.The documentation says:
Make sure that you only use this function when the user is somehow working with your plugin, so that other plugins can also use this hook when it's their turn.
How do you absolutely guarantee that the 'user is somehow working with your plugin' if the conditions that I saw exist? There are no other active tools - it can crash. Using and gobbling the expected keys doesn't guarantee anything - there is most definitely a focus problem with keyboard input. If my tool is active - screw the universe!!! I get first dibs - hands off and I won't go further on a linguistic rampage...
So, do I delete the ToolData::KeyboardInput() method as useless and potentially dangerous or is there a way to avoid it (remember, users aren't automatons)?
Thanks,
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/09/2006 at 00:22, xxxxxxxx wrote:
Not sure myself, i think it just captures keypresses before Cinema has a chance to handle them. If you wish to igrore them, return FALSE.
I also can't make sense out of that sentence in the docs.
As usual, whenever your tool has some internal data then depends on the scene, you must check if the data is still valid. For examples, pointers to objects.
The function is used in the knife tool for example. When you use the click-drag-click behavior, you can aboart with the ESC key. It's the responsibility of the plugin to handle this. Sort of like this
Bool Mws::KeyboardInput(BaseDocument* doc, BaseContainer& data, BaseDraw* bd, EditorWindow* win, const BaseContainer& msg)
{
const LONG chn = msg.GetLong(BFM_INPUT_CHANNEL);
if( bDragging && chn==KEY_ESC )
{
Cleanup();
bRedraw = TRUE;
return TRUE;
}
return FALSE
}Also have a look in the api c4d_toolplugin.cpp. The default implementation just returns FALSE.
Bool ToolData::KeyboardInput(BaseDocument *doc, BaseContainer &data;, BaseDraw *bd, EditorWindow *win, const BaseContainer &msg;)
{
return FALSE;
} -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/09/2006 at 06:25, xxxxxxxx wrote:
I don't know about that as, of course, I'm returning TRUE if my plugin 'gobbles' the key (or at least attempts to). Thing is that I want the keyboard input without mouse input (mouse movement, clicks, or drag).
As long as my plugin's AM 'has focus', the keys work. But if the user were to click to select using this tool, the object is selected (and shows its AM) and the tool no longer has 'focus'. Then the keystrokes go to Cinema first! And I want the behavior to be that the object gets the AM - but not the keyboard.
I thought that KeyboardInput() captured keys going to the Editor for the active tool (mine). (?)
Maybe I expect too much...
Thanks,
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/09/2006 at 09:42, xxxxxxxx wrote:
Ah.. i see. Never noticed this behavior though. I just used it to capture the ESC key. Perhaps i should check if it still works when the AM does not show the tool.
I'm also wondering now if this is a limitation or bug or what ?
Mikael ?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/09/2006 at 11:18, xxxxxxxx wrote:
Well, I can get away with LMB+Shift for selection traversal and LMB+Ctrl for operation traversal. KeyboardInput() looks very scary. If I'm on top of a selection and hit the Delete key - crash (not that I want users to hit that key). If I hit the 'T' key and no tool AM, crash. Too many opportunities for crash situations. This type of tool seems very crash prone (doing selections esp.). I have to watch what is selected for deselection as it could have been deleted, the document closed, changed, switched, etc. - so now I just deselect everything in the document.
For the time being, I've added KeyboardInput() back in, but only to return TRUE on any key so that none are allowed (crossfingers).
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/09/2006 at 23:43, xxxxxxxx wrote:
Perhaps SceneHookData::KeyboardInput(), with a check that you tool is active, could be a workaround?