-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
While using @before-cell and @after-cell random cells and even rows can be deleted #38
Comments
@nicky1038 as I said you, it should be very cool if you create a JUnit like It should be very cool if you could create a test with your case like https://github.com/opensagres/xdocreport/blob/master/integrationtests/fr.opensagres.xdocreport.core.test/src/test/java/fr/opensagres/xdocreport/document/docx/preprocessor/DocxPreprocessorWith2InstrText.java It will win me a lot of time if you do that. Thanks! But I'm very busy, I don't know when I will have time to study your problem. |
@angelozerr OK, here it is (again in scala but this code almost doesn't differ from java) |
@angelozerr DocxPreprocessor class is really helpful to control output - it's easy just to preprocess document.xml of template and get updated xml, then, if it's OK, try to finally process it. I've found that if there are multiple subsequent cells in one row with some condition stated like this With this syntax But even such measure didn't help me and my resulting table is incorrect - the whole row is being deleted (in xml).
Excuse me please for my persistence and wasting your time but it's really important to find out what's wrong. |
@nicky1038 I have fixed #42, perhaps it's the same problem than you? |
@angelozerr Sorry, I think I finally confused you. Initially I thought that my problem is in preprocessor but it turned out that it works fine, as I have said in my last reply - #if($..) and #end fields were token out of <w:tc>...</w:tc> block as it should be. Whatever, after preprocessing something goes wrong and the whole row, that contains cells surrounded with #if($..) and #end code, is being deleted. |
To be honnest with you, I'm a little lost. I have not a lot of time to understand problem of each users (I have already token time with your case with splitted mergefield and it seems that there are not problem). It seems that you are using @before-cell which could provides some problem (eg : if you use it with #if, ooxml table column will not updated, perhaps it's your problem). If you wish I help you, please create a very simple case which doesn't work and share it with your github project. Thanks |
@angelozerr I'm really sorry that I have to steal your time with such problem which I can't even properly explain. But it's really critical for me. I've tried to recreate a situation with a whole row deletion but I only came across a single cell deletion. This case is interesting too, and maybe it is an effect of the same problem. https://github.com/nicky1038/Java-and-Scala-Tests/tree/master/xDocReport Let me explain what did I do, what happened and what does my repo contain. My template contains a table in which rows are records (instances of a class) and columns are class' fields ("variables") that can be optionally printed, as user decides.
As soon as I created my template I processed it and saw that the whole column with 9th variable (I don't know why 9th) was deleted. Then I made a backup of this template, re-entered all mergefields in defective column and launched my application again... The column with 9th variable's data appeared, but not completely - its header cell was deleted just as before.
What else?
Now you do know the problem and do have its sample. Please do something :( |
@nicky1038 I'm very busy today and it seems that you are using @before-cell, @after-cell which is not official because the support is basic and I think there are several bugs. It was a long time that I have developed that and it requires a lot of time for me to improve @before-cell, @after-cell . I will try to study the problem when I will find time. Any contribution are welcome! |
@angelozerr Hi, it's me again :D Recently I finished the rest part of my work and decided to look at my template processing code again. And... it is awful. It puts an instance of my bean and a boolean value to IContext with the same names and sends information about EVERY field to FieldsMetadata, even if it isn't necessary. |
---Sorry, accidendally I have closed issue #37 so this is it once again---
What steps will reproduce the problem?
In my case the larger is the document the more is a probability that some of the mergefields will be divided into different runs in document.xml as it is shown below.
What is the expected output? What do you see instead?
I expect that every mergefield will be filled but in practice the other situation happens - those mergefields that were divided into various runs (during creating template) will not be filled. If you try to launch your java code once again you will discover that the same mergefields were not filled because mergefields are stored in the template itself.
What version of the product are you using? On what operating system?
Please provide any additional information below.
The most interesting thing is that if you try to delete and re-enter bad mergefields with the same information there will be a probability they will not be spoiled again.
I understand it is not a problem of yours and your library. Moreover it's really easy to use and it's a pleasure to work with it, but this trouble is a real headache for me and doesn't allow to work normally. Please add some features so that this problem will not be a problem anymore.
Here you can find a template, scala/java code and resulting output. I need to implement my project in scala so this template was processed using scala code too. But for your convenience I've added equivalent java code.
https://www.dropbox.com/sh/f2iyaiyvqg7wy1m/AAAf7nfNnTuULFstakS-59hUa?dl=0
This issue was also created there: https://code.google.com/p/xdocreport/issues/detail?id=483
UPD:
I've been tried to find a bit more information what exactly is wrong and I've found that as it's shown at screenshots every run has its own RSID parameter. It serves for conveniet merging of documents and can be turned off. It could be helpful, but..
Then I've tried to edit document.xml myself to make broken mergefields look like ordinary ones. It didn't affect on template's view but my program began throwing strange parse exceptions even if I've only removed really unnecessary runs.
Thank you very much!
Nick.
The text was updated successfully, but these errors were encountered: