Diffzilla crashes when run standalone and switching to Code Diff

[evanratt]

I'm trying to run Diffzilla standalone (not launched from SE), using "vsdiff file1 file2". If I click on the button at the bottom to switch to Code Diff mode, the window closes, I get a very brief progress bar in the middle of the screen, like it's comparing the two files, and then it just closes.

Edit: It is actually odd that I have to click a button to switch to Code Diff mode, as the Code Diff check box is checked in the diff options tab.

[Dan]

Evanratt:

Regarding the dialog going away, it actually is not crashing, but it certainly appears to be. The good news about this is that I can send you a macro fix (I will private message it to you).  Other posters, please contact support and ask for a modified diffedit.e if no hotfixes are available (this will be in the first hotfix).

Code diff has to be turned on from the dialog, or a command line option in SlickEdit.  Unfortunately vsdiff does not support this option right now, so that will be in the first patch.

[jb]

Edit: It is actually odd that I have to click a button to switch to Code Diff mode, as the Code Diff check box is checked in the diff options tab.

I encountered a similar problem with Code Diff:
If I click the 'Run Diff on Selected Backups' button in the 'Backup History' then the checked 'Code Diff' option is ignored too, but the 'Code Diff' button is not even displayed in the Diff window. So it is not possible to switch to Code Diff mode manually.

[Ryan]

I think Code Diff was purposely disabled for Backup History elements...I'm not sure if this is something planned for 14.0.1 or if it's "just the way it is"  .

- Ryan

[Dan]

This was disabled on purpose.  I felt that backup history was a place where you would want to see exactly what had happened.  It is possible to make it available in 14.0.1 if this is what people would like.

[jb]

This was disabled on purpose.  I felt that backup history was a place where you would want to see exactly what had happened.  It is possible to make it available in 14.0.1 if this is what people would like.

I think it should be clearly up to the user to decide what he wants to see. In my opinion such kinds of restrictions are bad because:
a) It hinders the user.
b) The developer has additional work to implement the restriction.
c) The treatment of unnecessary "special cases" blows up the code with all its negative consequences regarding maintainability, resources, ....

[jb]

Code diff has to be turned on from the dialog, or a command line option in SlickEdit.  Unfortunately vsdiff does not support this option right now, so that will be in the first patch.

For me it's even worse: vsdiff.exe /? or vsdiff.exe -h does not show its options anymore.
It seems to be a reoccurring problem. See also http://community.slickedit.com/index.php?topic=2580.msg10648#msg10648

[hs2]

I'd agree with jb that both ways of diffing are useful also when dealing with the backup history.
Just my 2ct, HS2

[jb]

This was disabled on purpose.  I felt that backup history was a place where you would want to see exactly what had happened.  It is possible to make it available in 14.0.1 if this is what people would like.

I think it should be clearly up to the user to decide what he wants to see. In my opinion such kinds of restrictions are bad because:
a) It hinders the user.
b) The developer has additional work to implement the restriction.
c) The treatment of unnecessary "special cases" blows up the code with all its negative consequences regarding maintainability, resources, ....

Now I discovered another annoying restriction:
When I compare two buffers (for two different writable files) and try to change the buffer displayed on the RIGHT side then SlickEdit 14.0.0.7 says "Command not allowed in Read Only mode". The same happens when I compare two writable files ("Use file on disk" checked) and invoke DIFFzilla from SlickEdit.
However when I compare two writable files and invoke DIFFzilla from the command line (vsdiff.exe) then both files can be modified (as desired).
SlickEdit 12.0.3.0 had no restriction in all three cases.

I really dislike such "IntelliNonsense" that seems to be introduced everywhere (following Microsoft).

[Clark]

This was disabled on purpose.  I felt that backup history was a place where you would want to see exactly what had happened.  It is possible to make it available in 14.0.1 if this is what people would like.

I think it should be clearly up to the user to decide what he wants to see. In my opinion such kinds of restrictions are bad because:
a) It hinders the user.
b) The developer has additional work to implement the restriction.
c) The treatment of unnecessary "special cases" blows up the code with all its negative consequences regarding maintainability, resources, ....

Now I discovered another annoying restriction:
When I compare two buffers (for two different writable files) and try to change the buffer displayed on the RIGHT side then SlickEdit 14.0.0.7 says "Command not allowed in Read Only mode". The same happens when I compare two writable files ("Use file on disk" checked) and invoke DIFFzilla from SlickEdit.
However when I compare two writable files and invoke DIFFzilla from the command line (vsdiff.exe) then both files can be modified (as desired).
SlickEdit 12.0.3.0 had no restriction in all three cases.

I really dislike such "IntelliNonsense" that seems to be introduced everywhere (following Microsoft).

We will be doing some UI enhancements here which will make this much easier for users to get SlickEdit working the way they want. There is also a bug where switching into LineDiff mode does not make the right side editable. This will be fixed as well.  It is likely that Code Diff will always make the right side read-only.  If you really don't like having the right side read-only, turn off the Code Diff option on the Options tab of the diff dialog. Also, make sure the "IF()END" button on the Files Tab of the diff dialog display an X (means "not code diff").
 

