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:29, xxxxxxxx wrote:

There is already a set of key operations - up and down arrows. I'm using GetCursorInfo() to get the mouse XY and then using that to get the object list underneath in Draw() for highlighting. But since there can be 'stacked' selections, not just objects - but even polygon selections, the up/down arrows are used to traverse the stack. I was hoping to use the right mouse button to do the same (as it's a circular stack, it will reset to the top level at the end of the stack as the button is clicked).

The Cinema 4D right mouse button 'double-click' list is really no good here since it does not see the polygon selections as valid choices.

Use of the right mouse button would keep the user from needing both hands (one on the mouse and the other on the keyboard up/down arrows).

ETA: If the mousewheel is 'unattended', this might be a good substitute, but not sure how sensitive it would be (a scroll tick may jump more than one selection). And it would mean that no mousewheel, must use keys.

Thanks,

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
DoubleClick

Maybe 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.