| Author |
 Topic  |
|
|
samdeane
New Member
5 Posts |
 Posted - Jan 16 2006 : 06:46:39 AM
|
I have defined a number of custom auto text items, and assigned shortcuts to them by including '&' in their names.
I've also assigned a custom keyboard shortcut to the insert autotext menu item (esc-I).
Prior to installing 1438, this worked fine. I could hit esc-I-H and get my custom header, and so on.
Now, though, the list that pops up doesn't respond properly to my keyboard shortcuts - often choosing one of the built-in auto text items instead of my ones, although mine are defined first.
Furthermore, the list of autotext items that pops up seems to randomly include only a couple of my items - with the rest only being available via the More Autotext menu.
This has broken a previously very useful feature! |
|
|
samdeane
New Member
5 Posts |
Posted - Jan 16 2006 : 07:08:45 AM
|
Actually, to follow up on my own message, I've realised that the problem is slightly more specific: it's when there is a text selection.
What happens when there's a text selection is that the list only contains auto-text items which contain the $selected$ variable - hence most of my custom items are removed from the list (and buried in the More items submenu).
Whilst this may sound sensible, it's actually often the case that one wants to replace some selected text with an plain autotext item (for example a comment header).
The way it works now is confusing, and counter-intuitive. At the very least, I'd like to see it as an option that I could turn off!
|
 |
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Jan 16 2006 : 4:16:17 PM
|
could you post a couple of example autotext rules for me to test out? i am not quite certain i follow all of the details here, so it would be much easier to just work through a couple of examples.
if you are using C++ autotext then you can simply open "C:\\Program Files\\Visual Assist X\\Autotext\\Cpp.tpl" in a normal text editor and copy / paste the rules to here. the other language autotext rules are in the same directory, just in differently named files. |
zen is the art of being at one with the two'ness |
|
|
|
samdeane
New Member
5 Posts |
Posted - Jan 17 2006 : 04:06:11 AM
|
Here's an example:
a:SCEE Insert &method header::
//!----------------------------\\n
//! $FILE_BASE$::$1$ \\n
//! $end$ \\n
//!----------------------------\\n
//-----------------------------
a:SCEE Insert method ¶meter::
//!\\param $1$ - $end$
With the insert autotext menu item mapped to ESC-I, the key sequence ESC-I-P ought to trigger the method parameter autotext to be inserted. If there is no text selection, it will do so, but if there is a text selection, nothing happens.
// Edited to reduce width of sample Autotext |
Edited by - support on Jan 19 2006 2:47:01 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Jan 17 2006 : 3:56:16 PM
|
i follow now. as you have already spotted, only rules using $selected$ are shown when there is selected text.
the problem with changing this behaviour is that you run the risk of "loosing" code when looking for an autotext rule that effects the selected text. where autotext entries have a title this is shown in the menu instead of a preview of the rule. as a consequence there is no easy way to tell by scanning down the list which items will operate on $selected$ text and which will not.
can you not simply press delete before triggering the autotext lookup when you have selected text? i am aware that this is an extra key press, but we do try to keep the number of options in VA to a minimum, since extra options make a lot of work, due to the way VAX has to be written. |
zen is the art of being at one with the two'ness |
|
|
|
spiderM9
Junior Member
18 Posts |
Posted - Jan 17 2006 : 5:42:55 PM
|
I get this too all the time. here's one:
cp:coke com_ptr
coke::com_ptr<$end$> sp;
and another
qs:
coke::service_ptr<$ns$$iface$, &$ns$SID_$iface$, &$ns$IID_$iface$> sp$end$;
has nothing to do with selected text in my case, but the symptom is identical. |
|
|
|
samdeane
New Member
5 Posts |
Posted - Jan 18 2006 : 03:51:49 AM
|
quote:
the problem with changing this behaviour is that you run the risk of "loosing" code when looking for an autotext rule that effects the selected text.
There are lots of operations which will destructively modify the selection - this is just one of them. Surely that's what Undo is for? |
|
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Jan 19 2006 : 2:37:42 PM
|
i understand what you are saying and why. i even see the appeal to your logic. my concern is the question "how will the user know what to expect?"
if you always get the standard autotext menu then you will never see the autotext entries that require selected text. so when you have selected text you are going to need a longer autotext menu, showing all autotext entries, at which point you no longer know which ones are going to use the selected text and do something with it, and which are simply going to overwrite it with something totally disconnected. |
zen is the art of being at one with the two'ness |
|
|
|
samdeane
New Member
5 Posts |
Posted - Jan 20 2006 : 04:17:23 AM
|
quote:
if you always get the standard autotext menu then you will never see the autotext entries that require selected text. so when you have selected text you are going to need a longer autotext menu, showing all autotext entries, at which point you no longer know which ones are going to use the selected text and do something with it, and which are simply going to overwrite it with something totally disconnected.
There are two issues here:
- understanding what's in the menu
- being able to trigger an autotext insertion using the keyboard
With the first issue, what is really exposed here is an underlying flaw in the user interface for inserting autotext. You've added lots more autotext items, which is nice, but it means that a single linear list is no longer an adequate way of organising them. I think you need to implement a mechanism for organising the autotext entries into folders, which can then be presented to the user as a series of hierarchical menus. Your built-in items can be organised into folders so that they don't fill the top level menu with confusing stuff. You could also include automatically generated menus (in the way that you do now) to make it easy to spot particular kinds of items, like ones that operate with the selection. These automatic menus could be placed at the top, rather than the bottom, of the list, to make them easy to find.
With the second issue, the problem is that having items buried inside submenus stops them from being triggered so easily with the keyboard. A workaround for this would be to allow autotext items to be bound directly to a keypress/action, in the same way that other actions in visual studio can be bound. That way I could unambiguously bind esc-i-m to my method header, esc-i-p to my parameter comment, and so on, without having to ever see the autotext menu. It would also have the advantage that I could add buttons to a palette which would trigger certain autotext insertions, if I so desired. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Jan 24 2006 : 6:38:41 PM
|
i have asked support about this. you are taking a different view point of autotext to how i think it was designed to work. my understanding is that it is primarily designed to be triggered by the shortcuts when you are typing.
the idea of binding a keyboard shortcut to a specific autotext entry is very appealing, and it does solve these problems.
i am not sure where to start thinking about organising the full list of autotext entries into some form of grouped menu. grouping by initial letter is one way forward, perhaps the easiest, but i am not sure how cunning this really is. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
autotext keyboard shortcuts
