| Author |
 Topic  |
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
 Posted - Oct 04 2004 : 10:21:26 AM
|
I realise that VA X chooses suggestions using a combination of various heuristics at different times. But there's one way in which it could be improved, and I think it's simple.
If a symbol is the default (highlighted) choice in a suggestion or completion listbox, and the user types another character, and the same symbol is still a valid completion, then it should still be present in the new listbox and should still be the default choice.
Why does this matter? My typing is frequently one character ahead of processing what I'm seeing on the screen. I start to type a symbol, and a nice suggestion box pops up with the right suggestion highlighted, and I hit Tab or Return to accept, but unfortunately I've typed the next character of the symbol already, and the suggestion box has changed, and I end up with completely the wrong symbol. This happens to me a lot.
I realise that autotext would take priority over my rule. Typing another character on the end of an autotext shortcut would still use my rule, however. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Oct 04 2004 : 2:32:20 PM
|
VA X should do as you suggest.
Do you have acronyms or shorthand enabled? They affect what VA X chooses to highlight. For one, an acronym has precedence over a prefix. |
 |
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Oct 04 2004 : 4:15:01 PM
|
I have both acronyms and shorthand enabled.
I'll look out for a specific example. The problem with trying to find an example is that if you go back and type it again, you don't always get the same suggestions in the same order. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
schoenherr
Tomato Guru
Germany
160 Posts |
Posted - Oct 05 2004 : 12:35:36 AM
|
same problem here, maybe you can change your policies in the way like stephen suggested.
why acronym's and shorthand's have precedence in this specific situation. i agree that
the listbox should be modified to contain matches with acronyms and shorthands but
i think a valid and "still valid" completion should stay in the list. |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Oct 05 2004 : 05:08:53 AM
|
I took "VAX should do what you suggest" to mean that that is believed to be the current behaviour. If so, it's not working. I have an example already. I had code that essentially looked like this:void CMyDialog::Write(LPCTSTR lpsz)
{
CString s;
s += lpsz;
When I typed the l of the final lpsz, VAX offered me a suggestion box containing three items: LPCTSTR, LPMARSHAL and lpsz, in that order. lpsz was selected. But when I typed the p, the items in the suggestion box didn't change, but suddenly LPMARSHAL was the selected one.
Of course, what happened was what I described earlier. I saw lpsz selected, but by the time I'd hit tab I'd already hit p, and I got LPMARSHAL instead.
Whichever of acronyms, shorthand and prefixes normally take priority, favouring the previously-favoured symbol should take priority over all of them. Only autotext should have higher priority, because that is guaranteed to produce the same thing every time. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Oct 06 2004 : 12:58:16 PM
|
Here's another example. I typed a t. That's an autotext abbreviation, so I got a suggestion box containing just "true". Then I typed an r. I got a new suggestion box with four entries, all things beginning with Tr or TR, but not containing "true".
This is as documented:
quote:
If you type beyond the name of an Autotext entry, if even the next character is part of the expanded string, the suggestion listbox with Autotext is replaced with a normal suggestion listbox. The new listbox may or may not contain your expanded string. (http://www.wholetomato.com/products/features/autotext.html)
(You mean "even if", not "if even", by the way). But under my rule, "true" would still be present and selected.
I mention this example to show (i) that I think my rule should even apply when coming out of an autotext listbox into a regular suggestion listbox; and (ii) that it's documented that it doesn't behave like I want.  |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
Rainer
Junior Member
Germany
22 Posts |
Posted - Oct 08 2004 : 03:38:18 AM
|
support wrote "For one, an acronym has precedence over a prefix."
I cannot second this. I'm now using the acronym feature for several days. It's very annoying, when I want to type the name of a local variable "sValue" and always get prompted with a suggestion "StringValidation" even if I type "sV".
The precedence should be:
1) local Names regarding case
2) Class Names regarding case
3) Acronyms
4) the Rest as before
and I strongly second Stephen's opinion!
|
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Oct 08 2004 : 04:37:05 AM
|
My inclination too is that prefixes (caseless) should have higher precedence than acronyms. I guess that's just how I usually type. I don't set out to create an acronym — that would require too much advance thought — I only use acronyms (or more likely shorthand) to disambiguate when I am offered two similar symbols.
I don't feel strongly about this, though. And of course it's orthogonal to my main suggestion in this thread. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Oct 08 2004 : 5:38:46 PM
|
We found a problem. Prefixes of symbols in all CAPS are acronyms for those symbols. For example, LP is an acronym for LPLPMARSHAL. This should not be the rule. We will change it.
case=358
Underscores in a symbol force another rule to apply. For example, "wf" will be an acronym for WM_FOO. This type of acronym will have at a lower priority than that of other acronyms, and lower than that of prefixes.
This fix should resolve the "tr" example as well. Too many acronyms matching tr, e.g. TRACE1 and TRACE2, bumped "true" off the list. |
Edited by - support on Oct 08 2004 11:46:05 PM |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Oct 11 2004 : 06:06:02 AM
|
| Of course, I'm all for making the default suggestion smarter, but it doesn't affect my main point — that the suggestion should never change when you type another letter. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Oct 12 2004 : 12:41:45 PM
|
We understand your point. We believe our bug-fix should alleviate the problem. We still want acronyms to have precedence, almost like Autotext has. Our bug simply qualified far too many symbols as acronyms, hence what you where typing kept getting deselected.
We can review this issue after the fix, due in the next build. |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Oct 13 2004 : 07:12:49 AM
|
Well, OK, we can review it later, but I can give you my next example in advance.
I wanted "continue". I typed "c" and was offered "continue". Then I typed "o" and was offered "const" instead (although "continue" was still in the menu).
As usual, what actually happened was that I saw the item I wanted and hit tab, but it was already too late because I'd hit the "o" first, so I ended up with "const" and had to go back and delete it.
There is no autotext for const, I believe. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Oct 18 2004 : 3:43:32 PM
|
| Prefixes of symbols in all caps are no longer acronyms in build 1276. |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Nov 11 2004 : 07:23:24 AM
|
Here's an interesting example from 1283. I had the following variables:CPage *pPageLeft, *pPageRight, *pPageLinked; I typed pp and was offered a suggestion box with pPageLeft, pPageLinked and pPageRight in that order, pPageLeft highlighted. Then I typed an l. pPageRight correctly disappeared from the box, and the highlighting moved from pPageLeft to pPageLinked.
I cannot really understand why Left was preferred for pp, but Linked was preferred for ppl, but maybe "prefixes" and "acronyms" are sorting in different orders? Actually, I think I've shot down that theory. I did some more experiments, and I discovered that if I type ppa instead of ppl, all three suggestions stay, but again the highlighting moves from pPageLeft to pPageLinked.
On this occasion, I actually wanted pPageLinked, but had I wanted pPageLeft, I probably would have accepted the wrong one as described several times above. I do accept that this has got a lot better in recent builds, but my proposed rule would eliminate any dependence on different sort orders, and thus allow me to accept suggestions I see with confidence.
1283, .NET 2003, C++. Acronyms yes, shorthand yes, shrink yes, Intellisense no, Guess contents yes, bits of code yes. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
Baga
Tomato Guru
122 Posts |
Posted - Nov 11 2004 : 11:17:39 AM
|
| When another letter is typed, VA should first check, if current suggession is still valid according to any applicable rules. If it is, it should stay on the list. The only reason to move selection to different item should be matching prefix. |
|
|
|
jpizzi
Tomato Guru
USA
642 Posts |
Posted - Nov 11 2004 : 11:45:34 AM
|
I have seen this, too. I think it stems from the normal action of a list where when you can type a letter, and the first of the items that start with that letter highlights. Type the same letter again, and the next one highlights.
Since the character you type appears in the window, I would think that this is inappropriate behavior for the completion listboxes.
|
Joe Pizzi |
|
|
|
support
Whole Tomato Software
5566 Posts |
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Nov 15 2004 : 7:29:22 PM
|
| Case 439 fixed in 1286. |
|
|
| |
Topic |
|
Topic Locked
