Windows install to custom location after building from source

[Tim Golden]

Only if you don't pass an msi file on the command line. So
I recommend that you do that.
OK.


Please, no. The only way I could accept that if merge.py would
be run at the end of msi.py (i.e. merge.py disappears).

Understood.

TJG

 

[Krishnakant]

Hi Terry,

Well, You did reply i know, but seems i lost that mail some where,
My mail client must have messed up the mail.

any ways thanks for your reply,
Right now I am stuck very badly.

The problem is that I am trying python-ooolib and did find the library
pritty good.
But the problem is that library is missing a major feature from my
requirement context.
I need to merge cells in a spreadsheet and this library won't do that.

Do you know how I can work around this?

I tryed searching for py2odf but did ont find any results.

Do you want me to continue on the previous thread (I will try and dig
that out ).


happy hacking.
Krishnakant.

 

[John Machin]

Hi Terry,

Well, You did reply i know, but seems i lost that mail some where,
My mail client must have messed up the mail.

It sure messed up when it hijacked two existing threads when sending
messages, so I'm not surprised if it's filing incoming mail in the
wrong place

any ways thanks for your reply,
Right now I am stuck very badly.

The problem is that I am trying python-ooolib and did find the library
pritty good.

There's another one called ooolib-python; have you had a look at that?

But the problem is that library is missing a major feature from my
requirement context.
I need to merge cells in a spreadsheet and this library won't do that.

Do you know how I can work around this?

Here's a radical suggestion: Ask the author directly, or pop a note in
the suggestion box on the sourceforge tracker [hint: don't use your
mail client for this].

I tryed searching for py2odf but did ont find any results.

Do you want me to continue on the previous thread (I will try and dig
that out ).

Nah, just hijack a third thread

Cheers,
John

 

[Terry Reedy]

Hi Terry,

Well, You did reply i know, but seems i lost that mail some where,
My mail client must have messed up the mail.

any ways thanks for your reply,
Right now I am stuck very badly.

The problem is that I am trying python-ooolib and did find the library
pritty good.
But the problem is that library is missing a major feature from my
requirement context.
I need to merge cells in a spreadsheet and this library won't do that.

I think you are confusing process and result. The result is a cell that
spans more than one column or row *when displayed*, thus hiding the
cells that would otherwise be displayed. This is, I am 99.9% sure,
controlled by an attribute of the visually expanded cell.

In OOCalc, the process is to mark a block of cells and select Format /
Merge Cells. But still, the result will be a change in the upper left
attribute. Thus I suggested you make a .ods file with expanded cells
and then read the xml to see what cell element attribute is set thereby.
Any decent odf library will be able to set element attributes.

If the about-to-be hidden cells are not empty, OOCcalc gives you the
option of converting all cell contents to strings and joining them into
one string in the expanded cell. If you create .ods from scratch, you
should never need to do this. If you edit an existing .ods, something like
' '.join(str(cell.contents for cell in merge_group))
possibly in a function that also sets the attribute, should be easy
enough to write. And, of course, you will be able to do things other
than the one option OOCalc gives you.

In other words, I do not think you *need* an existing cell-merge function.

Do you know how I can work around this?

See above.

I tryed searching for py2odf but did ont find any results.

Whoops. odfpy at
http://opendocumentfellowship.com/development/projects/odfpy

but I strongly suspect you can do what you want with python-ooolib.

Terry Jan Reedy

 

[John Machin]

I think you are confusing process and result.  The result is a cell that
spans more than one column or row *when displayed*, thus hiding the
cells that would otherwise be displayed. This is, I am 99.9% sure,
controlled by an attribute of the visually expanded cell.

In OOCalc, the process is to mark a block of cells and select Format /
Merge Cells.  But still, the result will be a change in the upper left
attribute.  Thus I suggested you make a .ods file with expanded cells
and then read the xml to see what cell element attribute is set thereby.
Any decent odf library will be able to set element attributes.

It doesn't appear to be quite so simple.

ODS uses a <table:table-cell> element as usual for the upper left
cell. Attributes set the range e.g. table:number-columns-spanned="3"
table:number-rows-spanned="2"

The gotcha is that it uses a *different* element for the cells covered
by the range. Example:
<table:covered-table-cell table:number-columns-repeated="2" />

