A bit more testing revealed that there are two issues, one a bug in my code
and the other a potential issue with the python COM code.
First, I'd written a routine to flash an IE DOM node and moved it into a
class. Unfortunately, I coded it like this in the class:
def DomFlash(node, flashes=5, errorFlag = True, message = None ):
when it should be like this:
def DomFlash(self, node, flashes=5, errorFlag = True, message = None ):
I invoked it thus:
yie.DomFlash(qNode)
and the node did not flash. Coding the correct def, of course, cures this
behavior.
But, while trying to find this bug, I inserted some debug code that raised
the print issue. It is now exhibited in the following code:
qNode = yie.DomGetANodeFilterValue(yie.dom, 'INPUT', 'id;name;value', 'q' )
print '\n***** qnode class <<<%s>>>'%qNode.__class__
print '\n***** qNode=<<<%s>>>'%qNode
print '\n***** DomGetANodeFilterValue
qNode.__str__()<<<%s>>>'%qNode.__str__()
print '\n***** DomGetANodeFilterValue q
Node.__repr__()<<<%s>>>'%qNode.__repr__()
print '\n***** `qnode`<<<%s>>>'%`qNode`
which produces the following output:
***** qnode class
<<<win32com.gen_py.3050F1C5-98B5-11CF-BB82-00AA00BDCE0Bx0x4x0.DispHTMLInputE
lement>>>
***** qNode=<<<>>>
***** DomGetANodeFilterValue qNode.__str__()<<<>>>
***** DomGetANodeFilterValue qNode.__repr__()<<<<win32com.gen_py.Microsoft
HTML Object Library.DispHTMLInputElement instance at 0x26199264>>>>
***** `qNode`<<<<win32com.gen_py.Microsoft HTML Object
Library.DispHTMLInputElement instance at 0x26199264>>>>
The class is correct (as was expected given the earlier test).
Print still does not produce the expected output.
__str__ does not produce the expected output. Since it is defined and print
uses __str__ if it exists, it is unsurprising that print fails.
__repr__ produces the expected output
`qNode` produces the expected output as expected since `` uses __repr__
http://docs.python.org/ref/customization.html provides some interesting
background.
Some checking of the COM interface code (I use early binding) finds the
following code supporting DispHTMLInputElement:
# Default property for this class is 'value'
def __call__(self):
return self._ApplyTypes_(*(-2147413011, 2, (8, 0), (), "value",
None))
# str(ob) and int(ob) will use __call__
def __unicode__(self, *args):
try:
return unicode(self.__call__(*args))
except pythoncom.com_error:
return repr(self)
def __str__(self, *args):
return str(self.__unicode__(*args))
def __int__(self, *args):
return int(self.__call__(*args))
Here __str__ depends on __unicode__ that depends on __call__ that depends on
_ApplyTypes_. This appears to be inherited from DispatchBaseClass via
from win32com.client import DispatchBaseClass
I'm unable to find DispatchBaseClass and so can not chase the issue further
(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.
Regards,
Richard
|-----Original Message-----
|From: [EMAIL PROTECTED] [mailto:python-win32-
|[EMAIL PROTECTED] On Behalf Of Richard Bell
|Sent: Wednesday, July 04, 2007 12:00 PM
|To: 'Emlyn Jones'; python-win32@python.org
|Subject: Re: [python-win32] Strange/impossible Python COM interface
|behavior
|
|
|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 48 sizeU 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
_______________________________________________
Python-win32 mailing list
Python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
