Disable CC calltip when context Menu is opened(Same as ValueTooltip in GDB)

[ollydbg]

Hi, all.

In revision 5612, the debuggergdb plugin, OnValueTooltip() will be disabled when a context menu is open.

Code Select Expand



void DebuggerGDB::OnValueTooltip(CodeBlocksEvent& event){

...
   if(ed->IsContextMenuOpened())
   {
    return;
   }
...



I think this can also  be applied to code Completion plugin

void CodeCompletion::OnValueTooltip(CodeBlocksEvent& event)


By ollydbg at 2009-06-16

Any comments?
A convinent way is that when a context menu is open, the editor stop sending Tooltip event.

[rhf]

ollydbg,
I am not sure of the best solution, but the problem is very annoying. If there are several Code Completion options, they completely cover the Thread Search options on the context menu. Windows XP, SVN 5650.

[ollydbg]

ollydbg,
I am not sure of the best solution, but the problem is very annoying. If there are several Code Completion options, they completely cover the Thread Search options on the context menu. Windows XP, SVN 5650.

Hi, rhf.

Did you mean that the Code Completion tooltip window cover "Thread Search Panel" ?

Where can I find "Thread Search options on the context menu"..Did you mean the "find the occurrence of "XXXXX" in the context menu?

I'm not quite full understand.

[MortenMacFly]

Any comments?

I've tested this and it works (and makes sense) IMHO. I have put it on my list of changes to CC.

I've done it as follows (shown is just the appropriate code snippet in void CodeCompletion::OnValueTooltip(CodeBlocksEvent& event) as I cannot provide a patch easily):
OLD:

Code Select Expand


       EditorBase* base = event.GetEditor();
       cbEditor* ed = base && base->IsBuiltinEditor() ? static_cast<cbEditor*>(base) : 0;
       if (!ed)
           return;

       if (ed->GetControl()->CallTipActive())
           ed->GetControl()->CallTipCancel();

NEW:

Code Select Expand


       EditorBase* base = event.GetEditor();
       cbEditor* ed = base && base->IsBuiltinEditor() ? static_cast<cbEditor*>(base) : 0;
       if (!ed || ed->IsContextMenuOpened())
           return;

       if (ed->GetControl()->CallTipActive())
           ed->GetControl()->CallTipCancel();


[ollydbg]

I'm thinking that we can disable on cbEditor class

Code Select Expand


void cbEditor::OnEditorDwellStart(wxScintillaEvent& event)
{
    cbStyledTextCtrl* control = GetControl();
    int pos = control->PositionFromPoint(wxPoint(event.GetX(), event.GetY()));
    int style = control->GetStyleAt(pos);
    NotifyPlugins(cbEVT_EDITOR_TOOLTIP, style, wxEmptyString, event.GetX(), event.GetY());
    OnScintillaEvent(event);
}


When Dwell starts, we should first check

IsContextMenuOpened()

Am I right?

[ollydbg]

I tested, and these code works fine.

Code Select Expand


void cbEditor::OnEditorDwellStart(wxScintillaEvent& event)
{
    cbStyledTextCtrl* control = GetControl();
    int pos = control->PositionFromPoint(wxPoint(event.GetX(), event.GetY()));
    int style = control->GetStyleAt(pos);
    if(IsContextMenuOpened()==false)
        NotifyPlugins(cbEVT_EDITOR_TOOLTIP, style, wxEmptyString, event.GetX(), event.GetY());
    OnScintillaEvent(event);
}



Any comments?

[oBFusCATed]

Don't do == false, but use ! :-) This is not C#  :lol:

[Jenna]

Are you aware, that we use exactly the same code in debuggergdb.cpp and codecompletion.cpp OnValueTooltip():

Code Select Expand

   if(ed->GetControl()->CallTipActive())
   {
    ed->GetControl()->CallTipCancel();
   }


That means the it's not clear which function wins and supresses the other.

[ollydbg]

Are you aware, that we use exactly the same code in debuggergdb.cpp and codecompletion.cpp OnValueTooltip():

Code Select Expand

   if(ed->GetControl()->CallTipActive())
   {
    ed->GetControl()->CallTipCancel();
   }


That means the it's not clear which function wins and supresses t

Oh, Yes, When I'm debugging, there is only "tip" from debuggergdb.
Seems the "tip" from code completion always be canceled.


@oBFusCATed
Thanks for the hint.  


Edit:

Code Select Expand


// get rid of other calltips (if any) [for example the code completion one, at this time we
// want the debugger value call/tool-tip to win and be shown]
    if(ed->GetControl()->CallTipActive())
    {
    ed->GetControl()->CallTipCancel();
    }


This code in debuggergdb was added in r5614.

I think we should find another way to disable CC's tip when debugging.

[Jenna]

Oh, Yes, When I'm debugging, there is only "tip" from debuggergdb.
Seems the "tip" from code completion always be canceled.

That's because debugger needs more time before the tooltip is called (sending commands to gdb, waiting for response, parsing output...), so it can cancel the other one.

[rhf]

Did you mean the "find the occurrence of "XXXXX" in the context menu?

Yes. Just as in your original post on this topic, if your BeginLoadingProject() had several overloads, the Code Completion tool tip can mask the options: "Find declaration of: ...", "Find implementation of: ...", "Find occurrences of:  ...", etc.
Thanks for pursuing this.

[ollydbg]

@rhf
You are welcome
@jens
I think debuggergdb plugin should temporary disable other plugins event sink for Tooltips. It is not easy to implement.

[oBFusCATed]

Or there should be cbEditor->EmitTooltip(something) that is used by all of the folks that show tooltips.
So if there are two tooltips shown simultaneously it can merge them or show only the last emitted tooltip.
But, I'm no sure if that is possible...

[ollydbg]

Or there should be cbEditor->EmitTooltip(something) that is used by all of the folks that show tooltips.
So if there are two tooltips shown simultaneously it can merge them or show only the last emitted tooltip.
But, I'm no sure if that is possible...

show only the last emitted tooltip is not the reliable way, because as jens said, we are not sure which plugin receive this kind of event first, and which plugin call the ed->showtip first.

[rhf]

If you could find a way to force the tooltips to always display "above" the selection, as happens now when the selection is at the bottom of the editor screen, then most (all?) of the overlap problems would go away. Just a suggestion.