Hi I was wondering if any of you all are familiar with the Python language according to sources on the internet it is compatible with dragons advanced scripting. However, in order to record mouse movements and keystrokes with python a module has to be imported. In this case pyautogui I was wondering if anyone knew if dragon supported the importing of modules like these or not. I could always go back to advanced visual basic but I'm more familiar with python and wanted to see if this was an option. 

-------------------------
Thank you

I have done a lot of Python programming, have experimented with the Python packages that run "in the same process" or synchronously with Dragon, and was quite interested in doing the sort of mouse and keyboard logger thing that you are talking about with Python.

However, I was never able to get this "in the same process" Python stuff working satisfactorily. Actually, I think the basic stuff might've been working, but I found that the Python stuff that interfaces to Windows did not seem to be as mature as the AutoHotKey stuff.

So eventually I switched to AutoHotKey. I would've preferred to stay in Python, because Python code is more likely to be reusable on Linux, if I ever switch to using speech recognition systems such as Kaldi on Linux.

Now, I don't do anything "in the same process" with AutoHotKey. I invoke my AutoHotKey code from Dragon (not-so-)advanced Scripting stubs, that then invokes the AutoHotKey code via ShellExecute. at 1st I was quite disappointed by this, worried about the overhead, but then I realized it was actually more reliable: Dragon would invoke my AutoHotKey code as a separate process, and if the AutoHotKey code hung, Dragon kept running.

You should be able to do the same thing with Python, i.e. invoke it from Dragon via ShellExecute. IIRC I actually did this, until I learned that the Python Windows ecology is not as mature as the AutoHotKey ecology. Essentially whenever I have a problem I can find dozens of answers googling in AutoHotKey, but much less useful education wrt Python and Windows. Did I mention that I'm a UNIX bigot? :-)

---

BTW, if you do this using ShellExecute, whether in Python or AutoHotKey or anything else, you have the option of invoking a new instance or process for each command, or of having your script send a message to a persistent process that does the work. Surprisingly, many many many commands don't need persistence. The performance is not that bad, and the improved reliability of being isolated in separate process instances is quite happy making. Actually, this should not be all that surprising, since 1 of the earliest results of UNIX was in this regard, compared to DEC VAX VMS which uses a command model much closer to that of Windows. (Windows is still headed by Dave Cutler, who came from DEC VMS. classic jokes about Windows NT's initials WNT all being one letter incremented over VMS).

Occasionally you will need persistence. One thing I have enjoyed is that I can use the same persistent AutoHotKey threads/processes for both speech commands and classic hotkey mouse and keyboard shortcuts. For that matter also for CLI command line interface programs. The interface stuff all just sends the appropriate messages to the persistent stuff. You should be able to do the same in Python.

Overall, I think I wasted a lot of time trying to get the "in the same process" stuff of Python working. If I had jumped directly to using ShellExecute for Python I might never have switched to AutoHotKey. Although the AutoHotKey environment for Windows still seems more mature and complete and easier to find code to borrow, even if the AutoHotKey language is pretty ugly.



---

BTW I know that saying "in the same process" is not really the right thing. ShellExecute definitely starts things in separate processes and even tasks. The COM object integration of Python may involve separate threads and separate processes. I'm a bit embarrassed that I don't know the details, but it is my understanding that COM Object integration supports both running code in the same process or in a different process but sharing a lot of memory directly. Perhaps the key thing is that such classic Windows programming tends to share a lot more memory, so that a bug in Python can mess up a DLL's memory segments and vice versa. Even with ShellExecute, if you open up a DLL you are vulnerable to such sharing problems. But at least with ShellExecute you have the option of not doing so. The basic thing is that classic Windows GUI programming often has much less isolation than classic UNIX process oriented programming. This is classic program reliability and security vulnerability stuff.

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

If you want to work in Python, have a look at Talon. It has its own recognizer, can use Dragon as a recognizer, is lightning fast (when not using Dragon), and the python part seems rock solid. I have never had Talon hang on me even once, although I am definitely a lightweight Talon user so far. Talon offers a really nice blend of the best of all worlds - fast recognition with the Talon recognizer in command mode, Dragon-quality free-form dictation, and a very solid Talon/Python implementation. Oh, and Talon is multiplatform and runs on Unix and Macs too. Probably the weakest part of the whole Talon system is the documentation and training - being built on a shoestring blended open-source model, it doesn't have the 25 years of Nuance money behind the documentation and addons.

-------------------------

Win10/11/x64, AMD Ryzen 7 3700X/3950X, 64/128GB RAM, Dragon 15.3, SP 7 Standard, SpeechStart, Office 365, KB 2017, Dragon Capture, Samson Meteor USB Desk Mic, Amazon YUWAKAYI headset, Klim and JUKSTG earbuds with microphones, excellent Sareville Wireless Mono Headset, 3 BenQ 2560x1440 monitors, Microsoft Sculpt Keyboard and Logitech G502 awesome gaming mouse.

 

I don't know where you got the information that Python was compatible with WinWrap Basic(Dragon Advanced Scripting) because it isn't really.   Looking at the possibilities CPython is a non-starter because it binds heavily to the executable which means that once a module is loaded, it is loaded forever. The only way to use CPython is to access it in another process so that the scope of module can be controlled by unloading the process. The PythonNET implementation looks like it has possibilities but it is difficult to integrate seamlessly into WinWrap Basic,  furthermore Dragon Advanced Scripting does not allow for the .NET module implementation available with WinWrap Basic. I did add the .NET module to previous versions of KnowBrainer but that is no longer licensed.

 

 

https://github.com/pythonnet/pythonnet

 

You need to look at NatLink.  Details all over the forum. 

-------------------------