This is looks like structural amendments are needed to a package like
(python-)?ooolib(-python)? that doesn't grok merged cells -- its
source doesn't contain the string "covered". Doesn't seem like it
could be done just by poking in attributes.

Here's an example of 2 merged ranges: A1:C2 contains the text "foo"
and D12 contains "bar"

<table:table-row table:style-name="ro1">
- <table:table-cell table:style-name="ce1" office:value-type="string"
table:number-columns-spanned="3" table:number-rows-spanned="2">
<text>foo</text>
</table:table-cell>
<table:covered-table-cell table:number-columns-repeated="2" />
- <table:table-cell table:style-name="ce1" office:value-type="string"
table:number-columns-spanned="1" table:number-rows-spanned="2">
<text>bar</text>
</table:table-cell>
</table:table-row>
- <table:table-row table:style-name="ro1">
<table:covered-table-cell table:number-columns-repeated="4" />
</table:table-row>

Aside: If you are wondering where the cell addresses (D1 etc) are,
they're in the reader's current_row and current_col variables
Perhaps this was intended to save space, but what of table:number-
columns-repeated="4" ??

Cheers,
John

 

[Tim Golden]

Latest attempt: merge.py runs but produces errors. Unfortunately
I know next to nothing about what MSI's trying to do here, except
in the most general sense that it's bringing auxiliary files into
the main MSI database.

