Registering and logging in removes this ad.
Registering and logging in removes this ad.
Window specific macros
Submitted by Adrian Byrne on Sat, 07/21/2007 - 20:42.
I have a piece of code that I wish to work within a specific Word template.
I am not sure if my problem is a bug in the DNS software, an install problem on my PC (I have gone through V7,8,9 and recently hacked in some demo templates having got Larry Allens book) OR a oversight on my part in creating the macro command.
Basically what I have is a form. I have set the template up so that it renames the caption window when a new doc is created. I then have set my DNS macro to act only in the specific window for this doc type. I cannot get it to work. The commands I am using to go to specific fields are being picked up as commands in any Word document. This creates an error that I am trapping (as the bookmarks are not there) but of course once the "command" is initiated there is no elegant way I can find to make it go back and ignore it.
Anyone else experienced this problem?
Help much appreciated as although it's a trivial thing I've spent all day playing with it and it's drivin' me nuts. Think I'll go for a beer 
With scripts the devil is
With scripts the devil is often in the details. Maybe someone knows exactly what your problem is, but if not you may have to help yourself by posting the actual script.
Good luck!
Bruce
I don't have a problem with
I don't have a problem with the VB script as such. That's working fine. I can't find where DNS stores the stuff. I just have a problem with where it is being enacted from. I cannot find any script relating to this bit. I suppose it may be somewhere in mycmds.dat but the save times don't correlate and I can't see anything.
Can you confirm that the DNS functionality I am trying to use actually works for MS Word?
Thanks
Adrian Byrne wrote: I don't
I don't have a problem with the VB script as such. That's working fine. I can't find where DNS stores the stuff. I just have a problem with where it is being enacted from. I cannot find any script relating to this bit. I suppose it may be somewhere in mycmds.dat but the save times don't correlate and I can't see anything.
Can you confirm that the DNS functionality I am trying to use actually works for MS Word?
Thanks
Adrian,
I concur with Bruce. Supposing that I were to call you on the phone and tell you that my car just stopped running in the middle of an intersection and ask you what the problem was. Would you be able to tell me?
When you're posting a problem on any of the speech recognition forums, you need to provide as much detail as possible; including your CPU, CPU speed, whether you're using a desktop or laptop, RAM, and you need to provide us with the script, as well as some of the details in the script dialog.
All scripts that you create are located in the MyCmds.dat for the user that is loaded. You can find any of your scripts that you have created (i.e., custom commands) in the Command Browser. Simply say "open command browser." If you know the command name that you gave to the command, you can use the filter button to locate it. If you don't, click on the Manage link and search through your custom commands.
Until or unless you can provide us with these details, we can't help you.
Chuck Runquist
Former Dragon NaturallySpeaking SDK & Senior Technical Solutions PM for DNS
"Problems cannot be solved by the same level of thinking that created them." – Albert Einstein
Window-specific commands
Window-specific commands don't work in word processors the way most would expect that they'd work. In other words, Window-specific commands are not a method to have commands work for one document but not for another.
Buried within the Help files of DNS 9.5 is the statement:
"You can create multiple commands with the same name only if the commands are specific to a certain window within an application. For example, although you can open multiple documents in separate windows in Microsoft Word for Windows XP, if you try to create more than one command with the same name for that program, Dragon NaturallySpeaking will tell you that there is already a command with that name"
There is probably a way to handle your situation some other way. Some situations can be handled using Structured States, others by checking window captions within macros, others using DNS dialog boxes, and I'm sure there are other methods. There is enough ambiguity in the terms "form," "template," and "field" that I can't tell exactly what you are attempting.
Larry Allen
http://www.pcspeak.com
Thank you both. I am highly
Thank you both. I am highly hooured to have such eminent experts responding to my post.
The script I have is a prototype to a idea I have to implement some report templates in a hospital setting. I want to jump around fields (bookmarks) by saying their name. I do not want these names to have to be document unique as they are words like "from" in this case. The prototype I have is based on a fax while I see how to get it to work. I have adapted it from something else I picked up. I open a new fax doc with command "Create Fax" and a auto macro in the template renames the doc window (caption) from Documentx to Fax. I thought this would allow me to tie DNS commands to that Window. What Larry says now seems to be the problem I have. Effectively the different Window name in Word is not a different or unique application window i.e. DNS will see it as a generic document window whatever. My code is below. Would be grateful for any idea on how else to achieve this thanks:
Option Explicit
Dim bookmarkName As String
Dim pos As Integer
Sub Main
On Error GoTo handleerror
pos = InStr(UtilityProvider.ContextValue(0), "\")
bookmarkName=Mid$(UtilityProvider.ContextValue(0),1,pos-1)
Word.ActiveDocument.Bookmarks(bookmarkName).Select
HeardWord "\Cap"
Exit Sub
handleerror:
' I put this next bit in just to send the bookmark name to the doc but it is no good as a solution
SendKeys Mid$(UtilityProvider.ContextValue(0),pos+1)
End Sub
I will guess that there are
I will guess that there are many different bookmark names and that you are constrained by being told you can not change the bookmark names. Some of those names are likely default names such as "Text1" and "Text2" where "Text2" may be a patient name in one document, a date in another document, etc.
Your error handling of sending what was said isn't too bad in my opinion, but you may be just as well off writing nothing if a bookmark isn't found. I'd strongly suggest making the commands something like "go to " or "go " or " field" so all these commands will be a couple of words or more and unlikely to appear in normal dictation.
I'd have one command. Start the command as you have already done, then do something like:
caption = ... ' get the window caption, determining type of form
Spoken = Mid$(UtilityProvider.ContextValue(0),pos+1)
Select Case caption
Case "fax"
Select Case Spoken
Case "name"
Word.ActiveDocument.Bookmarks("Text1").Select
Case "fax number"
Word.ActiveDocument.Bookmarks("Text2").Select
Case "subject"
Word.ActiveDocument.Bookmarks("Subject").Select
Case "intake"
Select Case Spoken
Case "name"
Word.ActiveDocument.Bookmarks("patient").Select
Case "referring physician"
Word.ActiveDocument.Bookmarks("Text2").Select
Case "insurance"
Word.ActiveDocument.Bookmarks("ins").Select
...
That is, the same command would be executed for each form but the command would determine the form type then what to do for each valid bookmark name.
There are other alternates, depending on number of forms, consistency of bookmark names, whether the forms use protected Word fields or not, ...
Larry Allen
http://www.pcspeak.com
Hello Larry, others, The
Hello Larry, others,
The statement from the help files above is a complete riddle to me. The help files also simply state:
Window-specific: The command will be available in the window you specify....
As there is no other information about Windows specific commands, I stick to my earlier observations that Windows specific commands simply suck. Should be considered as a serious bug in NatSpeak 9, and I think also in NatSpeak 8.
Because of this bug I support your workaround with getting the window title when a command is hit.
Quintijn
PS Instead of
you can simply use
Quote: As there is no other
As there is no other information about Windows specific commands, I stick to my earlier observations that Windows specific commands simply suck. Should be considered as a serious bug in NatSpeak 9, and I think also in NatSpeak 8.
Quintijn,
Granted, there are some limitations when using the "window specific" option in Advanced Scripting. However, you don't go back far enough. The same functionality existed as far back as 1998 when SpeechOne was acquired by L&H. Advanced Scripting is based on SpeechLinks, which was introduced into L&H Voice Xpress 5.0 way back. If it's such a useless command option, why has nobody complained until now. You all had almost 10 years to do so.
There are other workarounds for this. However, since I cannot see exactly what Adrian is doing, and I would have to see it in action, I can't be more specific. However, I do know this. There are limitations to the "window specific" option when using templates if the user designates the template as the "window specific" option is supplied. The simple reason for this is that the option applies to the template, not to the document. Otherwise, me "window specific" option generally works fine. This is one of those issues that I would put in the category of "why can't I have my cake and eat it too" bugs.
Chuck Runquist
Former Dragon NaturallySpeaking SDK & Senior Technical Solutions PM for DNS
"Problems cannot be solved by the same level of thinking that created them." – Albert Einstein
Hello Chuck, I didn't
Hello Chuck,
I didn't complain earlier because I can work around with natlink/natpython/unimacro, in which this issue doesn't arise.
And I believe my colleagues of inTAAL in Utrecht (the Netherlands) have reported this bug.
Anyhow this is something to complain about, and the fact that it only shows up now doesn't make it a less serious bug.
I do not see the difference between window and template in this respect.
Greetings, Quintijn
Sorry, I don't see how a
Sorry, I don't see how a feature becomes a bug?! I've got at least a hundred (probably more like hundreds) of Windows-specific commands and can't recall any problems with them.
I don't know the context is which you made your statement, but I would suggest it may reflect your idiosyncratic situation and perhaps a failure to understand the capability, which, after all, is quite common in most structured programming languages with which I'm familiar.
This capability is useful if you want the same command to have different effects depending on the Windows context -- a situation that arises often in applications. Otherwise, you essentially revert to the default universal scope so that a given command always has the same effect regardless of where it is issued -- not a desirable situation in many cases.
It may not be a critical capability, but it is a nice convenience for users. Of course, I can't come up with a specific instance at the moment, but I recall that I used to use "OK" throughout Quicken to close a dialog box etc., and the actual keystroke sequence would vary considerably depending on the context.
Bruce
BruceCyr wrote: Sorry, I
Sorry, I don't see how a feature becomes a bug?! I've got at least a hundred (probably more like hundreds) of Windows-specific commands and can't recall any problems with them.
I don't know the context is which you made your statement, but I would suggest it may reflect your idiosyncratic situation and perhaps a failure to understand the capability, which, after all, is quite common in most structured programming languages with which I'm familiar.
This capability is useful if you want the same command to have different effects depending on the Windows context -- a situation that arises often in applications. Otherwise, you essentially revert to the default universal scope so that a given command always has the same effect regardless of where it is issued -- not a desirable situation in many cases.
It may not be a critical capability, but it is a nice convenience for users. Of course, I can't come up with a specific instance at the moment, but I recall that I used to use "OK" throughout Quicken to close a dialog box etc., and the actual keystroke sequence would vary considerably depending on the context.
Bruce
Bruce,
Thank you. Your rant made my day. If you're ever in Howell New Jersey, look me up and I'll buy you as many beers as you can handle.
Chuck Runquist
Former Dragon NaturallySpeaking SDK & Senior Technical Solutions PM for DNS
As scarce as truth is, the supply has always been in excess of the demand. - Josh Billings (1818-1885)
Moi, rant!? Surely you
Moi, rant!? Surely you speak facetiously
Although Quentijn may be right that this feature is not adequately documented -- a critique that could be applied to many aspects of Pro scripting.
Bruce
Quintijn wrote: Hello
Hello Chuck,
I didn't complain earlier because I can work around with natlink/natpython/unimacro, in which this issue doesn't arise.
And I believe my colleagues of inTAAL in Utrecht (the Netherlands) have reported this bug.
Anyhow this is something to complain about, and the fact that it only shows up now doesn't make it a less serious bug.
I do not see the difference between window and template in this respect.
Greetings, Quintijn
Quintijn,
I don't disagree with you that there are some problems with this particular option. However, having worked with Kevin O'Donnell in incorporating SpeechLinks into L&H Voice Xpress and Dragon NaturallySpeaking 5/6, it functions as it was originally designed (Advanced Scripting – SDK technical specifications for DNS 5 and 6, which I wrote). Therefore, it is a design flaw vs. an actual bug. But, before you go off on a tangent about what is a bug, consider that as a developer and a programmer the technical definition of a bug is something that doesn't function as designed and/or crashes the system or the application. If it doesn't function as someone thinks it ought to, then it's a design issue, which one can legitimately argue is a flaw, but not a bug. What that simply means it is not that it should not be corrected, but that it's handled differently by development teams. That is, even if it's reported, it's not what is considered a "showstopper."
If I can get a clearer picture of exactly what the problem is, and again I need to see it in action with a specific example that I can actually test out on my systems, then I will go directly to the programming team at Nuance and discuss it with them since I do still have direct contact with the VP and the senior director of R&D, with whom I worked at L&H and who are still at Nuance.
So, I'm not trying to argue with you, I'm simply trying to clearly define (i.e. in a Step-by-Step with clear examples method) that a specific problem with this option can be tested, duplicated, and verified. Otherwise, Nuance development isn't going to touch it with a 10 foot pole. They don't have the time to put for the kind of effort required to find a problem based on the fact that somebody simply says "there is a problem." I have some insight into this process because I used to maintain the bug database and my function as SDK PM Technical Solutions Project Manager was to work directly with the programmers and QA to identify that absolutely required correction and those issues that can or should be deferred to a later date. During my tenure, this issue would never ever came up. Part of this process was going out and asking and users how many of them were experiencing this particular problem. I can tell you from Nuance's perspective that if only one or 2 people are sharing this particular type of problem with them, they're going to ignore it.
Just the way it works in the industry. Give a clear-cut, Step-by-Step, detailed explanation and examples that allow programmers to replicate the problem, and you'll get results. But unless someone does this clearly, it's going to get ignored. Been there done that.
Chuck Runquist
Former Dragon NaturallySpeaking SDK & Senior Technical Solutions PM for DNS
"Debugging is always harder than programming, so if you write code as cleverly as you know how, by definition you will be unable to debug it." -- unknown
Chuck, Bruce, Well, when
Chuck, Bruce,
Well, when somebody mentions a problem that I've experienced before, I at least want to raise the hypothesis that there is a bug found in NatSpeak.
And when the command browser has a button for Windows specific, which I cannot interpret different from "corresponding with the text in the title bar", I think there should be more explanation about this button or it should simply work that way.
But, OTOH, I did a few tests with problems that arose before, as far as I can remember, and I can not produce them.
I find though your statement "that is how the industry works" to firm. If users complain about things that do not work, it is of course better when those things can be reproduced by a step-by-step process. In that way I pointed and also worked around several issues in the past.
If an error cannot be reproduced this way (that easily) you cannot say the error isn't there. Maybe other users can report on this issue.
Greetings, Quintijn
Quintijn, I'm still a little
Quintijn,
I'm still a little confused about your specific problem.In my experience, window-specific commands work well, but they have their limits, as Larry explained.
To give an example, when I first moved to Advanced Scripting, I had trouble writing commands that would work in any Contract in Microsoft Outlook, because each contact has its own specific title, such as "Contact - Matt Chambers". I discovered, however, that I could edit the window title to only contain part of the window name, and now I have a macro that works in all Contacts.
Does that help?
From my perspective, this
From my perspective, this issue would be clarified if Nuance would document to users what it considers a "window" for the purpose of defining "window-specific" commands.
Even if that was publically documented in detailed technical terminology, others would at least have a chance at translating such a definition into language that others could understand. As it stands now, we have to guess what is intended. Perhaps this was documented in one of your specifications, Chuck?
It has been at least 3-4 years since I've asked, but the answers have always been vague.
Larry Allen
Larry Allen wrote: From my
From my perspective, this issue would be clarified if Nuance would document to users what it considers a "window" for the purpose of defining "window-specific" commands.
Even if that was publically documented in detailed technical terminology, others would at least have a chance at translating such a definition into language that others could understand. As it stands now, we have to guess what is intended. Perhaps this was documented in one of your specifications, Chuck?
It has been at least 3-4 years since I've asked, but the answers have always been vague.
Larry Allen
First of all, I understand everyone's concerns. Basically you're preaching to the choir.
Second, technical specifications do not include anything relative to documentation or help. Technical specifications only include program code and program function based on that code (i.e. how is the code is supposed to work). The documentation and help writers then take the specifications and are responsible for writing the documentation and help files. Therefore, they dropped the ball on this one.
Lastly, I don't doubt that what they are vague on this functionality. Since I worked directly with Kevin O'Donnell on the technical specifications for the incorporation of Advanced Scripting in Dragon NaturallySpeaking, Kevin was supposed to work with the documentation and help people. There may have been some documentation written by Kevin on the specific functions of features and options in Advanced Scripting, but if there were, they never got translated into documents included with the program. I don't think that there is anyone left at Nuance who has specifically researched this particular function, and the original documentation for SpeechLinks may have, in fact, and lost during the acquisition. Or, because Kevin felt that he had been ripped off as a result of the resolution of Chapter 11, he may have taken it all with him. It was always a part of SpeechLinks, but I don't think anyone really spelled out the functionality and/or of the definition of "window specific" other than perhaps Kevin. He was let go because of legal actions taken against L&H prior to the Chapter 11 resolution and the acquisition by ScanSoft. Unfortunately, you can order somebody to leave all code and documents behind, but Kevin is a lawyer in addition to being a programmer, and I don't doubt but what he may have just simply put the screws to L&H and left only the source code, taking all the documentation with him. Who knows. I'm sure there's nobody at Nuance that does, at least nobody left.
Chuck Runquist
Former Dragon NaturallySpeaking SDK & Senior Technical Solutions PM for DNS
"Debugging is always harder than programming, so if you write code as cleverly as you know how, by definition you will be unable to debug it." -- unknown
Chuck Runquist
From my perspective, this issue would be clarified if Nuance would document to users what it considers a "window" for the purpose of defining "window-specific" commands.
Even if that was publically documented in detailed technical terminology, others would at least have a chance at translating such a definition into language that others could understand. As it stands now, we have to guess what is intended. Perhaps this was documented in one of your specifications, Chuck?
It has been at least 3-4 years since I've asked, but the answers have always been vague.
Larry Allen
First of all, I understand everyone's concerns. Basically you're preaching to the choir.
Perhaps the choir has ears and will begin to sing as they understand the preaching?
Matt, Sorry, no it doesn't
Matt,
Sorry, no it doesn't help. I had problems in the past with specific commands in the spell window, and this window definitely has only "Spell" in the title.
In earlier versions, I think I remembered from DragonDictate, it was possible to match only part of the window title, for example "Message" in an outlook messages window. But this part is not described in the documentation.
Your second remark seems to fail with my initial test: when testing for a specific command that only works in an HTML message window of Outlook, having a window title .... (HTML)... and I give only "HTML" (or "(HTML)") as window title the command is not recognized.
Greetings, Quintijn
PS I do not bother, because in unimacro it works all very well... (and in vocola too)
Try "Message (HTML)" as the
Try "Message (HTML)" as the title. Works for me, at least.
Okay, that works. But you
Okay, that works. But you agree, I hope, that Nuance has a lot to explain on this issue.
Nice weekend, Quintijn
I absolutely agree. It took
I absolutely agree. It took me weeks or months to figure out how to write scripts for the various sub-windows In Microsoft Outlook on a window-specific basis.
I have just caught up on all
I have just caught up on all the discussion. I have concluded that for MSWord regardless of Window Title the NS App sees a document window as a document window and that's that.
There are some work arounds for this and thanks for those as they are a little more elegant than my first stab. This is never going to be satisfactory however as you lose something by sending the text through a script and then just dumping it in the document. In particular I am talking about leading spaces and caps as the script cannot determine whether this is required.
I think the suggestion of making the bookmark a unique command is the best so user can say something like "goto bookmark x" and then the command will never process in a "normal" doc template and if the user does inadvertently say this then nothing will happen, which is fine, well not ideal but ok
Thanks