Misc. UI bugs

[numEric]

Hi Igor,

Here are some bugs I noticed in v4.0 alpha (Unicode), build 1869:

Prerequisite:
1. Compare two files;
2. Minimize Compare It!'s window;
3. Modify one of the compared files from an external program.

Then you can observe these bugs:
• When you click the taskbar button to restore Compare It's window, you would expect it to show up unconditionally. Now, if the compared files have changed since the window was minimized, it doesn't: a message box shows up instead of the window, whereas the window should be restored first, then the application-modal message box should appear immediately after.
This behavior is annoying as the user has to click the taskbar button a second time after dismissing the message box in order to finally get the window restored. This is counter-intuitive.

• The text of this message box contains spelling/grammatical errors:

This file was change from outside:
<file name>
Do you want to reload files?

It should be:

This file has been changed from outside:
<file name>
Do you want to reload the files?

---

• The messages displayed in balloon tips are not formatted correctly.
Example:

Files are identical !

CR\LF mode is different!

You should consider removing one line feed on top and add one at the bottom so that the text is aligned vertically in the balloon tips.
Also, "CR/LF" would be more typographically correct than this "CR\LF". This isn't a Windows path nor an escape char!
And there should never be any space before exclamation (or question) marks.

• Often, the title bar and status bar don't redraw properly (at least when using the classic visual style; I've not tested with others).
For example, when the window loses focus, sometimes its icon and buttons (minimize, maximize, close) and their background aren't redrawn: they keep the "focussed window" colors.
This never occurs with any other application on my system, so Compare It! probably does something special that causes this odd behavior.

[grigsoft]

Thank you for your corrections, I will fix that. As for status bar, yes, there is weird problem with it and I still could not find a reason (to my shame ). But I'm working on it

[numEric]

I will fix that.

Thanks

As for status bar, yes, there is weird problem with it and I still could not find a reason (to my shame ). But I'm working on it

I've had a look at the window messages received/sent by the status bar control (using a hook), and I noticed something wrong: the WM_PAINT messages seem to be purely discarded; the control doesn't redraw when it receives them, and it doesn't return any value either. (It should normally return 0 to notify the system that the region has been repainted.)
So there seems to be something wrong or missing in your message handler for this window; you should take a look at it...
The title-bar refresh problem seems to have the same cause.

A little clarification:

[...] removing one line feed on top and add one at the bottom so that the text is aligned vertically in the balloon tips.

I meant "centered vertically", of course. Sorry for the inaccuracy.

[grigsoft]

I see CR\LF message as follows:

What is your Windows version?

[numEric]

I confirm that I see all balloon tips misformatted as follows:

What is your Windows version?

Windows Server 2003 SP1 (with Terminal Services enabled, in case it matters).
It's normally intended to behave identically to XP SP2, and it always did with all my applications.

My screen resolution is 120 dpi.
Could this be affecting the balloon tips' rendering?

[grigsoft]

OK, thank you, I will check what could lead to such results.

[numEric]

Update:

I've just noticed something strange with these balloon tips:
The misformatting occurs only if they're created while the main window is in restored state!
When it's maximized, the text is positioned properly!

Hope this helps...

[grigsoft]

Oh, I can see it too, thank you!

[grigsoft]

Yes, I will fix that too, of course. The problem is these texts are already used as keys in dictionaries, so changing it will require updating all dictionaries.

[numEric]

Thanks for the info.

The problem is these texts are already used as keys in dictionaries, so changing it will require updating all dictionaries.

Oh. I guess you mean language files. Using the names of the localizable string variables instead of the strings themselves would have been more judicious IMHO, as your solution implies that you have to be totally sure that all the strings are definitely perfect and error-free when you initially add them...

Well, at least, you can easily update these strings in all language files in one operation with a script performing search-and-replace, for example.
This is a matter of minutes, not a big problem.

[grigsoft]

Using keys instead of strings itself requires additional file for default language - and there is no problem to add one now: create file english.dic, select it Options>language, restart

Code: Select all

[WinDict 1.0]
[English]
[]
;02.02.2007 11:25.00

This file was change from outside
This file was changed from outside

Do you want to reload files?
Do you want to reload the files?

CR\LF mode is different!
CR/LF mode is different!