[jb]

It is likely that Code Diff will always make the right side read-only.  If you really don't like having the right side read-only, turn off the Code Diff option on the Options tab of the diff dialog. Also, make sure the "IF()END" button on the Files Tab of the diff dialog display an X (means "not code diff").

First I would like to say that DIFFzilla is my favorite FILE compare and merge tool since years. I use it directly from SlickEdit and indirectly from Total Commander and TortoiseSVN. However for DIRECTORY comparison I prefer Total Commander's "Synchronize Dirs..." function for normal cases and Araxis Merge for demanding cases.

Now with the new Code Diff feature you made DIFFzilla absolutely outstanding regarding source file comparison. So I will certainly not disable the Code Diff option if it will be possible to switch to Line Diff mode at any time for bidirectional merging. But this seems to be a workaround for me.
(Currently switching from Code Diff to Line Diff does not work at all on my machine with SlickEdit 14.0.0.7! Only vice versa.)

Why is it likely that Code Diff will always make the right side read-only?
Why not allowing to toggle the "Read only" check boxes on both sides whenever possible?
I understand for example that files in the Backup History should always be read only (or even MUST be read only for technical reasons).

PS: One great feature I miss in DIFFzilla is the ability to hide long stretches of lines that are identical on both sides. Araxis Merge offers this feature. With this feature enabled in many cases you can see all differences on one or two screen pages.

[Clark]

jb, keep the comments coming. Glad you like Code Diff. I think it totally rocks.

I'll have to checkout the Total Commander's Synchronize Dirs feature. 

You say Code Diff to Line Diff does not work on all machines.  What happens when it does not work?

So you wonder why it is likely that Code Diff will always make the right side read-only.  Well, this is because the file on the right has been beautified like the file on the left. It no longer looks anything like the original file. Trying to unbeautify and save the right side is pretty difficult or maybe even impossible to do. We haven't yet racked our brains on this one yet but we knows it's hard. One possible solution is to allow transfers for lines which have not been beautified. This is the most common case. Some how it would need to figure out what line in the actual file were modified. I think this is doable.

Hiding long stretches of lines that match is an interesting idea. This could definitely be added since the editor already supports hiding and unhiding lines. I guess this is a different way to handle next diff.  Another possibility would be to show change bars and allow you to click on them.

[buggyfunbunny]

So you wonder why it is likely that Code Diff will always make the right side read-only.  Well, this is because the file on the right has been beautified like the file on the left. It no longer looks anything like the original file.

When I was on windoze, I got used to ExamDiff Pro.  It had a plugin support, and I used Tiobe pretty printer for java files.  EDP would allow changes both ways, but warned if either had been beautified.  If you said Do It, it would.  Caveat Emptor, and all that.

[jb]

jb, keep the comments coming. Glad you like Code Diff. I think it totally rocks.

YES indeed!

I'll have to checkout the Total Commander's Synchronize Dirs feature.

Just in case you don't know Total Commander I would like to mention that Total Commander is a Shareware file manager for Windows with a long history and a huge community that produced many plugins for it. Some important properties of Total Commander 7.04a are:
- very stable
- fast
- incredible feature set
- small footprint (download size is 2.10 MB)
- highly configurable and extensible (plugin interface)
- decent price for lifetime license
BUT unfortunately the default configuration of Total Commander is rather unattractive. To make Total Commander really rock it takes a while to discover the best features and to customize it.

You say Code Diff to Line Diff does not work on all machines.  What happens when it does not work?

Actually I said "switching from Code Diff to Line Diff does not work at all on my machine with SlickEdit 14.0.0.7".
But anyway in the meantime I realized that problem is caused by spaces in the path of the file on the right side.
EXAMPLE:
C:\vsdiff_left   test\main1.cpp
C:\vsdiff_right   test\main2.cpp
If you switch from Code Diff to Line Diff mode then SlickEdit 14.0.0.7 says:
File 'C:\vsdiff_right' does not exist.
Obviously some SlickEdit developer forgot to "doublequote" the filespecs.

So you wonder why it is likely that Code Diff will always make the right side read-only.  Well, this is because the file on the right has been beautified like the file on the left. It no longer looks anything like the original file. Trying to unbeautify and save the right side is pretty difficult or maybe even impossible to do. We haven't yet racked our brains on this one yet but we knows it's hard. One possible solution is to allow transfers for lines which have not been beautified. This is the most common case. Some how it would need to figure out what line in the actual file were modified. I think this is doable.

Now I can imagine the difficulties and the chances that you will try to overcome them nevertheless.

Hiding long stretches of lines that match is an interesting idea. This could definitely be added since the editor already supports hiding and unhiding lines. I guess this is a different way to handle next diff.  Another possibility would be to show change bars and allow you to click on them.

For example WinMerge has the change bars but I don't find them very useful. The advantage of hiding the unchanged lines is that in many cases you can see all differences with minimal effort, that is, you just need to tip the mouse wheel a little bit.

[Clark]

Ah yes, the spaces problem. We'll have a hot fix for this and other bugs soon. I'll add your feature request for hiding consecutive lines as well as some synchronize dirs features.