I attach the merge.log output but I'll try to do some
research to understand what's going on here in any case.
In particular it's not clear to me whether the thing
has worked but has just tripped up over some non-essential
part, or whether these are real errors. (I really need
to set up a virtual machine which doesn't have VS2008).

For the record, running it by sticking execfile (merge) at
the end of msi.py has the same effect.

TJG

Opened MSI Database: python-2.7.14312.msi
Opened Merge Module: C:\Program Files\Common Files\Merge Modules\Microsoft_VC90_CRT_x86.msm
Merging Table: ModuleSignature
o Merging row: Microsoft_VC90_CRT_x86.0138F525_6C8A_333F_A105_14AE030B9A54
Merging Table: Directory
Merging generated Directory actions into Database Table: AdminUISequence
Merging Sequence Table: ModuleAdminExecuteSequence into Database Table: AdminExecuteSequence
Base Action CostInitialize in AdminExecuteSequence table already exists in MSI. Using MSI action.
Placing action WindowsFolder.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54 before CostInitialize
Merging Sequence Table: ModuleAdvtExecuteSequence into Database Table: AdvtExecuteSequence
Base Action MsiPublishAssemblies in AdvtExecuteSequence table already exists in MSI. Using MSI action.
Merging generated Directory actions into Database Table: InstallUISequence
Merging Sequence Table: ModuleInstallExecuteSequence into Database Table: InstallExecuteSequence
Base Action CostInitialize in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action MsiPublishAssemblies in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action AllocateRegistrySpace in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action InstallFiles in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action InstallFinalize in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action MsiUnpublishAssemblies in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action RemoveFiles in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action RemoveRegistryValues in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action WriteRegistryValues in InstallExecuteSequence table already exists in MSI. Using MSI action.
Placing action SxsUninstallCA after InstallFinalize
Placing action WindowsFolder.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54 before CostInitialize
Placing action SxsInstallCA before AllocateRegistrySpace
Merging Table: File
o Merging row: ul_msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing ul_msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 13 to 2695.
o Merging row: nosxs_msvcr90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing nosxs_msvcr90.dll.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 8 to 2690.
o Merging row: nosxs_msvcp90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing nosxs_msvcp90.dll.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 7 to 2689.
o Merging row: nosxs_msvcm90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing nosxs_msvcm90.dll.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 6 to 2688.
o Merging row: ul_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing ul_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 10 to 2692.
o Merging row: ul_catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing ul_catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 9 to 2691.
o Merging row: ul_msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing ul_msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 12 to 2694.
o Merging row: ul_msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing ul_msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 11 to 2693.
o Merging row: msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 5 to 2687.
o Merging row: msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 4 to 2686.
o Merging row: msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 3 to 2685.
o Merging row: manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 2 to 2684.
o Merging row: catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
* Changing catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 1 to 2683.
Merging Table: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation o Merging row: _Validation
o Merging row: _Validation
o Merging row: _SummaryInformation
o Merging row: _SummaryInformation
o Merging row: AdminExecuteSequence
o Merging row: AdminExecuteSequence
o Merging row: AdminExecuteSequence
o Merging row: AdminUISequence
o Merging row: AdminUISequence
o Merging row: AdminUISequence
o Merging row: AdvtExecuteSequence
o Merging row: AdvtExecuteSequence
o Merging row: AdvtExecuteSequence
o Merging row: Binary
o Merging row: Binary
o Merging row: Component
o Merging row: Component
o Merging row: Component
o Merging row: Component
o Merging row: Component
o Merging row: Component
o Merging row: Directory
o Merging row: Directory
o Merging row: Directory
o Merging row: CustomAction o Merging row: CustomAction
o Merging row: CustomAction
o Merging row: CustomAction
o Merging row: FeatureComponents
o Merging row: FeatureComponents
o Merging row: File o Merging row: File
o Merging row: File
o Merging row: File
o Merging row: File
o Merging row: File
o Merging row: File
o Merging row: File
o Merging row: InstallExecuteSequence
o Merging row: InstallExecuteSequence
o Merging row: InstallExecuteSequence
o Merging row: InstallUISequence
o Merging row: InstallUISequence
o Merging row: InstallUISequence
o Merging row: ModuleAdminExecuteSequence
o Merging row: ModuleAdminExecuteSequence
o Merging row: ModuleAdminExecuteSequence
o Merging row: ModuleAdminExecuteSequence
o Merging row: ModuleAdminExecuteSequence
o Merging row: ModuleAdvtExecuteSequence
o Merging row: ModuleAdvtExecuteSequence
o Merging row: ModuleAdvtExecuteSequence
o Merging row: ModuleAdvtExecuteSequence
o Merging row: ModuleAdvtExecuteSequence
o Merging row: ModuleComponents
o Merging row: ModuleComponents
o Merging row: ModuleComponents
o Merging row: ModuleSignature
o Merging row: ModuleSignature
o Merging row: ModuleSignature
o Merging row: ModuleInstallExecuteSequence
o Merging row: ModuleInstallExecuteSequence
o Merging row: ModuleInstallExecuteSequence
o Merging row: ModuleInstallExecuteSequence
o Merging row: ModuleInstallExecuteSequence
o Merging row: MsiAssembly
o Merging row: MsiAssembly
o Merging row: MsiAssembly
o Merging row: MsiAssembly
o Merging row: MsiAssembly
o Merging row: MsiAssemblyName
o Merging row: MsiAssemblyName
o Merging row: MsiAssemblyName
o Merging row: MsiFileHash
o Merging row: MsiFileHash
o Merging row: MsiFileHash
o Merging row: MsiFileHash
o Merging row: MsiFileHash
o Merging row: MsiFileHash
o Merging row: MsiSFCBypass
o Merging row: Property
o Merging row: Property
o Merging row: Registry
o Merging row: Registry
o Merging row: Registry
o Merging row: Registry
o Merging row: Registry
o Merging row: Registry
o Merging row: SxsMsmGenComponents
o Merging row: SxsMsmGenComponents
Merging Table: Binary
o Merging row: SxsUninstallCA
Merging Table: Component
o Merging row: nosxs.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: uplevel.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: downlevel_payload.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: downlevel_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
Merging Table: CustomAction
o Merging row: SxsUninstallCA
o Merging row: WindowsFolder.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: SxsInstallCA
Merging Table: ModuleComponents
o Merging row: nosxs.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: uplevel.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: downlevel_payload.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: downlevel_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
Merging Table: MsiAssembly
o Merging row: uplevel.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
Merging Table: MsiAssemblyName
o Merging row: uplevel.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: uplevel.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: uplevel.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: uplevel.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: uplevel.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
Merging Table: MsiFileHash
o Merging row: ul_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: ul_catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
Merging Table: MsiSFCBypass
o Merging row: ul_msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: nosxs_msvcr90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: nosxs_msvcp90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: nosxs_msvcm90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: ul_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: ul_catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: ul_msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: ul_msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
Merging Table: Property
o Merging row: ALLUSERS
o Merging row: Dummy_Microsoft_VC90_CRT_x86.0138F525_6C8A_333F_A105_14AE030B9A54
Merging Table: Registry
o Merging row: reg_nosxs.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: reg_downlevel_payload.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: reg_downlevel_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
Merging Table: SxsMsmGenComponents
o Merging row: downlevel_payload.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Merging row: downlevel_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
Connecting Merge Module Components to Feature: SharedCRT
o Connecting Component: nosxs.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Connecting Component: uplevel.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Connecting Component: downlevel_payload.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
o Connecting Component: downlevel_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
Extracting MergeModule CAB to c:\docume~1\timgol~1\locals~1\temp\tmpd38jky.cab.
c:\docume~1\timgol~1\locals~1\temp\tmpd38jky.cab extracted successfully.
Module file list requested...
o Retrieved file [ul_msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE]...
o Retrieved file [nosxs_msvcr90.dll.0138F525_6C8A_333F_A105_14AE030B9A54]...
o Retrieved file [nosxs_msvcp90.dll.0138F525_6C8A_333F_A105_14AE030B9A54]...
o Retrieved file [nosxs_msvcm90.dll.0138F525_6C8A_333F_A105_14AE030B9A54]...
o Retrieved file [ul_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030]...
o Retrieved file [ul_catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B]...
o Retrieved file [ul_msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE]...
o Retrieved file [ul_msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE]...
o Retrieved file [msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030]...
o Retrieved file [msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030]...
o Retrieved file [msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030]...
o Retrieved file [manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A]...
o Retrieved file [catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A5]...
Module file list complete...
Closed Merge Module.
Opened Merge Module: C:\Program Files\Common Files\Merge Modules\policy_9_0_Microsoft_VC90_CRT_x86.msm
Merging Table: ModuleSignature
o Merging row: policy_9_0_Microsoft_VC90_CRT_x86.52105B6B_A3EF_3A90_882A_947B287C203A
Merging Table: Directory
Merging generated Directory actions into Database Table: AdminUISequence
Merging Sequence Table: ModuleAdminExecuteSequence into Database Table: AdminExecuteSequence
Base Action CostInitialize in AdminExecuteSequence table already exists in MSI. Using MSI action.
Placing action WindowsFolder.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A before CostInitialize
Merging Sequence Table: ModuleAdvtExecuteSequence into Database Table: AdvtExecuteSequence
Base Action MsiPublishAssemblies in AdvtExecuteSequence table already exists in MSI. Using MSI action.
Merging generated Directory actions into Database Table: InstallUISequence
Merging Sequence Table: ModuleInstallExecuteSequence into Database Table: InstallExecuteSequence
Base Action CostInitialize in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action MsiPublishAssemblies in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action AllocateRegistrySpace in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action InstallFiles in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action InstallFinalize in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action MsiUnpublishAssemblies in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action RemoveFiles in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action RemoveRegistryValues in InstallExecuteSequence table already exists in MSI. Using MSI action.
Base Action WriteRegistryValues in InstallExecuteSequence table already exists in MSI. Using MSI action.
Placing action SxsUninstallCA after InstallFinalize
Placing action WindowsFolder.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A before CostInitialize
Placing action SxsInstallCA before AllocateRegistrySpaceMerging Table: File
o Merging row: ul_policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
* Changing ul_policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A's Sequence Column from 4 to 2699.
o Merging row: ul_catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
* Changing ul_catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A's Sequence Column from 3 to 2698.
o Merging row: policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
* Changing policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A's Sequence Column from 2 to 2697.
o Merging row: catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
* Changing catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A's Sequence Column from 1 to 2696.
Merging Table: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation
o Merging row: _Validation o Merging row: _Validation
o Merging row: _Validation
o Merging row: _SummaryInformation
o Merging row: _SummaryInformation
o Merging row: AdminExecuteSequence
o Merging row: AdminExecuteSequence
o Merging row: AdminExecuteSequence
o Merging row: AdminUISequence
o Merging row: AdminUISequence
o Merging row: AdminUISequence
o Merging row: AdvtExecuteSequence
o Merging row: AdvtExecuteSequence
o Merging row: AdvtExecuteSequence
o Merging row: Binary
o Merging row: Binary
o Merging row: Component
o Merging row: Component
o Merging row: Component
o Merging row: Component
o Merging row: Component
o Merging row: Component
o Merging row: Directory
o Merging row: Directory
o Merging row: Directory
o Merging row: CustomAction o Merging row: CustomAction
o Merging row: CustomAction
o Merging row: CustomAction
o Merging row: FeatureComponents
o Merging row: FeatureComponents
o Merging row: File o Merging row: File
o Merging row: File
o Merging row: File
o Merging row: File
o Merging row: File
o Merging row: File
o Merging row: File
o Merging row: InstallExecuteSequence
o Merging row: InstallExecuteSequence
o Merging row: InstallExecuteSequence
o Merging row: InstallUISequence
o Merging row: InstallUISequence
o Merging row: InstallUISequence
o Merging row: ModuleAdminExecuteSequence
o Merging row: ModuleAdminExecuteSequence
o Merging row: ModuleAdminExecuteSequence
o Merging row: ModuleAdminExecuteSequence
o Merging row: ModuleAdminExecuteSequence
o Merging row: ModuleAdvtExecuteSequence
o Merging row: ModuleAdvtExecuteSequence
o Merging row: ModuleAdvtExecuteSequence
o Merging row: ModuleAdvtExecuteSequence
o Merging row: ModuleAdvtExecuteSequence
o Merging row: ModuleComponents
o Merging row: ModuleComponents
o Merging row: ModuleComponents
o Merging row: ModuleSignature
o Merging row: ModuleSignature
o Merging row: ModuleSignature
o Merging row: ModuleDependency
o Merging row: ModuleDependency
o Merging row: ModuleDependency
o Merging row: ModuleDependency
o Merging row: ModuleDependency
o Merging row: ModuleInstallExecuteSequence
o Merging row: ModuleInstallExecuteSequence
o Merging row: ModuleInstallExecuteSequence
o Merging row: ModuleInstallExecuteSequence
o Merging row: ModuleInstallExecuteSequence
o Merging row: MsiAssembly
o Merging row: MsiAssembly
o Merging row: MsiAssembly
o Merging row: MsiAssembly
o Merging row: MsiAssembly
o Merging row: MsiAssemblyName
o Merging row: MsiAssemblyName
o Merging row: MsiAssemblyName
o Merging row: MsiFileHash
o Merging row: MsiFileHash
o Merging row: MsiFileHash
o Merging row: MsiFileHash
o Merging row: MsiFileHash
o Merging row: MsiFileHash
o Merging row: MsiSFCBypass
o Merging row: Property
o Merging row: Property
o Merging row: Registry
o Merging row: Registry
o Merging row: Registry
o Merging row: Registry
o Merging row: Registry
o Merging row: Registry
o Merging row: SxsMsmGenComponents
o Merging row: SxsMsmGenComponents
Merging Table: Binary
o Merging row: SxsUninstallCA
Merging Table: Component
o Merging row: uplevel.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: downlevel_manifest.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
Merging Table: CustomAction
o Merging row: SxsUninstallCA
o Merging row: WindowsFolder.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: SxsInstallCA
Merging Table: ModuleComponents
o Merging row: uplevel.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: downlevel_manifest.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
Merging Table: ModuleDependency
o Merging row: policy_9_0_Microsoft_VC90_CRT_x86.52105B6B_A3EF_3A90_882A_947B287C203A
Merging Table: MsiAssembly
o Merging row: uplevel.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
Merging Table: MsiAssemblyName
o Merging row: uplevel.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: uplevel.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: uplevel.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: uplevel.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: uplevel.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
Merging Table: MsiFileHash
o Merging row: ul_policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: ul_catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
Merging Table: MsiSFCBypass
o Merging row: ul_policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: ul_catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Merging row: catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
Merging Table: Property
o Merging row: ALLUSERS
o Merging row: Dummy_policy_9_0_Microsoft_VC90_CRT_x86.52105B6B_A3EF_3A90_882A_947B287C203A
Merging Table: Registry
o Merging row: reg_downlevel_manifest.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
Merging Table: SxsMsmGenComponents
o Merging row: downlevel_manifest.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
Connecting Merge Module Components to Feature: SharedCRT
o Connecting Component: uplevel.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
o Connecting Component: downlevel_manifest.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
Extracting MergeModule CAB to c:\docume~1\timgol~1\locals~1\temp\tmpm2g0jv.cab.
c:\docume~1\timgol~1\locals~1\temp\tmpm2g0jv.cab extracted successfully.
Module file list requested...
o Retrieved file [ul_policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882]...
o Retrieved file [ul_catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_88]...
o Retrieved file [policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_9]...
o Retrieved file [catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_]...
Module file list complete...
Closed Merge Module.
Committed changes to MSI Database.
Closed MSI Database.

 

[Martin v. Löwis]

I attach the merge.log output but I'll try to do some

research to understand what's going on here in any case.
In particular it's not clear to me whether the thing
has worked but has just tripped up over some non-essential
part, or whether these are real errors. (I really need
to set up a virtual machine which doesn't have VS2008).

AFAICT, it only complained about errors in merging _Validation.
I'm not sure whether I get the same errors (I would have to
check); those errors can safely be ignored. _Validation is
only used if you want to validate the MSI file, and I think it
complained because the data being merged are different than
the data that were already there. This, in turn, is because
the data already there are (or should be) the recommended values,
whereas the CRT msm deviates from Microsoft's recommended values
(IIRC).

I also see that it fails to add custom actions into
InstallExecuteSequence. I find that puzzling - apparently,
it tries to merge the twice. Are you sure you didn't run it
twice? It will certainly fail the second time.

Regards,
Martin

 

[Terry Reedy]

It doesn't appear to be quite so simple.

ODS uses a <table:table-cell> element as usual for the upper left
cell. Attributes set the range e.g. table:number-columns-spanned="3"
table:number-rows-spanned="2"

The gotcha is that it uses a *different* element for the cells covered
by the range. Example:
<table:covered-table-cell table:number-columns-repeated="2" />

This is looks like structural amendments are needed to a package like
(python-)?ooolib(-python)? that doesn't grok merged cells -- its
source doesn't contain the string "covered". Doesn't seem like it
could be done just by poking in attributes.

I guess it makes some sense that a cell that gets covered should be
changed to a covered-cell rather than merely being marked as 'covered'
or the covering left implicit by position. This would make it easier
for display software.

In any case, api-for-odfpy.odt has

5.17.12 table.CoveredTableCell
Requires the following attributes: No attribute is required.
Allows the following attributes: booleanvalue, contentvalidationname,
currency, datevalue, formula, numbercolumnsrepeated, protect,
stringvalue, stylename, timevalue, value, valuetype.
These elements contain table.CoveredTableCell: table.TableRow.
The following elements occur in table.CoveredTableCell: dr3d.Scene,
draw.A, draw.Caption, ...

so odfpy, at least, can create such elements.

Here's an example of 2 merged ranges: A1:C2 contains the text "foo"
and D12 contains "bar"

<table:table-row table:style-name="ro1">
- <table:table-cell table:style-name="ce1" office:value-type="string"
table:number-columns-spanned="3" table:number-rows-spanned="2">
<text>foo</text>
</table:table-cell>
<table:covered-table-cell table:number-columns-repeated="2" />
- <table:table-cell table:style-name="ce1" office:value-type="string"
table:number-columns-spanned="1" table:number-rows-spanned="2">
<text>bar</text>
</table:table-cell>
</table:table-row>
- <table:table-row table:style-name="ro1">
<table:covered-table-cell table:number-columns-repeated="4" />
</table:table-row>

Aside: If you are wondering where the cell addresses (D1 etc) are,
they're in the reader's current_row and current_col variables
Perhaps this was intended to save space, but what of table:number-
columns-repeated="4" ??

Those are the 4 cell covered in the second row -- 3 by 'foo' and 1 by
'bar'. I believe there could have been two separate entries, but this
is more compact, if less clear ;-)

