Poll

Should the "Display Files" option in the Defs tool window be removed.

Axe the "Display Files" option
3 (50%)
I rely on this feature and here are the reasons why.
0 (0%)
This poll seems very biased, but I vote to remove "Display Files".
0 (0%)
This poll seems perfectly objective, remove "Display Files".
0 (0%)
I didn't even know that option existed.
3 (50%)

Total Members Voted: 6

Voting closed: October 30, 2013, 03:32:55 pm

Author Topic: "Display Files" option in Defs tool window  (Read 6057 times)

dholshou

  • Community Member
  • Posts: 51
  • Hero Points: 1
Re: "Display Files" option in Defs tool window
« Reply #15 on: February 11, 2015, 06:02:07 pm »
Of course. VSE's powerful tagging and referencing are what I love.

I'm just upset about losing a feature I depend on.
I don't understand the symbols tab. It doesn't make sense to me, so I've lost the ability to get around and now I have to learn a new way.
My expectation of <ctrl><tab> is obviously very different than yours, so I find it very frustrating and my only recourse is to have files displayed in my defs tab.
Now I have double the mouse clicks to get where I could get yesterday with a minimum of expense.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2831
  • Hero Points: 429
Re: "Display Files" option in Defs tool window
« Reply #16 on: February 11, 2015, 06:11:34 pm »
Personally, I don't use Ctrl+Tab to navigate files, so my expectations are not really an issue. 
I do make a lot of use out of Ctrl+' (edit-associated-file).

What specifically do you not understand about the Symbols tool window ?  (BTW, I was suggesting you try the "Find Symbol" tool window earlier, not Symbols).

dholshou

  • Community Member
  • Posts: 51
  • Hero Points: 1
Re: "Display Files" option in Defs tool window
« Reply #17 on: February 11, 2015, 06:15:55 pm »
So, "Find Symbol" would mean typing out the symbol name when I want to move to a file/symbol area within my code in a file I already have open. Hmmmm. We'll see.

dholshou

  • Community Member
  • Posts: 51
  • Hero Points: 1
