Hi Rod and Doug,
Yes Rod, the get can be confusing but comes in handy if you have a running
object which you want the latest settings of that object while running a
program inside it's environment.
For if that object changes you want to know what it has and will not get
that information if you created another copy that is outside of the original
scope; which is always the case if you create an object from it.
Chip had errors and I was not sure what he was asking for and thought that
maybe he needed a comparison and not an object but Doug had given the example
for creating.
The get might work if getting something from the different tools in the WE
model since there derived from dictionaries of many types, thus get would be
appropriate.
Below is the thing behind the Dictionary which can cause errors if things
are also done out of sequence. The compare mode is needed if you want a key
with a name and don't care about the cap state of the key. In that case you
would do the text compare. Binary of course does it bit by bit...
Example, also using the create:
Dictionary Compare Mode Property
Sets and returns the comparison mode for comparing string keys in a
Dictionary object.
object.CompareMode[ = compare]
Arguments
object
Required. Always the name of a Dictionary object.
compare
Optional. If provided, compare is a value representing the comparison mode.
Acceptable values are
0 (Binary), 1 (Text), 2 (Database).
Values greater than 2 can be used to refer to comparisons using specific Locale
IDs (LCID).
Remarks
An error occurs if you try to change the comparison mode of a Dictionary object
that already contains data.
The following example illustrates the use of the
CompareMode property:
Dim d
Set d = CreateObject("Scripting.Dictionary")
d.CompareMode = vbTextCompare
d.Add "a", "Athens" ' Add some keys and items.
d.Add "b", "Belgrade"
d.Add "c", "Cairo"
' An error occurs on the next line because the key already exists.
' The comparison mode is Text, so the keys are case-insensitive.
d.Add "B", "Baltimore"
Bruce
Sent: Monday, September 09, 2013 2:21 PM
Subject: Re: low-level type of question
Actually I think I'm the one who got confused: I saw you use
Window-Eyes as the object to create, but thought you wanted a
Scripting.Dictionary object in the end, and were only using the
Window-Eyes object as an example. The original poster did want a
Scripting.Dictionary object, which must be created rather than fetched
On Mon, Sep 09, 2013 at 12:33:44PM -0400, Rod Hutton wrote:
Hi Doug,
Thanks for the info. I take it, then, that being able to use
CreateObject to instantiate the Window-Eyes object means that you are
creating a new copy of the Window-Eyes object, whereas GetObject
simply allows the use of the one already available on a system runningia
GetObject.
Window-Eyes. Forgive me, Doug, but as a fairly new programmer using
objects, this is a little confusing. (smile)
bfn,
Rod
Original message:
GetObject is for when you want a reference to something that's already
running. In this case though, he wants something new, that is not
running already. For example, if you are running Microsoft Word and
you want to control it, you might use GetObject("Word.Application").
But if you use CreateObject("Word.Application"), you'll probably
launch a new instance of Word. There is no Scripting.Dictionary object
running and waiting for programs to attach to it. Programs that want a
dictionary object just go make one.
On Sun, Sep 08, 2013 at 12:51:49AM -0400, Rod Hutton wrote:
Chip,
I looked up a note I had made and am wondering if this has something
to do with your problem.
I don't know as much about programming as I will some day, but would
it be better to use "GetObject" rather than "CreateObject"?
Here's the note I had made some time ago:
'To instantiate the window-eyes object externally,
'use either of these forms:
'set WO = GetObject("","windoweyes.application")
'or
'set WO = createObject("windoweyes.application")
hth,
Rod
Subject: low-level type of question
From: "Chip Orange"
<lists3...@comcast.net>
Date: Sat, 7 Sep 2013 17:40:59 -0400
Reply-To:
gw-scripting@gwmicro.com
Hi all,
For those of you who understand the really low-level way in which things
work, I wonder if you could guess at a problem I'm having (I'm just curious
as to why, not that I expect anyone to solve it).
At work I sometimes program in visual foxpro; an interpreted macro language,
much like VBScript. I frequently use activeX objects in these programs.
Recently, because I've learned about the scripting object
scripting.dictionary from my work with Window-eyes, I tried to use this
object in VFP programs. While it executes the CreateObject() just fine,
whenever I try to use any of the methods or properties of the
scripting.dictionary object I get an error from VFP that the property or
method can't be found.
Just wondering if there are different low-level standards for interfacing
with COM objects, and does the scripting.dictionary object require a
specific one (which VFP might not support)?
Thanks for any clues here.
Chip
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug....@ssbbartgroup.com
http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug....@ssbbartgroup.com http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