Terry Jan Reedy

 

[Tim Golden]

AFAICT, it only complained about errors in merging _Validation.
I'm not sure whether I get the same errors (I would have to
check); those errors can safely be ignored.
Good.

I also see that it fails to add custom actions into
InstallExecuteSequence. I find that puzzling - apparently,
it tries to merge the twice. Are you sure you didn't run it
twice? It will certainly fail the second time.

I'll double check. There was a point at which I was execfile-ing
it from within msi.py *and* running it separately, but I thought
I'd fixed that.

BTW what are your feelings on a patch to msi.py to change the
names of the directories it's looking for to pick up the Tk
licenses? It's a bit of a grey area since the only "canonical"
reference I can find is the externals checkout from within
tools\buildbot: you might as well argue that it's *that*
which should be changed.

For my own part, I can run on a patched version quite easily
so there's no real urgency for me. I'm just about at the point
when I can put together a from-scratch instruction sheet for
erstwhile Python-Windows developers to build Python & pywin32
including installers from checkouts.

TJG

 

[Krishnakant]

I think you are confusing process and result. The result is a cell that
spans more than one column or row *when displayed*, thus hiding the
cells that would otherwise be displayed. This is, I am 99.9% sure,
controlled by an attribute of the visually expanded cell.

That might be the case imho, But I tried increasing the width of the
column using python-ooolib and i could not get the effect of a merged
cells.

