
Announcement
Collapse
No announcement yet.
13298 Mystery mismatch
Collapse
X
-
Originally posted by ChrisAha. I don't think keeping that info from users was a smart idea.Leave a comment:
-
The documentation doesn't say one way or the other. At best, it says they're changes that "should" be considered unimportant, not "must".
What, that we made a design decision? We make thousands of decisions about how features should work; we aren't going to document all of the things we decided not to do.
That's a faithful execution of the Replacement the user asked for. That's exactly what I want as per "Replacements identify repetitive changes that should be considered unimportant."
Craig, I cannot imagine when I would find it useful for BC to apply my replacements "optionally". Replacements are no use to me if I cannot trust BC to apply them consistently.
I'm sorry the current behavior doesn't work for you, but adding the alternate approach is a fairly complex feature and I don't expect us to get to it soon. BC has find and replace support and updates the comparison as it does so, so you can do a global replacement yourself to eliminate them as differences.Leave a comment:
-
Not according to the documentation, Craig.
Craig, I cannot imagine when I would find it useful for BC to apply my replacements "optionally". Replacements are no use to me if I cannot trust BC to apply them consistently.
Originally posted by Aaronimproving replacements is on our wishlistLeave a comment:
-
If you have these two files:
Code:apples | apples apples | bananas bananas | bananas
With the current behavior, you can add "apples => bananas" as a replacement and it will only affect the middle line.
If, instead, we apply the replacements first, internally the files would be represented as:
Code:bananas | apples bananas | bananas bananas | bananas
ababababab
And you want to replace "aba" with "c". In that case you'll end up with something like:
cbcbab
The second and fourth "aba" substrings won't be replaced correctly because they've already matched a replacement. The current behavior allows the "c" replacement can occur for any of the "aba" substrings.
We may support doing pre-replacements at some point, but the current behavior is intentional. On the other hand, the initial alignment should be improved to better group characters, and if it did you wouldn't have had any problems here.Leave a comment:
-
The alignment does occur before the replacement. Expanding and improving replacements is on our wishlist, but the replacement does not currently try to push the alignment.Leave a comment:
-
Re http://img844.imageshack.us/img844/4...gnment0nor.png
Aaron wrote*:
Thanks, Chris. I added these to our test cases. In this specific
example, the issue is that the alignment aligns the 0 in an unexpected
location. The alignment step happens before the text replacement step,
so by being misalighed, the text replacement does not match the text
sections.
Improving our intra-line alignment is on our wishlist. The only
workaround available in this case would be to mark "\30s\Loud" as an
unimportant grammar instead of using text replacements.
But re "The alignment step happens before the text replacement step, so by being misalighed", are you sure, Aaron? Replacements represent file changes, so surely they must be applied first, if they are to work properly??Last edited by chrisjj; 23-May-2011, 06:53 AM.Leave a comment:
-
Meanwhile, is there a workaround? I.e. a way to get BC to show all matches?
PS It would have been useful to have received this information fifteen messages ago when I asked the question.Leave a comment:
-
Hello Chris,
That specific coloring is because BC3 does not color single character matches (checker-boarding). If it did match and color it, the "s\30s\Loud" would have a single black character in it, which would make it harder to read. It is a design and presentation decision and intentional behavior.Leave a comment:
-
Now, returning to my first question (i.e. regardless of the issues of a) failure of Unimportant marking and b) unexpected alignment), why does the left side shows the s as mismatched (red) as opposed to matched (black), here:
Thanks.Leave a comment:
-
At http://www.scootersoftware.com/vbull...40&postcount=5 Aaron wrote:
This is the screenshot I was referring to, but now that I re-review it I see the trouble it is having:
http://img846.imageshack.us/img846/1543/regionm.png
The 0's alignment is probably the cause. If you send in sample files I can add them to our test cases.
and emailed the BCsupport.zip and left and right files.Last edited by chrisjj; 20-May-2011, 11:00 AM.Leave a comment:
-
OK... will do. Thanks.Last edited by chrisjj; 18-May-2011, 04:53 PM.Leave a comment:
-
Hello,
Thanks for the easy to copy and paste text. Using the Open Clipboard to saving them to files I still see different text alignment results than your first screenshot. With this example, the first \ is not aligned at the front, so there is no "\" to match on. Your initial screenshot, however, shows different alignment details where the first \ is aligned to the front. I would need the requested files in order to try and reproduce that behavior.Leave a comment:
-
I'm surprised Aaron. I get the fail with this simple test:
1 Click Start New Session, Text Compare
2 Enter in left \Curtain\2480002928225-1-5 and right R:\Curtain\30s\Loud\2480002928225-1-5
3 In Session Settings, enter the Replacement right \30s\Loud\ to left \
4 Inspect right \30s\Loud\
Expected: Unimportant blue
Observed: Important red - see http://img688.imageshack.us/img688/2293/regionv.pngLeave a comment:
-
Hi Chrisjj,
Thanks for the screenshot. I tried recreating your files manually by typing out that line, but I'm not seeing the same behavior (alignment details) as you are. Please email us:
1) A pair of sample files
2) Your current support.zip (Help menu -> Support; Export)
3) A link back to this forum post for reference.
Thanks.Leave a comment:
Leave a comment: