Mark,
During development of the IE automation class I've frequently gotten a DOM
node by using one of the IE COM interfaces such as nodeList =
ie.getElementsByTagName or one of the interfaces available via a DOM node
such as nodeList = node.getElementsByTagName. To facilitate python
treatment of such list, I convert the HTML collection object into a Python
list with code that like this:
tagNodes = node.getElementsByTagName(tag)
# foundNodes is a COM ElementList, iterate and append to myNodes
for tNode in tagNodes: nodes.append(tNode)
Then when I want one of the individual DOM nodes I just index into the
Python list like this:
aNode = nodes[0]
During development, I've often found it useful to put in some debug
statements to print the object aNode like this:
print aNode
Up until yesterday I'd always found that when I did so I'd get some output
more or less like this:
<win32com.gen_py.Microsoft HTML Object Library.DispHTMLInputElement instance
at 0x...>
During debugging of my def mistake (after correction of the mistake) I had
the following debug print statements in my code:
----- code -----
print '\n***** Try the INPUT node q at www.google.com'
qNode = yie.DomGetANodeFilterValue(yie.dom, 'INPUT', 'id;name;value', 'q' )
print '-- type qNode <<<%s>>>'%type(qNode)
print '-- qNode class <<<%s>>>'%qNode.__class__
print '-- DomGetANodeFilterValue qNode.__str__()<<<%s>>>'%qNode.__str__()
print '-- qNode=<<<%s>>>'%qNode
print '-- DomGetANodeFilterValue qNode.__repr__()<<<%s>>>'%qNode.__repr__()
print '-- `qnode`<<<%s>>>'%`qNode`
print '\n***** Try the same node when returned as a list'
qNode2 = yie.DomGetNListFilterValue(yie.dom, 'INPUT', 'id;name;value', 'q')
print '-- type qNode2 <<<%s>>>'%type(qNode2)
print '-- len(qNode2) <<<%s>>>'%len(qNode2)
print '-- qNode2 <<<%s>>>'%qNode2
print '-- qNode2[0] <<<%s>>>'%qNode2[0]
print '-- qNode2[0] class <<<%s>>>'%qNode2[0].__class__
print '\n***** Try yie.dom, an HTML node'
print '-- typw yie.dom <<<%s>>>'%type(yie.dom)
print '-- yie.dom class <<<%s>>>'%yie.dom.__class__
print '-- yie.dom <<<%s>>>'%yie.dom
print '\n***** Try the body node'
bNode = yie.DomGetNList(yie.dom, 'BODY')
print '-- bNode class <<<%s>>>'%bNode.__class__
print '-- bNode <<<%s>>>'%bNode
print '\n***** Try DIV id=gbar'
dNode = yie.DomGetANodeFilterProperties(yie.dom, 'DIV', 'id=gbar')
print '-- dNode class <<<%s>>>'%dNode.__class__
print '-- dNode <<<%s>>>'%dNode
----- end code -----
This code produces the following output:
----- output -----
***** Try the INPUT node q at www.google.com
-- type qNode <<<<type 'instance'>>>>
-- qNode class
<<<win32com.gen_py.3050F1C5-98B5-11CF-BB82-00AA00BDCE0Bx0x4x0.DispHTMLInputE
lement>>>
-- DomGetANodeFilterValue qNode.__str__()<<<>>>
-- qNode=<<<>>>
-- DomGetANodeFilterValue qNode.__repr__()<<<<win32com.gen_py.Microsoft HTML
Object Library.DispHTMLInputElement instance at 0x26228016>>>>
-- `qnode`<<<<win32com.gen_py.Microsoft HTML Object
Library.DispHTMLInputElement instance at 0x26228016>>>>
***** Try the same node when returned as a list
-- type qNode2 <<<<type 'list'>>>>
-- len(qNode2) <<<1>>>
-- qNode2 <<<[<win32com.gen_py.Microsoft HTML Object
Library.DispHTMLInputElement instance at 0x26228136>]>>>
-- qNode2[0] <<<>>>
-- qNode2[0] class
<<<win32com.gen_py.3050F1C5-98B5-11CF-BB82-00AA00BDCE0Bx0x4x0.DispHTMLInputE
lement>>>
***** Try yie.dom, an HTML node
-- typw yie.dom <<<<type 'instance'>>>>
-- yie.dom class
<<<win32com.gen_py.3050F1C5-98B5-11CF-BB82-00AA00BDCE0Bx0x4x0.DispHTMLHtmlEl
ement>>>
-- yie.dom <<<<win32com.gen_py.Microsoft HTML Object
Library.DispHTMLHtmlElement instance at 0x26227416>>>>
***** Try the body node
-- bNode class <<<<type 'list'>>>>
-- bNode <<<[<win32com.gen_py.Microsoft HTML Object Library.DispHTMLBody
instance at 0x26228536>]>>>
***** Try DIV id=gbar
-- dNode class
<<<win32com.gen_py.3050F1C5-98B5-11CF-BB82-00AA00BDCE0Bx0x4x0.DispHTMLDivEle
ment>>>
-- dNode <<<<win32com.gen_py.Microsoft HTML Object
Library.DispHTMLDivElement instance at 0x26227576>>>>
----- end output ---
Several things caught my attention about this.
First, the attempt to print qNode (an object of class
win32com.gen_py.3050F1C5-98B5-11CF-BB82-00AA00BDCE0Bx0x4x0.DispHTMLInputElem
ent) produces a zero length string. However print of nodes for other HTML
tags such as HTML, BODY, or DIV produces strings that describe the object.
Second, when the INPUT node named 'q' is returned as an item in a list (see
qNode2) printing the list prints the item. I'm not sure what's different
about printing an item in a list vs printing the item, but clearly something
different is involved even though the underlying object is of the same type.
So it is possible to print some DOM nodes and get a non-zero length string,
but not all DOM nodes, and (at least insofar as I've looked) it is possible
to print all DOM nodes when an item is in a list.
This seems to me rather uneven (and unhandy) behavior, but I'm not really
sure it's a bug. I did poke a bit more at the Win32Com code but got to
_ApplyTypes_ where my understanding vanished.
Please forgive the length of this message but I wanted to try to be clear.
Regards,
Richard
|-----Original Message-----
|From: Mark Hammond [mailto:[EMAIL PROTECTED]
|Sent: Wednesday, July 04, 2007 6:10 PM
|To: 'Richard Bell'; python-win32@python.org
|Subject: RE: [python-win32] Strange/impossible Python COM interface
|behavior
|
|> from win32com.client import DispatchBaseClass
|>
|> I'm unable to find DispatchBaseClass and so can not chase the
|> issue further
|
|Its in win32com.client.__init__.py
|
|> (never mind that I'm a bit over my head in the Win32Com code).
|> Interestingly, __repr__ is NOT in the GenPY output code, so I
|> assume it is
|> also in DispatchBaseClass. I'm guessing that _ApplyTypes_ is
|> misbehaving
|> but am not sure.
|>
|> In any event, thanks for your assistance. While not resolved
|> the problem is
|> not critical since it only involves print and there is a work
|> around via ``.
|> Hopefully, Mark will pick up this thread and be able to shed
|> a bit of light.
|
|I'm afraid I don't understand the problem you are currently trying to
|demonstrate. Doing str(com_obj) will attempt to use the com object's
|"default" method or property and use that, while 'repr' does not. This is
|mainly done for things like ADO 'field' objects, where the default method
|fetches the value for the field, for example.
|
|Mark
_______________________________________________
Python-win32 mailing list
Python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