I am now trying odfpy and hope it will do what I want.

In OOCalc, the process is to mark a block of cells and select Format /
Merge Cells. But still, the result will be a change in the upper left
attribute. Thus I suggested you make a .ods file with expanded cells
and then read the xml to see what cell element attribute is set thereby.
Any decent odf library will be able to set element attributes.
What did you mean by the upper left attribute, are you asuming that the merged cells are in the top row? In my case that's actually the case beacuse because I want my python script to generate an ods file with the cells in the top row merged from let's say a1 to d1.

Talking about the xml, which file should I look at to see the effect of
merging cells?

If the about-to-be hidden cells are not empty, OOCcalc gives you the
option of converting all cell contents to strings and joining them into
one string in the expanded cell. If you create .ods from scratch, you
should never need to do this. If you edit an existing .ods, something like
' '.join(str(cell.contents for cell in merge_group))
possibly in a function that also sets the attribute, should be easy
enough to write. And, of course, you will be able to do things other
than the one option OOCalc gives you.

This is exactly what I was trying to achieve with the python-ooolib
module but could not do it.
The library did have a cet_cell_property function but did not allow for
merging.

In other words, I do not think you *need* an existing cell-merge function.

But the library I use does not allow me to try the method you suggested.
Seems that I will have to look at the xml and write my own module.

