Ron Henderson wrote:
Tim Golden wrote:
Ron Henderson wrote:
Thanks so much for trying this out. You've verified that it's
possible to get this working.
However, when I execute the same code, the file "p2.csv" is exactly
same size as p1.mpp and contains binary data, not the text. Since you
Ron Henderson wrote:
...
>>> print open (FILENAME).read ()
╨╧◄αí▒
I'm not sure how those binary characters will be handled by my email
client, but essentially the file "p2.csv" seems to have been written
out as a binary project file, not as a CSV file. If I open the file
"p2.csv" in Projec
Tim Golden wrote:
Ron Henderson wrote:
Thanks so much for trying this out. You've verified that it's
possible to get this working.
However, when I execute the same code, the file "p2.csv" is exactly
same size as p1.mpp and contains binary data, not the text. Since you
have it working it mu
Ron Henderson wrote:
Thanks so much for trying this out. You've verified that it's possible
to get this working.
However, when I execute the same code, the file "p2.csv" is exactly same
size as p1.mpp and contains binary data, not the text. Since you have
it working it must be a bug in eith
Ron Henderson wrote:
Thanks so much for trying this out. You've verified that it's possible
to get this working.
However, when I execute the same code, the file "p2.csv" is exactly same
size as p1.mpp and contains binary data, not the text. Since you have
it working it must be a bug in eith
Thanks so much for trying this out. You've verified that it's possible
to get this working.
However, when I execute the same code, the file "p2.csv" is exactly same
size as p1.mpp and contains binary data, not the text. Since you have
it working it must be a bug in either my version of MSPro
Can you confirm that the output is really a CVS (text) file? When I tried
this the file that was written was still a binary .mpp file, i.e., the
FormatID was ignored.
This works for me (I basically recorded a Macro and reproduced it):
import win32com.client
project = win32com.client.Disp
Roger Upole wrote:
Ron Henderson wrote:
My guess is that it *is* a Python problem somewhere in the win32com
bindings, based on the fact that executing a macro seems to do the
right thing but going directly through the com API from Python does not.
The macro executes essentially the same funct
Ron Henderson wrote:
My guess is that it *is* a Python problem somewhere in the win32com
bindings, based on the fact that executing a macro seems to do the right
thing but going directly through the com API from Python does not.
The macro executes essentially the same functionality:
Sub my_ex
Ron Henderson wrote:
My guess is that it *is* a Python problem somewhere in the win32com
bindings, based on the fact that executing a macro seems to do the right
thing but going directly through the com API from Python does not.
Ah. You cunningly missed that out from your previous description
My guess is that it *is* a Python problem somewhere in the win32com
bindings, based on the fact that executing a macro seems to do the right
thing but going directly through the com API from Python does not.
The macro executes essentially the same functionality:
Sub my_export()
FileSaveAs
Ron Henderson wrote:
Does anybody know how to avoid the "Export Wizard" when saving a file
with MSProject? The FileSaveAs method seems to ignore the Map keyword.
Hopefully someone here will have a clue (altho' it won't be me :) )
But have you tried posting to an MS-specific group? It doesn't
Does anybody know how to avoid the "Export Wizard" when saving a file
with MSProject? The FileSaveAs method seems to ignore the Map keyword.
My code looks essentially like this:
mp = Dispatch("MSProject.Application")
mp.FileOpen(mppFile)
mp.FileSaveAs(csvFile, Format=3, Map="My Export Map")
m
13 matches
Mail list logo
