HiGuys:
There are advantages and disadvantages to using the .net platform and thus
something lke the free Visual Studio module platforms for creating generic
scripts.
I don't know much, actually anything, about Power Shell.
Of course WE now supports JavaScript under the current script manager model
so that may be an option but I don't know how good JavaScript is for
building apps as stand-alone modules.
Python is a popular scripting language and I think might offer another
avenue for consideration - not sure.
A screen reader has to consider performance options all be it todays
computers are getting pretty bloody fast for executing local code blocks.
While something like vb.net or c++ from the managed environment is a choice
I'm not sure about whether non framework communications via com api objects
for working, scripting, would pose any noticible impact on performance when
working over a non-framework, standard API, like for Thunderbird or other
such platforms.
I would guess it is the same as if working outside the .net framework and
trying to access programs running under the Microsoft framework like
Internet Explorer or Outlook.
Again, I'm not sure this would be a factor since todays computers are
getting very fast and have multi-processors as well as the fact once
compiled the MS code base would run faster than vbscript or javascript as
they are inturpeted.
I am not sure about other languages like Power Shell or Python or some
others.
If I remember another reader uses c++ for some high performance modules and
Python for the UI stuff but only heard a blurb from another programmer about
that.
You can code c++ in Visual Studio or the free versions and the UI is
superior to any other project management packages but, again, I'm not sure
about actual performance comparisons between a managed script and a
non-managed code script.
When I created a External vb.net script it ran with instant response using
the existing WE COM interface so my guess is that compared to using vbscript
the .net platform would be as fast or, perhaps, much faster as a scripting
tool.
That doesn't mean the underlying WE modules and models would use it
necessarily - they may elect tostick with native c++ unless they convert to
using a managed code base, perhaps c++ in the .net environment - don't know
all the technical details.
Anyway, I am sure they have a plan and, for me, it doesn't matter which way
they are headed but I would like to have a heads up about the direction to
scout out the road ahead.
Rick USA