See above.


Whoops. odfpy at
http://opendocumentfellowship.com/development/projects/odfpy

but I strongly suspect you can do what you want with python-ooolib.

No buddy, I tryed with ooolib but now given up unless some one points
out what I am missing.
happy hacking.
Krishnakant.

 

[Krishnakant]

In any case, api-for-odfpy.odt has

I am going through the documentation for odfpy but finding it pritty
complex right now.

5.17.12 table.CoveredTableCell
Requires the following attributes: No attribute is required.
Allows the following attributes: booleanvalue, contentvalidationname,
currency, datevalue, formula, numbercolumnsrepeated, protect,
stringvalue, stylename, timevalue, value, valuetype.
These elements contain table.CoveredTableCell: table.TableRow.
The following elements occur in table.CoveredTableCell: dr3d.Scene,
draw.A, draw.Caption, ...

So merged cells are refered to as covered cells is it?

so odfpy, at least, can create such elements.

Do you have any code sample done in odfpy which I can browse throu and
run it to see the results.

I guess I got the point, but still can't figure out how I could actually
implement this because I find the documentation of odfpy pritty complex
and does not have the kind of example which shows what you explained in
the above code.

And the problem is that I got a bit confused in the above code because
my merging happens only in the top row and spanns columns not rows.

I would be very happy if I could get the code wich creates a set of
merged cells in a single row with some data in it.

