|
On 2/27/2009 6:59:28 PM, Ian Binnie wrote:
>On 2/27/2009 1:05:24 PM, Pauli Lindgren
>>How can there be too much information?
>
>You can't, but if the data is not
>telling the user anything new it is not
>information (at least according to
>Information Theory), and just noise.
Are you suggesting that the useful information in the dialog "is not telling anything new"?
>If it was my macro it would not be
>there, because if I make a mistake I
>just reload the file.
You can reload the file only if you did save it before calling the macro. Most people do not save the file before making mistakes.
>
>> And I think it is really
>>useful to see which format the file is,
>>and to have option to manually change
>>the selection in case the automatic
>>detection does not work.
>
>You should not have the option if BOM is
>found.
It is useful to see the format even if there is BOM.
In addition, a different dialog box for that situation would mean more complex macro. But if the graying option can not be made to work in Vedit, maybe the different dialog box could be used.
>
>>And the option to preserve non-ANSI
>>characters is really important. Maybe it
>>should be ON by default?
>
>Again this is a matter of taste.
>It does NOT "preserve non-ANSI", but
>corrupts the file with html.
That is absolute bullshit.
The preserve option DOES preserve the information and allows reverse conversion without data loss. Without this option, all the non-ANSI characters are corrupted and destroyed irreversibly. So the truth is exact opposite to what you claim.
Obviously you have some problem with HTML.
Would you be happier if some non-standard coding was used to store the non-ANSI characters? That was my original plan, but then I realized that using existing HTML coding has many advantages.
>I mainly operate on files generated by programs.
>UTF-8 is becoming more common for .NET applications.
Why do you think that if the file is "generated by programs", the data can be freely destroyed?
If the files contain non-ANSI characters, obviously those characters do contain some necessary information.
>Html has nothing to do with these files,
>it would just make them harder to read.
Why should html have to do with those files?
It is just a method used to preserve the information.
When you convert the file back to UTF, the html is replaced with UTF characters.
If html codes are "hard" to read, destroyed characters are IMPOSSIBLE to read. And more importantly, impossible to convert back to Unicode.
>If users habitually have to respond to a
>prompt, it becomes automatic.
That has nothing to do with this macro.
The habit to automatically accept anything is caused by web browsers and other similar programs that constantly pop all kind of dialog boxes without user asking for it. Often those dialog boxes really do not contain any usable information.
However, when the user enters a command to perform a complex operation, he expects to get some response.
>
>Your comment also illustrates another
>difference in our modus operandi. I use
>the keyboard, and rarely touch the
>mouse. I prefer menus to dialog boxes
>for this reason.
Why? You can select the options from dialog box with keyboard just as easily and often with fewer key presses.
The menus have very little room, so it is not possible to include all the different options in the menus. For example, to have a different menu item for all possible combinations of Unicode conversion.
>
>If you are happy with the mouse, you can
>use Notepad, which supports Unicode,
>without all the problems of conversion.
You are the one who favors Notepad. So feel free to use it.
And you can use Notepad with keyboard as well.
>
>Incidentally I find the vedit limitation
>on menu length frustrating, particularly
>when the error message is "INVALID
>MENU". Vedit needs to move beyond the
>Windows 3 single level menus, and allow
>sub-menus for Tools etc.
Sub-menus in User and Tools menus have been in my wish list for ages, too. But I don't think this has anything to do with Windows 3. The other menus (File, Edit etc.) have had sub-menus all the time, even in DOS version.
>
>Windows only converts to ANSI because
>vedit asks it to.
>If vedit requested CF_UNICODETEXT this
>is what it would get.
This is not something specific to Vedit.
All applications that do not support Unicode have the same effect. And even if the application does support Unicode, pasting converts it to ANSI if Unicode mode has not been selected in the application.
For example on Notepad 2, if you just paste Unicode text in an empty window, it is converted to ANSI. You must first manually create a new file and save it as UTF-xx. Then you can paste the Unicode data correctly.
I wonder if it is even possible in Windows to paste as "raw", without needing to know in which format the data is.
>
>If you use Notepad you will get Unicode.
This is because Notepad internally uses Unicode even with 8-bit files. If it is ANSI file, it is converted to Unicode. If it is Unicode file, it stays in Unicode.
If you load a 100MB ASCII text file in Notepad, it uses at least 200MB of memory.
--
Pauli
|
|