Due to some unavoidable feature of gdb, such as:
1, under windows, When I use gdb with python supported, when showing a local uninitialized variable, such as a vector<string>, the gdb will crash.
2, when debugging, when I select some piece of code, the debugger plugin try to evaluate the "whole piece of the code", this will always cause gdb to crash.
So, can some devs to add an option that when the user hold the "ctrl" key, and the caret hover event send, then the debugger plugin just send the expression to gdb.
any ideas?
Both Loaden and I have just modify the code to:
void DebuggerGDB::OnValueTooltip(CodeBlocksEvent& event)
{
event.Skip();
if (!m_pProcess || !IsStopped())
return;
if (!Manager::Get()->GetConfigManager(_T("debugger"))->ReadBool(_T("eval_tooltip"), false))
return;
if (!wxGetKeyState(WXK_CONTROL)) // does not work!!!!!
return;
But the code does not work.
wxGetKeyState(WXK_CONTROL) this function always get false.
any comments about this?
why I can't query the ctrl key information???
thanks.
Edit:
In this post: one more years ago.
http://forums.next.codeblocks.org/index.php/topic,10616.msg72724.html
QuoteBy the way, I want to use "CTRL" key while mouse hovering some text to get the ValueTooltip shown.
So, I try to add the code:
Code:
+// if (!wxGetKeyState(WXK_CONTROL))
+// return;
But it didn't works as I expect. Can you give me some suggestions?
Thanks
I've just tested it and it works as expected... (tested on linux).
Quote from: oBFusCATed on December 17, 2010, 08:22:19 AM
I've just tested it and it works as expected... (tested on linux).
thanks for the test. but it definitely does not work under windows, :( can some windows guys test for me. thanks.
Hi,
I think I tried it once (to show debugger event only when CTRL is down) however, the problem was that under Windows I did not receive the 'dwell' events from scintilla if CONTROL is down - so I dropped it.
Do you get the dwell event when control key is down? (Windows)
Eran
Quote from: eranif on December 17, 2010, 09:58:49 AM
Hi,
I think I tried it once (to show debugger event only when CTRL is down) however, the problem was that under Windows I did not receive the 'dwell' events from scintilla if CONTROL is down - so I dropped it.
Do you get the dwell event when control key is down? (Windows)
Eran
You are right, I just find this.
from the file: F:\cb\codeblocks_trunk\src\sdk\wxscintilla\src\wxscintilla.cpp
I think it is the point where this message sent.
case SCN_DWELLSTART:
evt.SetEventType (wxEVT_SCI_DWELLSTART);
evt.SetX(scn.x);
evt.SetY(scn.y);
break;
case SCN_DWELLEND:
evt.SetEventType (wxEVT_SCI_DWELLEND);
evt.SetX(scn.x);
evt.SetY(scn.y);
break;
but not sure the key value is already saved here:
void wxScintilla::NotifyParent (SCNotification* _scn)
{
SCNotification& scn = *_scn;
wxScintillaEvent evt (0, GetId());
evt.SetEventObject(this);
evt.SetPosition(scn.position);
evt.SetKey(scn.ch);
evt.SetModifiers(scn.modifiers);
switch (scn.nmhdr.code) {Can we use the evt.GetKey???
Quote from: ollydbg
Can we use the evt.GetKey???
I think you misunderstood me...
What I meant is:
When the CONTROL key is DOWN you will not receive the wxEVT_SCI_DWELLSTART event. (this is on Windows 7 with the latest wxScintilla)
If you *do* receive the event, then I suggest that you try:
if(wxGetMouseState().ControlDown())Eran
Quote from: eranif on December 17, 2010, 10:44:06 AM
Quote from: ollydbg
Can we use the evt.GetKey???
I think you misunderstood me...
What I meant is:
When the CONTROL key is DOWN you will not receive the wxEVT_SCI_DWELLSTART event. (this is on Windows 7 with the latest wxScintilla)
thanks, I understand now.
Quote from: eranif on December 17, 2010, 10:44:06 AM
If you *do* receive the event, then I suggest that you try:
if(wxGetMouseState().ControlDown())
Eran
In fact, I never get such event when I press the control key. :D ,may be, we can hack the scintilla code.
@eranif and other devs
from the scintilla maillist, I get the answers, see below:
https://groups.google.com/forum/?fromgroups#!forum/scintilla-interest
QuoteAsmWarrior:
> I would like to receive the dwell( call tip ) event when I hold on the ctrl
> key. currently, In Windows OS, when I hold the ctrl key, the dwel event will
> never sent. but it seems under linux, it works.
On Windows, keeping the Ctrl key pressed causes multiple key press
events to occur just like holding down an arrow key causes multiple
movements. Each time a key press event occurs, Scintilla resets the
dwell timer as normal key presses are interpreted as the user doing
something and not just hovering the mouse.
You could try to filter out these key press events, possibly on the
basis of which key is being pressed or on whether its an auto-repeat.
Neil
So, I will try to find the code snippet where the "multiply key" event occurs, and filter out such key.
BTW: can someone familiar with scintilla core base can give me a point? thanks.
Index: plugins/debuggergdb/debuggergdb.cpp
===================================================================
--- plugins/debuggergdb/debuggergdb.cpp (revision 6903)
+++ plugins/debuggergdb/debuggergdb.cpp (working copy)
@@ -2648,6 +2648,11 @@
if (!Manager::Get()->GetConfigManager(_T("debugger"))->ReadBool(_T("eval_tooltip"), false))
return;
+ if (!::wxGetKeyState(WXK_CONTROL)) // does not work!!!!!
+ return;
+ //if(! (::GetAsyncKeyState(VK_CONTROL)&0x80))
+ // return;
+
EditorBase* base = event.GetEditor();
cbEditor* ed = base && base->IsBuiltinEditor() ? static_cast<cbEditor*>(base) : 0;
if (!ed)
Index: sdk/wxscintilla/src/scintilla/src/Editor.cxx
===================================================================
--- sdk/wxscintilla/src/scintilla/src/Editor.cxx (revision 6903)
+++ sdk/wxscintilla/src/scintilla/src/Editor.cxx (working copy)
@@ -5379,7 +5379,10 @@
}
int Editor::KeyDown(int key, bool shift, bool ctrl, bool alt, bool *consumed) {
- DwellEnd(false);
+
+ if (!ctrl)
+ DwellEnd(false);
+
int modifiers = (shift ? SCI_SHIFT : 0) | (ctrl ? SCI_CTRL : 0) |
(alt ? SCI_ALT : 0);
int msg = kmap.Find(key, modifiers);
This patch try to solve the problem, but it failed. when holding the ctrl, the tip show about 0.1 second and disappeared quickly.
any one can help me? thanks.
Works here on windows7.
Quote from: jens on December 20, 2010, 10:16:03 AM
Works here on windows7.
thanks.
can someone tested on win xp???
thanks.
Quote from: MortenMacFly on December 20, 2010, 12:58:54 PM
Quote from: ollydbg on December 20, 2010, 10:56:21 AM
can someone tested on win xp???
Works here.
which wx version did you use?
I use 2.8.11.
did you directly apply my patch? (with out other patch)
I have tested in two PCs, but both the tooltip will disappear quickly. :( :(
what's wrong with my PC???? :(
@Jens and Morten
I have solved the problem, see the patch:
Index: plugins/debuggergdb/debuggergdb.cpp
===================================================================
--- plugins/debuggergdb/debuggergdb.cpp (revision 6903)
+++ plugins/debuggergdb/debuggergdb.cpp (working copy)
@@ -2648,6 +2648,9 @@
if (!Manager::Get()->GetConfigManager(_T("debugger"))->ReadBool(_T("eval_tooltip"), false))
return;
+ if (!::wxGetKeyState(WXK_CONTROL)) // does not work!!!!!
+ return;
+
EditorBase* base = event.GetEditor();
cbEditor* ed = base && base->IsBuiltinEditor() ? static_cast<cbEditor*>(base) : 0;
if (!ed)
Index: plugins/debuggergdb/gdb_tipwindow.cpp
===================================================================
--- plugins/debuggergdb/gdb_tipwindow.cpp (revision 6903)
+++ plugins/debuggergdb/gdb_tipwindow.cpp (working copy)
@@ -222,9 +222,10 @@
Close();
}
-void GDBTipWindow::OnKey(wxKeyEvent& /*event*/)
+void GDBTipWindow::OnKey(wxKeyEvent& event)
{
- Close();
+ if(!event.ControlDown())
+ Close();
// not using event.Skip() here to save us from a bad crash...
}
Index: sdk/wxscintilla/src/scintilla/src/Editor.cxx
===================================================================
--- sdk/wxscintilla/src/scintilla/src/Editor.cxx (revision 6903)
+++ sdk/wxscintilla/src/scintilla/src/Editor.cxx (working copy)
@@ -5379,7 +5379,10 @@
}
int Editor::KeyDown(int key, bool shift, bool ctrl, bool alt, bool *consumed) {
- DwellEnd(false);
+
+ if (!ctrl)
+ DwellEnd(false);
+
int modifiers = (shift ? SCI_SHIFT : 0) | (ctrl ? SCI_CTRL : 0) |
(alt ? SCI_ALT : 0);
int msg = kmap.Find(key, modifiers);
I need the filter out the control key event on the GDB tip window. I'm really strange why both of your system works correctly with my last patch?? any ideas??
BTW:
From the codelite's change log, eranif has use this feature for debugger:
Quote
rev 4672 of Codelite trunk
- New: debugger tooltip is now enabled only if CTRL key is down (configurable via the debugger settings page)
- Updated various scripts to set the new codelite version to 2.9.0
-------------------------------
M : /trunk/InnoSetup/make_packages.bat
M : /trunk/Interfaces/debugger.h
M : /trunk/LiteEditor/app.cpp
M : /trunk/LiteEditor/cl_editor.cpp
M : /trunk/LiteEditor/context_cpp.cpp
M : /trunk/LiteEditor/debuggersettingsbasedlg.cpp
M : /trunk/LiteEditor/debuggersettingsbasedlg.h
M : /trunk/LiteEditor/debuggersettingsdlg.cpp
M : /trunk/LiteEditor/frame.cpp
M : /trunk/LiteEditor/manager.cpp
M : /trunk/Runtime/config/debuggers.xml.default
M : /trunk/Runtime/config/debuggers.xml.gtk
M : /trunk/formbuilder/DebuggerSettings.fbp
M : /trunk/make_deb.sh
M : /trunk/make_src_targz.sh
M : /trunk/sdk/wxscintilla/src/scintilla/src/Editor.cxx
Do we need to implement this feature???
for those want to show the debug information correctly. see like below:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2010-12-22111301.png)
You need to delete(comment out) the code snippet in gdb_types.script (because python pretty printer works better than the old implementation and has more wx and c++ container type support)
more reference can be found in this post:
http://forums.next.codeblocks.org/index.php/topic,12747.0.html
Quote from: ollydbg on December 21, 2010, 06:36:42 AM
Do we need to implement this feature???
I'd say no. I don't think this is very intuitive to be honest. When debugging I am very used to see the tooltips as that's the default I want to see in a debugging session. I think forcing the use of control will make this feature pretty much hidden. And the other way round, too: Making this an option would in fact mean nearly nobody will use it. So: What's wrong with showing the tooltips in the debugger session?!
Quote from: MortenMacFly on December 22, 2010, 07:05:10 AM
Quote from: ollydbg on December 21, 2010, 06:36:42 AM
Do we need to implement this feature???
I'd say no. I don't think this is very intuitive to be honest. When debugging I am very used to see the tooltips as that's the default I want to see in a debugging session. I think forcing the use of control will make this feature pretty much hidden. And the other way round, too: Making this an option would in fact mean nearly nobody will use it. So: What's wrong with showing the tooltips in the debugger session?!
I think the reason is:
1, this way, we can show both tooltip by cc(do not hold ctrl) and tooltip by gdb（hold the ctrl), and they never be conflict.
2, I don't want to gdb to show something when the mouse hover something, especially some complex data structure, this will
2a: cause gdb to crash when gdb try to evaluate a complex statement( I think ofb has don some thing to debugger_branch in the last patch to forbid get to evaluate a long or multiline statement)
2b: slow down the debugging stage, I need to wait until something to be shown.
2c: gdb will crash when showing some uninitialized data. like uninitialized c++ vector, but holding the ctrl will give a change to avoid the crash.
Quote from: ollydbg on December 22, 2010, 07:13:38 AM
2, I don't want to gdb to show something when the mouse hover something, especially some complex data structure, this will
2a: cause gdb to crash when gdb try to evaluate a complex statement( I think ofb has don some thing to debugger_branch in the last patch to forbid get to evaluate a long or multiline statement)
2b: slow down the debugging stage, I need to wait until something to be shown.
2c: gdb will crash when showing some uninitialized data. like uninitialized c++ vector, but holding the ctrl will give a change to avoid the crash.
Well - what about a toggle-button in the debugger's toolbar then? To globally enable/disable the evaluation of the cursor... In addition the timer when the tooltip kicks in could be increased. Surely crashes should be fixed and not hidden by disabling options. But in fact I
never saw the debugger crash with the branch. :shock:
Quote from: MortenMacFly on December 22, 2010, 07:19:05 AM
Quote from: ollydbg on December 22, 2010, 07:13:38 AM
2, I don't want to gdb to show something when the mouse hover something, especially some complex data structure, this will
2a: cause gdb to crash when gdb try to evaluate a complex statement( I think ofb has don some thing to debugger_branch in the last patch to forbid get to evaluate a long or multiline statement)
2b: slow down the debugging stage, I need to wait until something to be shown.
2c: gdb will crash when showing some uninitialized data. like uninitialized c++ vector, but holding the ctrl will give a change to avoid the crash.
Well - what about a toggle-button in the debugger's toolbar then?
agreed.
Quote
To globally enable/disable the evaluation of the cursor... In addition the timer when the tooltip kicks in could be increased. Surely crashes should be fixed and not hidden by disabling options. But in fact I never saw the debugger crash with the branch. :shock:
did you use the gdb pretty printer?
See the post of mine in the gdb (all the test was under Codeblocks, even I use the gdb cvs 20101216, it will still crash)
http://sourceware.org/ml/gdb/2010-10/msg00045.html
I'd say no. I don't think this is very intuitive to be honest. When debugging I am very used to see the tooltips as that's the default I want to see in a debugging session.
[/quote]
Try to put the cursor, may be as an involuntary action due to mouse moving, over a std::vector<double> of 50000 elements ...wait and good luck!
Max
Quote from: MaxGaspa on December 22, 2010, 09:17:44 AM
Try to put the cursor, may be as an involuntary action due to mouse moving, over a std::vector<double> of 50000 elements ...wait and good luck!
I see your point, but again: I don't believe the
default case is users having std::vector<double> of 50000 elements. So an option for those who have which can be toggled easily via a toolbar is the way to go IMHO.
Morten: The problem is if you hover your mouse on an uninitialized vector. Then the size is not 50000, but uint_t(-1) or something that large.
Ollydbg: I'll add an item to my TODO: add a option to disable the gdb_types.script
Quote from: oBFusCATed on December 22, 2010, 12:33:16 PM
Morten: The problem is if you hover your mouse on an uninitialized vector. Then the size is not 50000, but uint_t(-1) or something that large.
Ollydbg: I'll add an item to my TODO: add a option to disable the gdb_types.script
thank you obf!!!
@all
Just a reminder, I just noticed that Codelite has an enhanced feature. see the log
Quote
- Debugger: when the option to show the debugger tip only if CTRL key is down is ON, the tip will now be shown immediately without the need to "move" the mouse
-------------------------------
M : /trunk/LiteEditor/cl_editor.cpp
M : /trunk/LiteEditor/context_cpp.cpp
In-fact, I'm trying to implement this feature several days ago. (by hacking the scintilla source code, but failed).
So, eranif has done a great job!!!! thanks.
another question is:
How can this be done in Codeblocks:
The codelite's code is like below:
void LEditor::OnKeyDown(wxKeyEvent &event)
{
// Hide tooltip dialog if its ON
IDebugger * dbgr = DebuggerMgr::Get().GetActiveDebugger();
bool dbgTipIsShown = ManagerST::Get()->GetDebuggerTip()->IsShown();
bool keyIsControl = event.GetKeyCode() == WXK_CONTROL;
if(dbgTipIsShown && !keyIsControl) {
// If any key is pressed, but the CONTROL key hide the
// debugger tip
ManagerST::Get()->GetDebuggerTip()->HideDialog();
} else if(dbgr && dbgr->IsRunning() && ManagerST::Get()->DbgCanInteract() && keyIsControl) {
DebuggerInformation info;
DebuggerMgr::Get().GetDebuggerInformation(dbgr->GetName(), info);
if(info.showTooltipsOnlyWithControlKeyIsDown) {
// CONTROL Key + Debugger is running and interactive
// and no debugger tip is shown -> emulate "Dwell" event
wxScintillaEvent sciEvent;
wxPoint pt ( ScreenToClient(wxGetMousePosition()) );
sciEvent.SetPosition( PositionFromPointClose(pt.x, pt.y));
m_context->OnDbgDwellStart(sciEvent);
}
}
...
Any one can help me???
thanks.
Is it possible to emulate a wxEVT_SCI_DWELLSTART event, and send it directly to the debugger plugin?
(I do not need the other plugin to receive this event in this situation)
thanks!
Ollydbg: it will be ugly, if possible:)
There is a need for tooltip redesign, but I'm not sure what could be done to improve the current situation.
Probably the best solution is tooltip grouping...
Quote from: oBFusCATed on January 05, 2011, 01:38:18 PM
Ollydbg: it will be ugly, if possible:)
agreed. really ugly.
we need to consider a better way.
QuoteThere is a need for tooltip redesign, but I'm not sure what could be done to improve the current situation.
Probably the best solution is tooltip grouping...
tooltip grouping. you mean just stack the tip window one by one??
Currently, As I know, the tip windows is just a wxWindow, see
plugins\debuggergdb\gdb_tipwindow.cpp(trunk)
see:
class GDBTipWindowView : public wxWindow
{
public:
GDBTipWindowView(wxWindow *parent);
// event handlers
void OnPaint(wxPaintEvent& event);
void OnMouseClick(wxMouseEvent& event);
void OnMouseMove(wxMouseEvent& event);
#if !wxUSE_POPUPWIN
void OnKillFocus(wxFocusEvent& event);
#endif // wxUSE_POPUPWIN
// calculate the client rect we need to display the text
void Adjust(const wxString& symbol, const wxString& typ, const wxString& addr, const wxString& contents, wxCoord maxLength);
private:
wxSize GetTextSize(wxArrayString& array, const wxString& text, wxCoord maxLength, int indentationAfterFirstLine = 0);
void PrintArray(wxDC& dc, wxPoint& pt, const wxArrayString& array);
wxString AdjustContents(const wxString& contents);
GDBTipWindow* m_parent;
wxCoord m_headerHeight;
wxString m_symbol;
wxString m_type;
wxString m_address;
wxString m_contents;
#if !wxUSE_POPUPWIN
long m_creationTime;
#endif // !wxUSE_POPUPWIN
DECLARE_EVENT_TABLE()
DECLARE_NO_COPY_CLASS(GDBTipWindowView)
};
By grouping I mean:
1. display all tooltips vertically in different windows
or
2. display all tooltips vertically in one window
Another option is to have tooltip manager which shows only one tooltip at a time.
And there are tooltip priorities, so the best priority wins.
Maybe this is the simpler solution.
Quote from: oBFusCATed on January 05, 2011, 02:05:19 PM
By grouping I mean:
1. display all tooltips vertically in different windows
or
2. display all tooltips vertically in one window
Another option is to have tooltip manager which shows only one tooltip at a time.
And there are tooltip priorities, so the best priority wins.
Maybe this is the simpler solution.
I would prefer only one window. and the idea tooltip manager is a good solution. Currently the tooltip from codecompletion and gdb will battle. (we have discussed this issue one years ago)
Quote from: ollydbg on December 20, 2010, 05:26:50 AM
Index: plugins/debuggergdb/debuggergdb.cpp
===================================================================
--- plugins/debuggergdb/debuggergdb.cpp (revision 6903)
+++ plugins/debuggergdb/debuggergdb.cpp (working copy)
@@ -2648,6 +2648,11 @@
if (!Manager::Get()->GetConfigManager(_T("debugger"))->ReadBool(_T("eval_tooltip"), false))
return;
+ if (!::wxGetKeyState(WXK_CONTROL)) // does not work!!!!!
+ return;
+ //if(! (::GetAsyncKeyState(VK_CONTROL)&0x80))
+ // return;
+
EditorBase* base = event.GetEditor();
cbEditor* ed = base && base->IsBuiltinEditor() ? static_cast<cbEditor*>(base) : 0;
if (!ed)
Index: sdk/wxscintilla/src/scintilla/src/Editor.cxx
===================================================================
--- sdk/wxscintilla/src/scintilla/src/Editor.cxx (revision 6903)
+++ sdk/wxscintilla/src/scintilla/src/Editor.cxx (working copy)
@@ -5379,7 +5379,10 @@
}
int Editor::KeyDown(int key, bool shift, bool ctrl, bool alt, bool *consumed) {
- DwellEnd(false);
+
+ if (!ctrl)
+ DwellEnd(false);
+
int modifiers = (shift ? SCI_SHIFT : 0) | (ctrl ? SCI_CTRL : 0) |
(alt ? SCI_ALT : 0);
int msg = kmap.Find(key, modifiers);
This patch try to solve the problem, but it failed. when holding the ctrl, the tip show about 0.1 second and disappeared quickly.
any one can help me? thanks.
Good catch!
A fix for this was committed in r7397 in the debugger's branch.
Quote from: oBFusCATed on August 29, 2011, 04:55:21 PM
A fix for this was committed in r7397 in the debugger's branch.
would you like to do some extra enhancement? like the patch here:
hit the ctrl key to show the debug tip (http://forums.next.codeblocks.org/index.php/topic,10908.msg101344.html#msg101344)
Yes, my version of this patch is to be committed in some time...
Quote from: oBFusCATed on August 30, 2011, 09:08:18 AM
Yes, my version of this patch is to be committed in some time...
No, the rev 7397 only change one file.
But What I said is to use the full patch:
http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0022.5.patch
Such that when you hit the ctrl, the emulated dwell event is sent.
Quote from: oBFusCATed on August 30, 2011, 09:08:18 AM
Yes, my version of this patch is to be committed in some time...
The text in bold probably should have been: "is going to be"