Thanks Emlyn, that's got me a bit further. I tried your suggestions and
also tried to see if the object was the one expected. Here's the output:
node0 = nodes[0]
print 'DomGetANodeFilterValue type', type(node0)
# DomGetANodeFilterValue type <type 'instance'>
print 'DomGetANodeFilterValue tagName[%s]'%node0.tagName
#DomGetANodeFilterValue tagName[INPUT]
print 'DomGetANodeFilterValue outerHTML[%s]'%node0.outerHTML
#DomGetANodeFilterValue outerHTML[<INPUT title="Google Search"
maxLength=2048 size=55 name=q>]
#It appears that node0 is the desired node, notwithstanding the
print issue
print 'DomGetANodeFilterValue nodes[0].__repr__()
%s'%nodes[0].__repr__()
# DomGetANodeFilterValue nodes[0].__repr__()
<win32com.gen_py.Microsoft HTML Object Library.DispHTMLInputElement instance
at 0x26199304>
print 'DomGetANodeFilterValue nodes[0].__unicode__()
%s'%nodes[0].__unicode__()
# DomGetANodeFilterValue nodes[0].__unicode__()
The first couple of prints tell me that the object node0 is the one expected
and seems to be useable in that I can reference the objects properties and
get the expected values. Interestingly __repr__ returns the right kind of
object reference.
I'll look into your list item suggestion as that seems more likely to be the
essential part of the issue.
Thanks again.
Richard
|-----Original Message-----
|From: [EMAIL PROTECTED] [mailto:python-win32-
|[EMAIL PROTECTED] On Behalf Of Emlyn Jones
|Sent: Wednesday, July 04, 2007 11:22 AM
|To: python-win32@python.org
|Subject: Re: [python-win32] Strange/impossible Python COM interface
|behavior
|
|On 7/4/07, Richard Bell <[EMAIL PROTECTED]> wrote:
|>
|> In my continued work on a COM automation interface for IE I've
|encountered a
|> strange/impossible Python behavior. Here's what appears to be the
|offending
|> code:
|>
|> ----- code -----
|> nodes = self.DomGetNListFilterValue(node, tags, properties,
|value,
|> intoFrames, errorFlag,
|message)
|> print 'DomGetANodeFilterValue', nodes
|> #DomGetANodeFilterValue [<win32com.gen_py.Microsoft HTML Object
|> Library.DispHTMLInputElement instance at 0x34839088>]
|> print 'DomGetANodeFilterValue', len(nodes)
|> #DomGetANodeFilterValue 1
|> print 'DomGetANodeFilterValue[%s]'%nodes[0]
|> #DomGetANodeFilterValue[]
|> if len(nodes) == 1:
|> print 'DomGetANodeFilterValue[%s]'%(nodes[0])
|> #DomGetANodeFilterValue[]
|> #but under debugger,
|> #nodes[0]
|> #<win32com.gen_py.Microsoft HTML Object
|> Library.DispHTMLInputElement instance at 0x34839088>
|> return nodes[0]
|> ----- end code -----
|>
|> The call to DomGetNListFilterValue returns a list with 1 object per the
|> print statements (the comments contain the print statements output). But
|an
|> attempt to reference the object returns nothing per the following print
|> statement. Curiously, setting a break point and referencing nodes[0]
|DOES
|> return the correct value!?! I've never seen this kind of behavior. Does
|> anyone have any clues?
|>
|Hello,
|Not had much to do with COM but I would check out what
|<win32com.gen_py.Microsoft HTML Object> Library.DispHTMLInputElement'
|s implementation of __str__ does. What happens if you try
|nodes[0].__repr__() (or nodes[0].__unicode__()?)
|I can't think off the top of my head what the builtin to retrieve a
|list item is from a list object but that might be worth checking too.
|
|Cheers,
|Emlyn.
|--
|() ascii ribbon campaign - against html e-mail
|/\ www.asciiribbon.org - against proprietary attachments
|_______________________________________________
|Python-win32 mailing list
|Python-win32@python.org
|http://mail.python.org/mailman/listinfo/python-win32
_______________________________________________
Python-win32 mailing list
Python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
