Probably most of you who use custom commands have occasionally found where Dragon does not like the name that you have chosen for a command. The first thing you may have tried was to say the command while holding down the Control key to force recognition of a command. In that did not work, you probably checked to see what was recognized in the Recognition History. If incorrect, you may have tried to Train the name in the Command Browser. If that did not work, you may have then trained the words individually in the Vocabulary Editor. Failing that, you may have entered the entire command name in the Vocabulary Editor. If that still did not work, you probably just gave up and changed the name to something different that fickle Dragon liked better and would recognize. But, if you REALLY wanted your original name instead, I found a different approach that works. Having gone through all of the above with my "Reply To Hannah" command failing repetitively, I changed it to "Choose Hannah" which fickle Dragon accepted readily. Then, I clicked on New Copy, and made the name of that command: "Reply To Hannah", and guess what, I fooled the Dragon and it worked right off and recurrently.

MDH

Mark,

so that would indicate that internally, Dragon also has some  sort of "formerly known as" references to fall back on, just like when we can't seem to manage to adopt to something new, but rather stick with the old, for convenience. Well, hard to believe, and difficult to control, but a nice idea nonetheless.

But maybe the real effect underlying continuous misrecognition (a concept inherent in continuous recognition also), was something else, although I am not certain, and speculating rather in fact. I also have a theory for it, but I don't want to reveal it so soon, however ask you to do a little testing the next time it happens (a custom command not being recognized that is).

Please be so kind to do the following. Create a new command with the same name, but under a different context, make it a scripting command and insert the line below between Sub Main and End Sub:

MsgBox "That worked."

Instead of "That worked." you may also insert anything else in here, between the quotes, the whole purpose of it is to bring up a message box displaying some text to verify whether or not the command has been recognized. The most important thing, however, I would ask you is to not train the command prior to using it.

Thanks in advance.

Rüdiger

Well, it's past the point where we can make any changes in the code, but we can still make changes to the Easter Egg!

Rudiger,

Tried above with "Reply To Wilke", "Reply To Lunis", and "Reply To Janaly" and thjese all worked first time. Then tried "Reply To Bougeous" (last name of someone who works in my office). It did not work repetively. Then swapped out the command lines instead for the MsgBox "It Worked" and still not properly recognized. Instead, recognized as "Reply To Sheila". See Recognition History attached.

MDH

Recognition History FOR REPLY TO BOUGEOUS.txt  (15 KB)

Mark,

thanks. So isn't getting "reply to bourgeois" instead of "Reply to Bougeous" something special?  - My idea was this, however. If, per your description, doing all of the training and re-training it just doesn't work, you may have overtrained it. So I took your explanation as an indicator that when re-creating is as a new command, even using the same name, you start from scratch (with no training underlying the name), and that was what solved it.

Rüdiger

Well, it's past the point where we can make any changes in the code, but we can still make changes to the Easter Egg!

Rudiger,

I should also add that when it was ably to repetively recognize "reply to bougeois" (note the"i" instead of "u", but not the Reply To Bougeous command (written with the caps), even pressing the Control key, yielding the "Reply To Sheila" command instead.

MDH

Mark,

in that particular case, most likely the problem is with the underlying pronunciations generated by Dragon when entering the proper name (which isn't really English spelling), and a little confusion created around it. Since you are back to using version 10, there is an interesting method to find out, making them visible for that matter. I will contact you offline about it.

Rüdiger

Well, it's past the point where we can make any changes in the code, but we can still make changes to the Easter Egg!

Rudiger,

Thanks.

MDH

Mark,

I concur with Rüdiger's assessment. However, and just FYI, back during the initial testing of DNS 10.0, there were a lot of consistent reports relative to this type of problem. Most of these referred to Text and Graphics macros not executing properly and most of them also were a result of importing and upgrading previous version (9.5) user profiles. These were fixed, at least most of them, by the initial release of DNS 10.0, along with some additional fixes to related issues that came along with the update to DNS 10.1. I haven't seen anybody report any of these recently except for your situation, but I'm not completely surprised. Windows burps from time to time producing some oddball results and errors, and so does DNS. However, my suspicion is that it's more of a quirk, and maybe just situationally related, rather than being anything major, which is why I concur with Rüdiger.

I haven't seen this problem occur in a long time and I've never seen it occur in DNS 11.5 or DMPE. However, since you've gone back to DNS 10.1 Medical, the occurrence of these types of command misrecognitions was related to cross version issues. I'm not saying that that's the case in your particular situation having gone back from DMPE to DNS 10.1 Medical. All I'm saying is that the problems generally occurred when updating and across versions, and mostly occurred in DNS 10. I've seen what you're saying and what I've done when this occurred way back in before the Civil War was to simply copy the code from the script, delete the original, create a new script with the same command name, and paste the code back in. In the few cases where I ran into this problem way back when it first reared its ugly head, the procedure that I used generally worked. Nonetheless, I haven't experienced this problem over the course of using DNS 10.1 Medical, which I still do under Windows XP even though solely for testing and support issues. In fact, this post is dictated with DNS 10.1 Medical under Windows XP just to point out that I still use it on a regular basis.

Just adding my $.02 worth to this discussion.

Chuck Runquist
Technical Project Manager
VoiceTeach LLC
Home of VoicePower®: We don't make Dragon NaturallySpeaking, We make it better!

Logic 101: Post Hoc fallacy - The logical fallacy of believing that temporal succession implies a causal relation