Hi Mark,
It doesn´t work with the following code:
-----------------
import win32com.client
oLv = win32com.client.gencache.EnsureDispatch("LabView.Application")
strVi = "D:\\Projects\\py.lv.test\\pytest.vi"
oViTest = oLv.GetVIReference(strVi,"",True)
obViTest._FlagAsMethod("Call")
bError = True # to preset object
strResult = "" # to preset object
arParNames = ["strEntry","strOutput","bError"] # first and second are
strings, third is bool
arParVals = ["Hello World", strResult, bError] # first input, second+third
output
oViTest.Call(arParNames,arParVals)
-------------------
I got the following error messages:
Traceback (most recent call last):
File
"D:\Python24\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py", line
310, in RunScript
exec codeObject in __main__.__dict__
File "D:\Projects\py.lv.test\lv3.py", line 6, in ?
oLv = win32com.client.gencache.EnsureDispatch("LabView.Application")
File "D:\Python24\Lib\site-packages\win32com\client\gencache.py", line 529,
in EnsureDispatch
disp = win32com.client.Dispatch(prog_id)
File "D:\Python24\Lib\site-packages\win32com\client\__init__.py", line 96, in
Dispatch
return __WrapDispatch(dispatch, userName, resultCLSID, typeinfo,
UnicodeToString, clsctx)
File "D:\Python24\Lib\site-packages\win32com\client\__init__.py", line 38, in
__WrapDispatch
klass = gencache.GetClassForCLSID(resultCLSID)
File "D:\Python24\Lib\site-packages\win32com\client\gencache.py", line 179,
in GetClassForCLSID
mod = GetModuleForCLSID(clsid)
File "D:\Python24\Lib\site-packages\win32com\client\gencache.py", line 240,
in GetModuleForCLSID
makepy.GenerateChildFromTypeLibSpec(sub_mod, info)
File "D:\Python24\Lib\site-packages\win32com\client\makepy.py", line 306, in
GenerateChildFromTypeLibSpec
__import__("win32com.gen_py." + dir_name + "." + child)
ImportError: No module named _Iapplication
-----------------------------
In the meantime I found an article here
http://www.talkaboutprogramming.com/group/comp.lang.python/messages/253859.html
I tried it and it worked!!
I used the following lines, changed the name of the makepy genereated .py file
into labfiew.py, copied it into the dir of the script and it works.
import labview
oLv = labview.Application()
But now I ran into another problem.
There is no data coming back from LabVIEW via the Call method.
The arParVals List is unchanged after the call. Normaly the last two elements
should held the result of the VI call.
In the other directon it´s working, I´m able to see the string "Hello World" in
LabVIEW.
--------------------------
>From LV-Doc
object.Call([paramName, paramVals])
paramNames : array of strings by ref (Names of the front panel objects that act
as input and output parameters to the call).
paramVals: array of variants by ref (Input values for the input parameters and
return values from the output parameters in the order in which the names were
specified in paramNames)
---------------------------
Is a list object at that point not the right thing on python side ??
Thanks in advance
Martin
-----Original Message-----
From: Mark Hammond [mailto:[EMAIL PROTECTED]
Sent: Friday, 24. June 2005 16:12
To: Kuner Martin; python-win32@python.org
Subject: RE: [python-win32] win32com problem with LabVIEW
> I try to talk with Python to a LabVIEW-Application called "cbt" via
> ActiveX.
>
> Now I´m running into problem calling the "Call" method.
>
> Here´s the code:
> ------------
> import win32com.client
> oLv = win32com.client.Dispatch("cbt.Application")
Try either
oLv = win32com.client.gencache.EnsureDispatch("cbt.Application")
or:
> strVi = oLv.ApplicationDirectory + "\\cbt.exe\\" + "cdcAxLogPrint.vi"
>
> # retrieving the reference to the VI to be called via "Call"
> oViLogPrint = oLv.GetVIReference(strVi,"",True)
>
> arIn = ["strEntry","Error"]
> arOut = ["Hello World",True]
>
obViLogPrint._FlagAsMethod("Call")
> oViLogPrint.Call(arIn,arOut)
> ------------
> The resulting error message:
> oViLogPrint.Call(arIn,arOut)
> TypeError: 'NoneType' object is not callable
The problem is that .Call is being interpreted as a property reference rather
than a method call. The former should trigger early-binding, which should
avoid the problem. If that doesn't work, the latter is still using
late-binding, but offering a hint to win32com that Call is a method rather than
a property.
Mark
_______________________________________________
Python-win32 mailing list
Python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
