Hi:
Ron Wrote:
I don't understand exactly what you're trying to ask here, but I'm going
to try to answer it anyway. You need to call a method of the
Application class, ClientIdentify. If you do not call that, Window-Eyes
has no idea who you are or what client information to provide to you, so
until you do call that, the Application.ClientInformation property is
undefined.
Ron, here is the code where I called the ClientIdentify Method as i detailed
in my prior posts.
WEApp.ClientIdentify( MyIntId )
What other call to this method do I need to do?
By the way, I use the Virtual Earth API if you are interested in Mapping.
Rick USA
----- Original Message -----
From: "Ron Parker" <r...@gwmicro.com>
To: <gw-scripting@gwmicro.com>
Sent: Friday, March 13, 2009 9:32 AM
Subject: Re: Seeking help with VB.NET program
Ricks Place wrote:
Hi Ron: Why would I need to call anything other than the Application
Class if that is a property defined under that class?
I don't understand exactly what you're trying to ask here, but I'm going
to try to answer it anyway. You need to call a method of the Application
class, ClientIdentify. If you do not call that, Window-Eyes has no idea
who you are or what client information to provide to you, so until you do
call that, the Application.ClientInformation property is undefined.
It was decided that trying to access the ClientInformation property when
it was undefined was an indication that there was something fundamentally
wrong with your code, or at the very least with the way your code was
being used, so it should throw an immediate runtime error rather than
return Nothing and have the resulting error wait to appear later.
Also, That is wierd programming. The Getter and Setter, or Letter, as the
case may be if you are using them correctly, should be in the class where
the Property is defined and that class and property should include the
requsit validation on that property prior to sending it out. A default
value would do this.
Properties aren't always just simple storage locations. Sometimes they
refer to aspects of the physical world. Sometimes they refer to derived
information.
For example, consider the case of a GPS navigation object. It has exactly
one thing stored in memory: where you're going. But it doesn't make sense
for the destination location to be the only property of the object; it'd
be pretty useless if it couldn't tell you where you are, which direction
you're facing, and which direction you should go to reach your
destination. Those are all properties of the nagivation state, even
though you didn't directly set them. The first two get changed by actions
that take place entirely outside the nagivation system, when you walk or
drive around. The last one also changes as you walk or drive around, but
it's derived from the other properties and - this is the part that's
particularly relevant here - it's impossible to tell you which direction
you need to go if you haven't yet told the system where you're going. So
changing one property affects the values of another property that you
can't otherwise change directly.
In this case, ClientInformation is derived information, and it's
information that can't be derived until your script identifies itself to
Window-Eyes.
As it now stands you require a user to access the methods and properties
of classes you define as Private.
We don't define them as private. That's part of the COM Interop thingy.
COM Automation itself doesn't even have the concepts of public or private.
We simply define them as not creatable, because they're not.
