Author Topic: cb-calltree command bug? How to get the inverse of cb_call_tree??  (Read 2174 times)

Ganesh Venkitachalam

  • Community Member
  • Posts: 32
  • Hero Points: 0
I'm having a lot of trouble with call trees:
(0) There's the cb-call-tree command, which I believe is supposed to show all the functions that the current function calls. I bind this to a key, and press my key-combo with the cursor on a function, and all I get back is a dialog with the title "Symbol uses/Calling tree". The dialog has 3 buttons (Expand, Close, Help) but zero text in the dialog. Is this a *big* bug, or do others actually see call tree when invoking cb_call_tree? Or does this need to be configured in some way?

(1) Then there's the reverse: I want to get a call tree like cscope, where cscope can show you "functions calling the current function". Does SE support this? It feels like it should have all the info, but I can't find any command for this.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2789
  • Hero Points: 422
Re: cb-calltree command bug? How to get the inverse of cb_call_tree??
« Reply #1 on: May 28, 2013, 02:25:15 pm »
cb_calltree() is meant to be called from the context menu of the Defs, Class, or Symbols tool windows, not from the editor control.  I'm putting in a tweak for the next release so that it will work from the command line and the editor control.

The reverse operation you are asking for is references.  Just right click on the symbol and select "Go to reference to 'symbolName'", or, in most emulations, hit Ctrl+Slash.

Ganesh Venkitachalam

  • Community Member
  • Posts: 32
  • Hero Points: 0
Re: cb-calltree command bug? How to get the inverse of cb_call_tree??
« Reply #2 on: May 28, 2013, 08:02:18 pm »
Hi Dennis,

Thanks. By "next version", do you mean the version that's now in beta? Cannot wait to try it, then.

No, what I'm asking for is not references (I already use that extensively). References just gives you a flat list of all the callers (and references including header declarations) of the function under the cursor. What I'd like is a rooted call-tree, to see the entire call chain of how control *ends up* at the current function. eg: say A calls B calls C calls D, and Z calls Y calls D, what I want is a flat list of who calls D (which would show Y and C), but then I want to click a little "+" sign that will expand to N levels and show the whole calling hirearchy (whic would show in a tree A->B->C->D when I click the "+" on C, and show Z->Y->D when I click the "+" on Y)/. I realize this is hard with function pointers, but still you could show what slickedit in fact knows to be true.

Does this already exist? emacs has plugins to do this kind of thing, and I'd imagine slickedit already has all the information given how cool your tags are now...

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2789
  • Hero Points: 422
Re: cb-calltree command bug? How to get the inverse of cb_call_tree??
« Reply #3 on: May 31, 2013, 12:31:14 pm »
Yes, the fix should be in Beta 6.

We do not have a multi-level facility for finding references, like the inverse call tree you describe.  The data is there, obviously, but rather expensive and time consuming to calculate.  We do have an old feature request for it, I'll add another +1 for it.

RaffoPazzo

  • Community Member
  • Posts: 65
  • Hero Points: 2
Re: cb-calltree command bug? How to get the inverse of cb_call_tree??
« Reply #4 on: November 13, 2013, 05:59:18 pm »
I would like to give a suggestion. You might have probably thought about it, but it doesn't hurt sharing it, anyway.

As Dennis has said
Quote
The data is there, obviously, but rather expensive and time consuming to calculate.

But only if you did it all in once, upfront. I think there's a much cheaper and easier way to do this, and it wouldn't be so time consuming...do it on demand.

We just need a slightly amended version of the References Window. We look for foo() references with "push-ref" and it lists bar() and baz() as today. However, per each result, it will also show the usual + icon. When we click the + icon, it will simply invoke "push-ref" again, on that symbol and its result will be nested under it rather than wiping out the previous result.

In this way it shouldn't be that expensive for you to implement and even quicker for us to use, as it looks for references on demand.