PrestoSoft Community

I was comparing a couple of binary files (.bin) of about 450 kbytes each.
I switched some times the "Fast byte-by-byte comparison" on and off.
Then I finished having a visualization in which two vertical stripes, one per pane, were not drawn so they appeared almost "transparent". More correctly, not being redrawn, the stripes showed what was there before.
For example, in the right one I saw the relics of the dialog that had warned me that there were too many differences.

I closed EDP. Then I reopened it with the same files: same view.
I switched the "Fast byte-by-byte comparison" on and off: same view.

Now I try to describe how each pane looked.
On the left side of the pane there was the offset expressed with probably 16 hex digits, surely much more than the usual 8, followed by a colon (':').
Then a little blank space.
Then the vertical "transparent" stripe.
One more little blank space.
The hex dump of the data with the differences higlighted.
I don't remember any ASCII dump.

My first thought was: I left my hex dump plugin enabled: no.
I enabled it and, indeed, the view is very different.
To be sure I disabled all the plugins: same view.

Some other tests and Windows freezed. (I'm not sure it was EDP to blame.)

After a reboot I was absolutely unable to replicate that effect.

Where does that view comes from?
Did I have allucinations?

No idea. Could it be the video driver? Windows in an unstable state?

Sorry, what effect do you mean?

The windows freeze? Don't worry too much. As I wrote, I'm not at all sure EDP is the culprit.
The missing redraw of two stripes of the screen? A small glitch of secondary importance.
The different layout? How can Windows (video drivers or anything else) change so radically the view?

What puzzles me is: who generated that view?
It was not at all a garbled view. It makes sense!

The most probable origin is a plugin, but I dont know which one.
And then I disabled all the plugins.
And the plugin's output can not generate the "missing redraw" problem.
So what?

Is it an alternative/experimental view of the fast binary compare of EDP I missed? Quite possibly.
How can it be selected? I don't remember having read about it anywhere and I'm not able to trigger it again.
I'll read the instructions more attentively...

I meant the garbled view that I thought you experienced. Well, we'll have to wait until a reproducible case is possible.

Breaking news.
To begin with, my memory proved unreliable (but that's not a news...)
Lukily (?) I got them again.

Normally I see something like this:


but sometimes I get this:


Do you see in the second screenshot the two vertical stripes I was talking about?
And also: why two different views?
N.B. In the second screenshot the two files are identical, but it doesn't seem to matter.

Hmm, how did you get these results? What are your options as far as getting messages about identical/different binary files, and fast binary comparison for each of these screenshots?

the two files are identical, but it doesn't seem to matter.

Wrong!
It's exactly when you compare two identical binary files that it happens (after clicking "show files anyway", of course).
It's the size of the file that seems unimportant.
Sorry.

There is a small difference between the 32 bits version and the 64 bits.
In the 32 bits version the offset in hex is 8 digits long, in the 64 bits it's 16 bits long.
How surprising!

Odd, I'm not seeing this redrawing issue. Also, what to you get when files are different?

In a few words: if the files differ (either of the same length or different lengths) then I get exactly what I expect, i.e. something similar to the "standard" binary compare.

I'm still puzzled: what's the need for a different view in that case? (When the files are identicals, I mean.)

Well, there's a bug currently that, if you have no Identical or Different message, in fast mode EDP will not show hex offsets as it's supposed to. This will be fixed in the next build.

I'm still puzzled: what's the need for a different view in that case? (When the files are identica, I mean.)

I'm not sure what view you are referring to. Are you talking about offsets in fast mode? If so, this is by design.

will not show hex offsets as it's supposed to

Aha!
So the problem is not when the two files are identical but... in all the other cases!
I misunderstood that.

My 2 cents: do you think it's good to have the hex offsets on the left, in special mode in the 64 bits mode?
First of all, the offset of the byte selected is visble on the left of the panel status bar. (Good!)
Second: I still use a 4:5 monitor.
Third: if the file is short (I just mean: much shorter than 4 GB or I don't know how many PB...), why waste so much monitor real estate with a bunch of 0? N.B. You know from the beginning how big is the file.
Could you at least make it selectable?

Could you at least make it selectable?

Yes, we'll add an option for this in the next build.