I managed to do the odt part in the odfpy because the examples were
there and well documented.

happy hacking.
Krishnakant.

 

[Martin v. Löwis]

BTW what are your feelings on a patch to msi.py to change the

names of the directories it's looking for to pick up the Tk
licenses? It's a bit of a grey area since the only "canonical"
reference I can find is the externals checkout from within
tools\buildbot: you might as well argue that it's *that*
which should be changed.

Never touch a running system If I can leave the tcl directories
where I have them, and just check them out a second time (or
perhaps just the license), that would be fine with me.

Regards,
Martin

 

[Tim Golden]

Never touch a running system If I can leave the tcl directories
where I have them, and just check them out a second time (or
perhaps just the license), that would be fine with me.

OK; I've added a step to my process which does a svn export
with the other name, specifying a depth of files-only.

TJG

 

[Krishnakant]

There's another one called ooolib-python; have you had a look at that?

Can you provide the url? Actually I think I saw this library but it
seems it is not well maintained and the author is no more active.

I think it is supporting old formats if I am talking about the same
library. So please send me the link so that I confirm my doubts.

But the problem is that library is missing a major feature from my
requirement context.
I need to merge cells in a spreadsheet and this library won't do that.

Do you know how I can work around this?

Here's a radical suggestion: Ask the author directly, or pop a note in
the suggestion box on the sourceforge tracker [hint: don't use your
mail client for this].

