| T O P I C R E V I E W |
| thruska |
Posted - Aug 29 2006 : 10:26:43 AM
When entering what I call 'edit mode' (typing the first open parenthesis - same as pressing Ctrl+Shift+Space), I notice that what gets displayed in the tooltip isn't exactly organized. I have one class where, while I don't use it a lot, has two functions with the exact same name. One of the functions is public, the other private. In this particular case, the private method shows up first in the list of options (granted there are only two). The public method is probably the one I want since I can't access the private method.
Just a minor issue.
|
| 6 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Sep 03 2006 : 4:20:50 PM
i try quite hard to avoid the friend keyword, but there are a few places in my code where it really is the best solution i could find, and i feel improved the code by making sure people could not abuse the classes i was building  (well they could, but i made it as hard as possible)
Kevin the idea of an inverse filter makes a lot of sense, i have put in a suggestion for this
case=2351
thruska idea's are good not all ideas will be accepted or embraced, but it is still worth posting them. now and then people post an idea and i just sit here going "now why didn't i think of that, its so sensible!" it doesn't happen all that often, but it does happen |
| thruska |
Posted - Sep 01 2006 : 7:17:36 PM
Feline, I only run into this problem with one of my classes. And it isn't a huge deal - I can just hit the down arrow (when I'm editing the parameter list) and it selects the other function. I just figured it would be nice to sort the parameter lists according to public vs. private vs. protected. I don't really use the 'friend' keyword a whole lot.
Anyway, this was just an idea I had. I crank out new ideas every day. |
| kevinsikes |
Posted - Sep 01 2006 : 4:33:31 PM
Ah, I had forgotten about the dreaded friend keyword. I wonder if the parser is (or could be modified to be) able to track a class's friends and allow access within each friend's context?
As a short-term enhancement, how about allowing a right-click on the filtering toolbar to perform an inverse filter (e.g., right-click on Private Methods to apply all filters except Private Methods)? Or allow a right-click to invert whatever combination of existing filters is currently applied? |
| feline |
Posted - Sep 01 2006 : 2:36:20 PM
the immediate problem with this is the friend keyword. in simple cases VA should be able to work out what is visible and what is not, but not all code is that simple.
it is the edge cases that tend to cause us a lot of problems *sigh*
this reminds me of the suggestion to make the filtering sticky, but so far i cannot find the thread that discussed this idea.
the completion listbox has the icons showing if it is public or private, but i never tend to look at these personally.
this seems like such a sensible idea, but i have this nagging feeling there is some fundamental problem here. if i could just put my finger on what is bothering me it would help. |
| kevinsikes |
Posted - Sep 01 2006 : 1:46:41 PM
To boil a little fat off the problem, it would be cool to completely remove private and protected members from the tooltips (when typing the open parenthesis) and enhanced listboxes (when typing the dot or -> operator) when invoked from contexts that can't access them, regardless of whether their names collide with overloads in different access levels. Consider this C++ code:
class Foo
{
public:
Foo() : m_nBar(0) {}
Foo(int n) : m_nBar(n) {}
int GetNumber() const { return m_nBar; }
void SetNumber(int n) { m_nBar = n; }
private:
int GetTwoTimesNumber() { return 2 * m_nBar; }
int m_nBar;
};
void main()
{
Foo foo;
foo. [member list opens here]
}
In the member list, I see m_nBar and GetTwoTimesNumber, even though they are not valid within function main(). Although VA X does provide filters for access type, you would need to shift+click all filters that are not private to see the remaining valid members (you can only filter "in", not filter "out"). Having the option to suppress the members that are not valid in the current context would be a BIG timesaver.
(Post edited to cover both tooltips and enhanced listboxes) |
| feline |
Posted - Aug 31 2006 : 5:30:04 PM
an interesting idea. i am wondering how common this situation is though. thinking about my own code i can think of hardly any situations where some of the overloads are public and some are private.
i use overloaded functions a fair bit, but normally have different function names for public and private calls. anyone else got an opinion on this? are there a lot of examples in the Win32 API for example? |
|
|
