Hi Tom and Rod
Thank you very much for your prompt replies.
I am aware that the scripting object itself is not made available outside
Window-eyes. However, the Keyboard object, in whose events I am interested,
is returned by the KeyBoard property of the Application object.
So, once I've instantiated the application object, I was expecting to get
access to all of Window-eyes objects, their properties, methods and events,
apart of course from the Scripting Object. The issue is I can't access the
events.
Here is the code in VB. This works, but doesn't give me the events.
VB:
Dim WeEApp as Object
Dim WeKeyBoard as Object
Sub Main()
WeAPP = CreateObject("Windoweyes.application")
WeKeyboard = WeApp.keyboard
End Sub
VB End
This returns a Keyboard object, whose properties I have proved I can access
in VB by messenging out the Boolean variable returned by the
KeyDescriberActive property. Similarly, the following code shuts down
Window-eyes as it should do:
VB:
WeApp.quit
VB End
But I can't access the KeyBoard's events. The compiler says the event (eg
OnKeyUp) doesn't exist for that object. Events for the Application object
are given similar short shrift by the VB compiler.
Powershell behaves in exactly the same way.
I realise that VB Script is the natural way to code scripts for Window-eyes,
and I have done so in the past. My problem is that I need a script to access
a serial [port to control an external peripheral. I have an old API that
runs in VB Script that allows me to do this, but it will only run on Windows
7. So, as soon as my Windows 7 PC dies, I am stuck. I have searched high and
low and cannot find a way of accessing the serial port in VB Script unless I
shell out £130 to a company for paid-for software. I am trying to avoid
this. VB and Powershell do have native access to the serial port. But
without Window-eyes's events, I can't write code I can control at run time.
So there's the problem. The barrier is that, outside of VB Script, I can't
access the Keyboard and the Application events, and I can't find a means of
accessing the serial port in VB Script that works in Windows 10!
Tom's final paragraph regardin IDespatch and late binding may give a
pointer. Are you able to elaborate on this or give me any further pointers?
Any ideas very welcome!
Kind Regards
Stuart Foster
-----Original Message-----
From: Scripting
[mailto:scripting-bounces+stuart.foster=btinternet....@lists.window-eyes.com
] On Behalf Of Tom Kingston via Scripting
Sent: 04 March 2017 02:52
To: Rod Hutton <rod_hut...@hotmail.com>; Window-Eyes Scripting List
<scripting@lists.window-eyes.com>
Subject: Re: Accessing events from external code
Stuart,
Rod is right about the Script object. But that's because it's specific
to scripts hosted by Window-Eyes. The Application object is the doorway
for external scripts. It also is for hosted scripts. But this has all
been taken care of up front so folks writing hosted scripts don't have
to deal with it.
Unless there is a real reason you need to use VB you're actually better
off using VBScript. Yes, it's an interpreted language. But it's hosted
by Window-Eyes and therefore is handled in process by Window-Eyes.
Conversely, a VB script will run out of process. So there will be a lot
of inter-process communication that will slow things down significantly.
The only time compiled VB will increase performance is if you need to do
serious computational crunching. And the only other reason to use VB is
if you need access to things such as API calls that VBScript can't give
you. And finally, when writing an external script you have to do a lot
of work that has already been done for us when writing hosted scripts.
The problem with events is that event handlers MUST support IDispatch.
Window-Eyes won't call the vTable interface for them. So you can't use
early binding or direct access, which is another performance hit. Things
must be constructed on the fly (late binding) rather than pre-compiled
from the COM interface.
Hth,
Tom
On 3/3/2017 7:55 PM, Rod Hutton via Scripting wrote:
Hi Stuart,
I copied this excerpt from the information panel of the main Script node
in the App Developer's manual and this explains your situation:
Script properties, methods, and events are only available for scripts
hosted under Window-Eyes. External, un-hosted scripts will not have access
to any of the Script object properties, methods, or events.
I would add that the same seems to be true for the Keyboard object.
However, the fact that this is true implies that there are alternative
means of gathering the information you require.
I hope this helps,
Rod
-----Original Message-----
From: Scripting
[mailto:scripting-bounces+rod_hutton=hotmail....@lists.window-eyes.com] On
Behalf Of Stuart Foster via Scripting
Sent: Friday, March 3, 2017 6:13 AM
To: scripting@lists.window-eyes.com
Subject: Accessing events from external code
Hi
I've been trying to write code that accesses the Window-eyes com
Automation
object model from Visual Studio and Powershell. These do not run under the
Window-eyes environment. I have been able to instantiate the Windoweyes
Object Model, and access the objects' properties and methods. But I cannot
access the events. Both PowerShell and the Visual Studio compiler report
that the event I am accessing does not exist for the object. Here is what
I
have done, in both PowerShell and a Visual Studio VB module:
Instantiate the Object Model - success
Set up a local variable object for the Windoeyes Keyboard - success
Demonstrated that I can test the keyboard.KeyDescriberActive state by
outputting a variable giving the Boolean value - success
Run the application.onquit method to close Window-eyes - success
Used the application,speech.speak method to speak out strings - success
Attempted to access the keyboard.OnKeyProcessedUp and OnKeyUp events. In
both environments, the compiler and interpreter report that the event does
not exist for the object.
Any ideas? Any help much appreciated.
With thanks
Regards
Stuart Foster
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com/attachme
nts/20170303/caabf8b0/attachment.htm>
_______________________________________________
Any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/rod_hutto
n%40hotmail.com.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
_______________________________________________
Any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/tom.kings
ton%40charter.net.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/stuart.fo
ster%40btinternet.com.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
