FRX extraction isn't repeatable if Office jumbles the site order

[BaronBodissey]

Hi chelh,

I noticed that extracting twice the same form doesn't generate the same frx file.

Thx

[BaronBodissey]

I must had that the FormControl "reader" seems not to work properly. In debugging I see that the read properties don't correspond to the form.

Best regards.

[chelh]

Could you please make a small file that displays this behavior? It's probably some odd combination of settings you're using on your form that causes this. My test files all generate the same .frx file each time.

[BaronBodissey]

Modèles Office personnalisés.zip

[chelh]

The issue seems to be that Office can change the order in which it stores controls in a form, even if you make no changes to that form. Please try this v2.2.0 release candidate.

Portable VBA Sync Tool 2.2.0.zip

[BaronBodissey]

Hi,

Still not working.

Maybe Office jumbles sites order but still I don't think that's the reason I had to open this ticket. As I explained in the initial post, the problem is that extracting twice in a row (without using Office between the two extractions) the generated frx is different. There must be something in VBASync that is not repeatable or time/random dependant to generate this issue.

Thx

[BaronBodissey]

In fact I noticed that there's an issue on frm files also. Maybe that's the starting point. There's some special french char in the frm: é. When I "open" (from scratch) VBASync and then I extract the dot file the é char is correctly extracted. But at the same time VBASync display some differences although it just did itself the extraction! So then (without closing/reopening VBASync) I extract again. And the second time the é char is lost/misinterpreted.

The initial state:

After applying, the frm is kinda correct: VERSION 5.00 Begin {C62A69F0-16DC-11CE-9E98-00AA00574A4F} Designations OleObjectBlob = "Designations.frx":0000 Caption = "Intégration"

but VBASync stil detects some differences although it just extracted!

So then I apply. And so there's no more differences but the frm file is now incorect: VERSION 5.00 Begin {C62A69F0-16DC-11CE-9E98-00AA00574A4F} Designations OleObjectBlob = "Designations.frx":0000 Caption = "Int�gration"

[chelh]

Hm, I thought the fix for that was included in the last set of binaries I posted here. Could you try replacing VBASync.exe and VBASync.WPF.dll in your VBASync folder with these, to see if they make a difference?

VBASync binaries.zip

[BaronBodissey]

The frm file problem is gone. But the frx one is still here. The problem is always at the same place in the frx, "last line" between character 523 and 539 (with winmerge). You can reproduce the problem using the doc2.dot document in the zip file: Modèles Office personnalisés.zip

[chelh]

Okay, I see what you mean now, and it may be due to the CLSID of the .frx root storage not being set to the proper value of c62a69f0-16dc-11ce-9e98-00aa00574a4f. Try this latest set of binaries and see if they help:

VBASync binaries with CLSID fix.zip

Sorry for mistakenly editing your bug title earlier!

[BaronBodissey]

Ok, It work better/fine now.

Nonetheless I noticed something else during some roudtripping tests. When you suppress the ThisDocument.cls and publish to the office document you kinda corrupt the office file. That is to says that when opening the document with office, you don't find anymore the project in the VBA Editor.

Is it intentionnal?

I found this feature kinda dangerous. I can envision the case where someone would want this case. But for most of the time I think the root project should remain intact. Maybe there should be an additional option for when the user intentionaly wants to crush the root project.

[chelh]

When I tested a similar scenario with Excel, Excel automatically repaired the file, so I assumed Word would behave the same. I guess not!

To prevent future users from stumbling upon this and corrupting their file, I've made it so that if you delete any document file in the repository and then publish, VBA Sync will act as if you had truncated all of the code in that file, leaving the metadata intact.

Note there is an option that “expert users” can apply to override this and delete document modules to their hearts' content, even though I can see no legitimate uses of this behavior…

[chelh]

By the way, have you had a chance to look at my responses to #28 and #29?