Re: "Display Files" option in Defs tool window
« Reply #18 on: February 19, 2015, 04:48:24 pm »
Ok, so I've narrowed down a bit on this concept.
You say <ctrl>+. "Go to definition" and that does work for inherited classes (actually sometimes it only goes to the symbol in the current file and ignores the other [declaration or definition] even if I don't have "Do not show these options again" checked. but it works most of the time.)
But if I "Go to references" <ctrl>+/, a dialog pops up with the super and the sub class Symbols listed for choice, and then when I select the sub class, all possible symbols, from the entire code base are shown.

Code: [Select]
class B {
public:
   virtual void validate();
};

class C1: public B {
public
   virtual void validate();
};
class C2: public B {
public
   virtual void validate();
};

/* dot dot dot */

class C99: public B {
public
   virtual void validate();
};

The References tab always shows all references to all B::validate() if the cursor is sitting on C99::validate() select "Go to Reference for validate()" and then select C99::validate() from the selection dialog.
There are no preprocessor weirdities (or any other oddities.) This code base is very simple and straightforward. We don't have strange constructs. It's simply not allowed.

See attachment ScreenClip.png
I seem to remember VSE being smarter in the past about only showing references that match.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2831
  • Hero Points: 429
Re: "Display Files" option in Defs tool window
« Reply #19 on: February 19, 2015, 05:57:44 pm »
Testing with 19.0.1, when I do Ctrl+/ on validate, I'm prompted whether I want C99::validate() or B::validate().

If I choose C99::validate(), I only see B::validate(), which is a reference by virtue of being the declaration in a parent class, and C99::validate(), which is the item I selected.

If I choose B::validate(), I see all four references, which is correct, because they are all related by inheritence to the parent class B.

In your screen shot, it's hard to tell if what I happening is correct or not because I don't know your class hierarchy.  Which of the following classes inherit from SspInterface?  Which of the following classes use SspInterface or a class that derives from SspInterface, or call the Initialize() method from an abstract class that SspInterface derives from.

  • AccelInterface?
  • BitManager?
  • BsaInterface?
  • CalibrationMangager?
  • CameraManager?
  • CiuInterface?
  • CmdRouter?
  • EnvInterface?
  • FaultManager?
  • HwInterface?
  • IrAlgorithms?
  • LineOfSight?

I notice that the reference in IrAlgorithms.cpp is in an unrecognized code region, so there must be some preprocessing going on there, or some very unusual code construct that the parser did not recognize.  Maybe it's incomplete code.

Polymorphism can be great, but it does create situations where code navigation gets more difficult.  Every time you have some thing like the following example, there is no guessing what sub-class is being called, except at run-time, of course.  An overuse of this construct can decompose a strongly typed language down to being as hard to statically analyze (ie, read the code) as an run-time typed scripting language.

Code: [Select]
   CommonInterface *pci = something;
   pci->Initialize();
   // 200 classes derive from "CommonInterface" and redefine Initialize()
   // This call could be to ANY one of them.

dholshou

  • Community Member
  • Posts: 51
  • Hero Points: 1
Re: "Display Files" option in Defs tool window
« Reply #20 on: February 19, 2015, 06:04:54 pm »
None of these classes inherit from SspInterface. That's the point.
They ALL inherit from a super class LPSW.
I have selected the symbol Initialize(SspInterface:func), but it's showing me every possible version including the super class and all inheriters.

There is no preprocessing allowed. IrAlgs is not showing because it's unimplemented and in a half-baked state. I don't know what's up with it, it's just empty right now.

I've seen this on several code-bases. All of those codebases use different structures but follow the same rules, no weird preprocessing. Don't blame it on that. That's not it.

VSE didn't used to do this, in the last few rev's things have gotten so complicated that it seems to be missing the simple stuff now.
« Last Edit: February 19, 2015, 06:07:31 pm by dholshou »

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2831
  • Hero Points: 429
Re: "Display Files" option in Defs tool window
« Reply #21 on: February 19, 2015, 06:29:32 pm »
OK, here's a made-up example.  Do you think this is a possible reference to SspInterface?  [hint, I do].  If you are looking for references to SspInterface::Initialize(), then I presume you want to see all possible places where it could theoretically be called from.

Code: [Select]
void CameraManager::Initialize()
{
    for (size_t i=0; i<m_cams.length(); i++) {
       LPSW *child = m_cams[i];
       child->Initialize();   // could be any class that ultimately derives from LPSW
    }
}

dholshou

  • Community Member
  • Posts: 51
  • Hero Points: 1
Re: "Display Files" option in Defs tool window
« Reply #22 on: February 19, 2015, 06:47:58 pm »
I'm trying to figure out the implications of that. There is nothing that does that exactly, ie: pointer/polymorphic use of the super to change a "shape" into a "circle" or a "square".

All applications follow exactly the same construct in this respect.
All sub classes explicitly call super::Initialize() as the first line of sub::Initialize() to setup interprocess communication.
There are no pointers to possible polymorphic subclasses. This is direct and simple in every sense I can think of.
Code: [Select]
lpsw_err SspInterface::Initialize(CmdRouter *pCmdRouter, TlmCollect *pTlmCollect, FaultManager* pFaultManager)
{
   lpsw_err locRetVal = LpswApp::Initialize(pCmdRouter, pTlmCollect, FaultManager);

But this is digging too deep into detail. I've seen this behavior on multiple code bases with different structures. This isn't about polymorphism or ruby-like run-time type-morphic madness. I'm not sure how I can describe it better or differently. Every reference, to every possible name that's spelled the same (even if it's in a different class) isn't the correct match but that's what I'm getting.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2831
  • Hero Points: 429
Re: "Display Files" option in Defs tool window
« Reply #23 on: February 19, 2015, 07:14:30 pm »
OK.  I think that may have finally helped me narrow it down.  I can fix this.

Code: [Select]
class B {
public:
   virtual void validatex();
};

class C1: public B {
public
   virtual void validatex();
};
class C2: public B {
public
   virtual void validatex();
};

/* dot dot dot */

class C99: public B {
public
   virtual void validatex();
};

void C99::validatex()
{
   B::validatex();   // only a reference to B::validatex(), not classes derived from B
}