Hi Dave.
Yeah, we know the user who had the same problem in the past. However, In Japan,
it needed to be written by encoding of a client, and We did not want to set an initial
value to UTF-8. Therefore, It is need recognized by the warning message.
How is an attached patch proposal?
Regards,
Hiroshi Saito
----- Original Message -----
From: "Dave Page" <dpage@postgresql.org>
> On 08/01/2008, Andrew <archa@pacific.net.au> wrote:
>> Excellent,
>>
>> Thanks Hiroshi Saito, that worked a treat, I really appreciate you
>> posting those images. Apologies for taking up your time for something I
>> probably could have figured out by RTFM.
>
> Yes, thanks Hiroshi (our resident encoding guru :-) ).
>
>> However, IMHO I still think it is a defect, in that it shouldn't really
>> be saving a 0 byte file silently, when you think it has successfully
>> saved your changes, and then when you go back to the file you find the
>> data you have worked on is lost. If it is in a mode not to support the
>> characters, then it should alert you that it cannot save those
>> characters. However, I will leave that for the development team to
>> decide if it is defective behaviour or behaviour by design.
>
> Absolutely agree. Hiroshi; we do something similar in frmExport:
>
> if (rbUnicode->GetValue())
> file.Write(line, wxConvUTF8);
> else
> {
> buf = line.mb_str(wxConvLibc);
> if (!buf)
> skipped++;
> else
> file.Write(line, wxConvLibc);
> }
>
> (we then warn the user if skipped > 0). Would something similar
> suffice do you think?
>
> /D