ToolData::MouseInput RightButton
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/08/2006 at 12:37, xxxxxxxx wrote:
I can only repeat, it´s absolutely feasible to use an additional key. A cinema 4D user has his hands on the keyboard all the time on it anyway (at least I personally don´t know anybody working without, well, maybe for presentations *g* ). To conclude: DO IT!
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/08/2006 at 12:40, xxxxxxxx wrote:
How about this, Mr. DO IT! - Currently, the cursor does the highlighting and a left mouse button click selects the deformer object associated with the polygon selection. What if a left mouse button click traverses the stack and a double-click selects?
I agree that users will be at the ready for keyboard shortcuts, but mouse options are always good to have (if possible).
Thanks,
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/08/2006 at 12:47, xxxxxxxx wrote:
Sorry, what do you mean by "What if a left mouse button click traverses the stack and a double-click selects?" (my english seems to break there :_) )
Well, mouse options are good, but sometimes they can work against the workflow of the user. And it may be easier to hold the SHIFT key (beside the fact that I probably don´t see your problem
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/08/2006 at 12:57, xxxxxxxx wrote:
In this case there are two stages - just the cursor location without any button clicks highlights the (possible) selection while the button click selects the highlighted possible selection.
But in order to choose/highlight other possible selections under the cursor location, there needs to be another set of user inputs. Currently that is provided using the up/down arrows.
I see that one problem with click/double-click is that the first click of the double-click is getting read as a traversal - and then mistakenly selects the next highlighted selection in the list instead of the current one when the next click is read as part of a double-click (arghhh!). Now, I could forego the double-click and use the SHIFT key to signal traversal on LMB clicks while no key actually selects on the LMB click. Whatcha think?
Thanks,
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/08/2006 at 13:28, xxxxxxxx wrote:
hmm, how are you checking for the double click? BFM_INPUT_DOUBLECLICK should be the channel to check for. If you do this already (but then it shouldn´t do anything for the first click) and it doesn´t work as expected, then yes, I´d definetly go for SHIFT. (of course, in this case a working double click would truly be better)
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/08/2006 at 13:39, xxxxxxxx wrote:
Yep, I'm checking for the (BFM_INPUT_CHANNEL) == BFM_INPUT_MOUSELEFT and then for BFM_INPUT_DOUBLECLICK or else (single-click). Seems that on the first click 'else' is evaluated and on the second click for the double-click, BFM_INPUT_DOUBLECLICK is evaluated. Don't know how this can be avoided and still have single clicks evaluated properly.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 31/08/2006 at 01:35, xxxxxxxx wrote:
how are you doing this. Code snippet?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 31/08/2006 at 08:32, xxxxxxxx wrote:
Well, I'm currently using the LMB+Shift, but I've reconstructed the code for double-click just in case you see something that can be fixed:
// ToolData.MouseInput //*---------------------------------------------------------------------------* Bool IPPTool::MouseInput(BaseDocument* doc, BaseContainer& data, BaseDraw* bd, EditorWindow* win, const BaseContainer& msg) //*---------------------------------------------------------------------------* { // Only interested in Left Mouse Button if (msg.GetLong(BFM_INPUT_CHANNEL) != BFM_INPUT_MOUSELEFT) return TRUE; if (!hilitedBP) { // This allows click-deselection (see Draw()) if (selectedBP) { doc->SetActiveObject(selectedBP, SELECTION_SUB); selectedBP = NULL; } return TRUE; } // Left Mouse Button double-click for selection/translation/rotation/scale if (msg.GetBool(BFM_INPUT_DOUBLECLICK)) { selectedBP = hilitedBP; doc->SetActiveObject(hilitedBP, SELECTION_NEW); // Get Start Mouse coordinates mouseX = msg.GetReal(BFM_INPUT_X); mouseY = msg.GetReal(BFM_INPUT_Y); // Operation if (operation == IPTOP_ROTATE) Rotate(doc, bd, win); else if (operation == IPTOP_SCALE) Scale(doc, bd, win); else if (operation == IPTOP_TRANSLATE) Translate(doc, bd, win); EventAdd(); } // Left Mouse Button single-click for highlight stack traversal else { level++; // This gets the Draw to happen (maybe DrawViews() is better?) EventAdd(); } return TRUE; }
Thanks,
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 31/08/2006 at 08:39, xxxxxxxx wrote:
hmm, looks correct to me (and yes, DrawViews should be fine as there´s no need for an EventAdd), so I don´t know why you get a single and double click. Probably because of the EventAdd call?
DrawViews(DA_NO_THREAD|DA_ONLY_ACTIVE_VIEW|DA_INDRAG); Is what I am using.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 31/08/2006 at 08:45, xxxxxxxx wrote:
Let me give that a try and see what results.
Thanks,
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 31/08/2006 at 09:01, xxxxxxxx wrote:
Still doing the same thing. I've decided to make this official and print 'SingleClick' on supposed single-clicks and 'DoubleClick' on double-clicks. Indeed, it is printing this to the console on a double-click:
SingleClick
DoubleClickMaybe one has to sit in the MouseInput() and wait for the double click within a time period to determine which course to take - using InputEvent(), GetInputState(). or GetInputEvent(). (?)
Thanks,
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/09/2006 at 10:12, xxxxxxxx wrote:
Just as a final post on this thread, I found this earlier message from Mikael concerning Right and Middle mouse button support in Tool plugins:
I'm afraid it's not possible to detect right och middle clicks in the editor from a tool plugin. As you've noticed, these events are already bound to other C4D functions.