quote:

---

Originally posted by feline

We don't have any current plans to do anything like this.

---

quote:

---

Originally posted by feline

These examples are hard coded.

Do you have any specific examples of things you are trying to do?

---

quote:

---

Originally posted by feline

The class example makes sense, and is interesting.

My main concern here is the work required to implement this, verses the benefit our customers will get from it. Using a parsing framework will help with doing it, but first you have to design the language you are going to use, and decide what features it is going to offer.

---

quote:

---

Originally posted by feline

You seem to be suggesting the current autotext system is to complicated, since people are not really using it.

---

quote:

---

Originally posted by sl@sh

1. The amount of predefined autotext entries that come with VA is already intimidating. They might be meant to be useful, but I never really took the time to check them all out. The entries I know most about are those that are triggered by typing common things like "#" or "/**".

---

quote:

---

Originally posted by sl@sh

2. I'm a programmer, not a typist, so most of the time when I type I look at the keyboard and miss all those useful suggestions that unexpectedly pop up at the screen simply because I'm not looking! Of course, when I expect a suggestion to pop up, especially for long typenames and the like, I do see the list, but often much earlier than expected, and filled with a lot of Autotext suggestions that I'm not interested in at all. Waiting for the right suggestions to be presented is sometimes a game of chance, and, as a result, I sometimes need to type a lot more of the actual symbol than I'm comfortable with.

---

quote:

---

Originally posted by sl@sh

3. Invoking autotext entries that refer to 'selected' text is somewhat awkward. You need to select something, then shift-rightclick the selection. Then select 'Insert Autotext', then an entry from a longish list of suggestions. There's various problems of usability I see with this approach:
- There's too many single steps involved.
- The list of autotext entries is quite long, and not all entries in this submenu show what exactly they produce. There's not even a preview, so unless you're already familiar with the autotext entry you're looking for, you have to go trial and error. The description (if present) isn't shown either.
- If you add more custom autotext entries, the submenu gets bigger, along with the above problem.

---

quote:

---

Originally posted by sl@sh

4. In spite of various improvements the autotext editor is still a bit clumsy to use. Here are some issues that I have and which, I think, shouldn't be too hard to improve:
- Calling up the autotext editor takes too many steps for my taste. I'm not even calling it up a lot to edit, just to look up what a certain entry currently is defined like. How about adding a command to open it that I can assign a key to?
- The list of entries is too long to comfortably navigate. I'm missing ways to filter that list, introduce more (user defined) subgroups, or just incremental search.
- The editor window could use a few improvements. I'd suggest a preview (divided into 'before' and 'after' view), and I would very much like a suggestion list popping up whenever I type '$'. (IIRC there's already a case for the latter)

---

quote:

---

Originally posted by sl@sh

Regarding item 3 above, I'd suggest to design a dialog box, similar to the one turning up when you use autotext with parameters. Assigning a key to opening that dialog would reduce it's invocation to a minimum. It could present a list of existing autotext entries that use selected text (just like the submenu currently presented, but not limited in width or length - it could even provide incremental search or filtering). Once the user selects an entry, the dialog could show the entry's description and maybe even a preview.

---

quote:

---

The number of steps is quite easy, IF you already know the answer
Select the text and press the toolbar button for "Insert Autotext", which should be present on the VAssistX toolbar by default.

---

quote:

---

Originally posted by feline

I have never triggered a SQL prompt / query from inside the IDE.

---

quote:

---

Originally posted by feline

gosh I don't understand what you are talking about here.

---

quote:

---

Originally posted by sl@sh

Thanks, feline, for your detailed answer. Some of the things you suggested I wasn't aware of, so that surely helps (and, besides, if I hadn't already known you would be looking at it that closely I might not have bothered to write such a lengthy posting - yes, you can take this as a compliment )

---

$New_type$ *$New_pointer$ = dynamic_cast<$New_type$ *>($Cast_this$);
if($New_pointer$)
{
	$end$
}

quote:

---

Originally posted by feline

I agree that this is a very important thing, but what does this have to do with autotext?

---

    Sub VaxMacro()
        Dim strName
	strName = VAX.AutoText.ResolveString("SymbolName")
        ' or better yet, a deeper object model
	' strName = VAX.Parser.Scope(DTE.ActiveDocument).Name
        DTE.ActiveDocument.Selection.Text = "// " & strName & StrDup(80 - Len(strName), "-") & vbCrLf
    End Sub

quote:

---

Originally posted by kevinsikes


1) Add a scripting engine to Visual Assist X.
2) Expose Visual Assist X AutoText variables to Visual Studio macros through the automation object model.

While each method requires nontrivial development effort, the latter method appeals to me because users can create macros in a familiar environment without learning the intricacies of yet another program's internal script processor.

---

quote:

---

Originally posted by kevinsikes


This may also appease the occasional requests we receive for a VA X API.

A sample Visual Studio VBScript macro would look something like this:

    Sub VaxMacro()
        Dim strName
	strName = VAX.AutoText.ResolveString("SymbolName")
        ' or better yet, a deeper object model
	' strName = VAX.Parser.Scope(DTE.ActiveDocument).Name
        DTE.ActiveDocument.Selection.Text = "// " & strName & StrDup(80 - Len(strName), "-") & vbCrLf
    End Sub

Would this method accomplish your goals? I'm happy to discuss this at our next dev meeting, but I'd like to get an idea of how many customers would find this useful first.

---