Patch: function arguments added to autocomplete tooltip

[p2rkw]

I tried doxyblocks, but it seems that it only doubles functionality of doxywizard. My question was about display documentation in codeblocks.
to see doc, i.e. description of function parameters I have to minimize c::b and switch to browser, open documentation, search for function, remember parameters meaning and switch back to c::b. My intention was to display documentation in floating window above autocompletion. Something similar to http://netbeans.org/images_www/v7/1/screenshots/editor.png , for example:


And I agree that doxygen is the best tool to generate documentation, and IMO codeblocks should use its to generate docs.
Codeblocks already have (mostly unused) html viewer, maybe it can be used to display documentation? It is possible to make popup floating window with this viewer inside? It can be nice replacement for scintilla's call tip.

[dmoore]

I think you could just use a wxPopupWindow. The info windows are popup windows.

[oBFusCATed]

I'd be rather careful with the popup window usage... we have very messy fights between the cc and the debugger popups.
Probably you'll have to see what is used to implement the current popup and probably add something to it.
Like a text control at the top/bottom with the comment.

[Alpha]

An alternative idea to a popup would be to have a "CC Documentation" tab in the logs at the bottom.  CC could update it whenever it felt necessary: docs on the symbol under the caret, docs on the current function, and, of course, docs on the current selection during auto-completion.  This idea should not interfere with other popups, but it also may not be as intuitive.

About documentation, I tried to detect when user changes selection in autocomplete but currently I can't do that.

Have you tried the work around of listening for key presses WXK_UP and WXK_DOWN, then requesting the current selection?

[p2rkw]

Alpha: yes I did. I added something like this:
Connect(wxEVT_KEY_DOWN, wxKeyEventHandler(CodeCompletion::OnKeyDown));
to Codecompletion's ctor, but my event handler wasn't called.

[ollydbg]

An alternative idea to a popup would be to have a "CC Documentation" tab in the logs at the bottom.  CC could update it whenever it felt necessary: docs on the symbol under the caret, docs on the current function, and, of course, docs on the current selection during auto-completion.  This idea should not interfere with other popups, but it also may not be as intuitive.

I like this idea.

[Alpha]

Connect(wxEVT_KEY_DOWN, wxKeyEventHandler(CodeCompletion::OnKeyDown));

Key events are not generated inside a plugin, so it is necessary to Connect() to the editor with something like:

Code Select Expand


cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
if (ed)
    ed->GetControl()->Connect(wxEVT_KEY_DOWN, (wxObjectEventFunction)&CodeCompletion::OnKeyDown, NULL, this);

...

void CodeCompletion::OnKeyDown(wxKeyEvent& event)
{
}


Also, take a look at:

Code Select Expand


void CodeCompletion::EditorEventHook(cbEditor* editor, wxScintillaEvent& event)


[MortenMacFly]

I think you could just use a wxPopupWindow.

Note that this is not available on the Mac. Maybe a HTML/RTF like control is indeed better.

[dmoore]

We use mini frame or some such on Mac using an ifdef. The scintilla popup does the same thing.

Re html window... I would prefer the way it is done in netbeans. To have a html control means another persistent window on screen taking up space?? An alternative to two popups is to hack the tip window to add extra widgets to it.

[oBFusCATed]

An alternative to two popups is to hack the tip window to add extra widgets to it.

wxTipWindow is unhackable... you'll have to use wxPopupWindow or wxPopupTransinientWindow.

[dmoore]

Sorry meant auto complete window not tip window. And why wouldn't it be hackable? Just put a sizer and extra widgets in it. But we don't have to use scintillas implementation of auto complete at all.

[MortenMacFly]

To have a html control means another persistent window on screen taking up space??

Clearly, it should be one window only. I didn't mean to add another.
BTW: My experience with wxMiniFrame is (however) rather bad, as it steals focus.

[dmoore]

Correction... wxSctintilla uses either wxPopupWindow or wxFrame to display the autocomplete list control (see line 917 of PlatWX.cpp). There is an #ifdef about COCOA in the wxPopupWindow derived version, so are you sure this isn't supported on Mac in newer versions of wxWidgets?

[oBFusCATed]

wxCocoa is available only in wx2.9+, for wx2.8 there is only wxCarbon.

[dmoore]

Regardless, the point stands that there is a working implementation in wxScintilla using either PopupWindow or Frame that can be adapted.