This post referres to the technique used for filtering originally described in post.
We have been upgrading out software to the latest version quite regularly.
We did not have use for filtering for quite a while, so we did not test it.
Now we ran into a situation where filtering would be good to have, and we find it is broken.
We adapted the code given in the thread _(mentioned above)_so that it would support ‘=’ and ‘!=’.
The code looks like this:
private static bool FieldStillExistsAfterApplyingFilter(FieldMergingArgs arguments)
{
bool keepFieldInDocument = true;
**string parseResult = arguments.Field.Result;**
// Code adapted from the aspose website.
// Check if this field contains a filter defined by the equals sign in the field code.
// If it does have a filter then evaluate it and if the value is different to the filter, mark
// the row it appears in to be removed
int indexOfEquals = parseResult.LastIndexOf(EQUALS);
if (indexOfEquals > 1)
{
// Get the filter value between the "=" symbol and the end of the field result symbol
int firstPosAfterEquals = indexOfEquals + 1;
int endTagIndex = parseResult.IndexOf("»", firstPosAfterEquals);
string filterText = parseResult.Substring(firstPosAfterEquals, endTagIndex - firstPosAfterEquals).Trim();
// If the value is different mark it for removal
bool keepField = arguments.FieldValue.ToInvariantString().EqualsIgnoreCase(filterText);
bool invertKeepField = parseResult[indexOfEquals - 1] == SIGN_UNEQUALS;
if (invertKeepField)
{
keepField = !keepField;
}
if (keepField)
{
arguments.Text = "";
}
else
{
// indicate this row should be removed.
// the 'NodeChangingCallback' method on the document will actually remove the row.
arguments.Text = "%RowRemove%";
keepFieldInDocument = false;
}
}
return keepFieldInDocument;
}
We find that filtering no longer works because the result (highlighted in bold, above) no longer contains the parsed result, but still contains the text of the field, before parsing.
It looks like the IFieldMergingCallback has become an actual ‘before’ event.
And that we are missing an IFieldMergedCallback (‘after’) - interface/event.
If this method of filtering is no longer supported, please advice how we can get similar behaviour in the current version.
Thanks for your inquiry. To ensure a timely and accurate response, please attach the following resources here for testing:
Your input Word document.
Please attach the output Word file that shows the undesired behavior.
Please attach the expected output Word file that shows the desired behavior.
Please create a standalone console application (source code without compilation errors) that helps us to reproduce your problem on our end and attach it here for testing.
As soon as you get these pieces of information ready, we will start investigation into your issue and provide you more information. Thanks for your cooperation.
PS: To attach these resources, please zip and upload them.
Thanks for sharing the documents. You have shared the executable file that is using the old version of Aspose.Words. Please create a standalone console application (source code without compilation errors) that helps us to reproduce your problem on our end and attach it here for testing.
We will investigate the issue on our side and provide you more information. Thanks for your cooperation.
I suggest you apply that same logic, to the code/problem that was posted/solved in this thread: Filter within merge - #7 by Seph
And see if it still holds up.
The stated problem is:
based in some input in the dataset,
we want to conditionally show some rows in a Word-Table,
and others not.
(And I’ve supplied the simplest case to show the problem, a more complicated problem would contain stablestart/tableend clauses and more rows/coditions in both tables (data and word)).
The solution you’ve posted is:
a hardcoded way to always remove the same row from the Word-Table, no matter the input.
The reason why filtering no longer works, is because the .Arguments.Field.Result;
No longer contains the value that it did in previous/older versions of the Words.dll.
The code you’ve posted here, does nothing to fix that problem.
You are using the very old version of Aspose.Words. You are setting the field’s result based on “=” and “!=” signs in filed’s code. The code snippet shared in my previous post works in your case.
You can get the “=” or “!=” signs from the field using Field.GetFieldCode() method and perform the desired operation.
If you want to use the old code example, please call Document.UpdateFields method before calling MailMerge.Execute method. This will update the result of mail merge fields.
After trying your solution with little success,
and spending an hour or so in quiet desperation, trying things out…
I have found the cause and solution to the problem; And I feel a bit stupid now.
In hindsight it is obvious, but the error was that we defined the filter in the mergefield, instead of the ‘Display text’ of the mergefield. If we do that, then there is no way that the parser can match the fieldname of the mergefield, so there is no way we can match the filter with the fieldvalue (since it was never matched).
Moving the filter to the ‘display text’ fixed our error and things are now running smoothly.
It is nice to hear from you that your problem has been solved. Please feel free to ask if you have any question about Aspose.Words, we will be happy to help you.