I did send him a message but did not get any reply for the email.

I will put this request on sourceforge.net as per your suggestion any
how.

Nah, just hijack a third thread

Thanks for that suggestion, I am not that multi threaded *smile*.
I have fixt my mail problem now so every things seems to be fine (untill
i hyjak another thread by accident LOL!).

happy hacking.
Krishnakant.

 

[John Machin]

Can you provide the url? Actually I think I saw this library but it
seems it is not well maintained and the author is no more active.

I think it is supporting old formats if I am talking about the same
library. So please send me the link so that I confirm my doubts.

http://ooolib.sourceforge.net/ calls it ooolib-python, but in
topsy-turvy land
(http://packages.debian.org/unstable/python/python-ooolib) it's called
python-ooolib but all you need in the end is import ooolib.

Three are one and one is three

 

[Tim Golden]

Feel free to create a patch for that.

http://bugs.python.org/issue5467

TJG

 

[Tim Golden]

I also see that it fails to add custom actions into
InstallExecuteSequence. I find that puzzling - apparently,
it tries to merge the twice. Are you sure you didn't run it
twice? It will certainly fail the second time.

Just to confirm: I'm certainly only running this once.
Still getting the same errors. Log attached for
completeness. However, the .msi installs (and Python
runs) without issue on a virgin VirtualXP.
And it passes the basic test suite ok.

This isn't surprising if it's just a case of "I've already
done that; I'm not doing it again" as you suggest. But
I'm not sure what's causing it. Not worth worrying about
too much, I expect.

TJG

 

[Tim Golden]

However, the .msi installs (and Python
runs) without issue on a virgin VirtualXP. And it passes the basic test
suite ok.

I lied. test_zipfile fails because the new(ish) zipdir.zip doesn't
get carried across to the install. Patched in:

http://bugs.python.org/issue5470


A couple of other tests fail (test_platform & test_pep352) when
running regrest, but I can't get them to fail otherwise.


TJG

 

[Krishnakant]

Hi John,

I tryed this same library to begin with.

python-ooolib is very good except that it misses a major feature of cell
merging (spanning ).

That is the point from which I started the thread.
I even thought the author of that library will respond back but did not
happen.

Seams it is a very old library and no development happens on it.

happy hacking.
Krishnakant.

 

[Tim Golden]

Do you mean 3.1a0? As far as I know, 2.7a0 requires the use
of the time machine, as it is expected to be 3 months out.

If you do get an installer built, even having a semi-official copy
around for those of us not on the MS compiler upgrade train to
do a little alpha (and/or beta) testing as well.

I've uploaded a couple of installers here:

http://timgolden.me.uk/python/downloads/snapshots/

Currently, there's the Python Subversion trunk (py2.7) and the
corresponding pywin32, built from the latest CVS. I believe
I've got everything in there, altho' the platform test was
failing irreproducibly when I last looked.

I'm building the py3k branch now, so if there are no problems
I'll upload that later tonight.

Please take them for a spin and let me know if they work.

TJG