Menu
▾
▴
gnuplot-beta
|
From: Tatsuro M. <mat...@nu...> - 2005-01-26 12:48:47
|
Dear sir, From wgnuplot 4.0 later, we can treat Japanese shift-Jis code character. Unfortunately I found that pgnuplot.exe could not treat Japanese character. If "void PostString(HWND hwnd, char *pc)" in pgnuplot.c is modified by "void PostString(HWND hwnd, unsigned char *pc)" , it looks like work well. This may be because Shift-Jis code uses code number larger than 80(HEX). I have another opinion. The buffer size is rather small. (80) I think it should be larger (eg.512). "#define BUFFER_SIZE 512" Please be patient for my influent English. *************************************************************** Dr. Tatsuro MATSUOKA Department of Molecular Design and Engineering Graduate School of Engineering Nagoya University Furo-cho, Chikusa-ku, Nagoya, 464-8603, Japan E-mail mat...@nu... Tel. +81(Japan)-52-789-3274 FAX +81(Japan)-52-789-3273 **************************************************************** |
|
From: Tatsuro M. <mat...@nu...> - 2005-01-25 12:39:07
|
Dear sir, From wgnuplot 4.0, we can treat Japanese shift-Jis code character. Unfortunately I found that pgnuplot.exe could not treat Japanese character. If "void PostString(HWND hwnd, char *pc)" in pgnuplot.c is modified by "void PostString(HWND hwnd, unsigned char *pc)" , it looks like work well. This may be because Shift-Jis code uses code number larger than 80(HEX). I have another opinion. The buffer size is rather small. (80) I think it should be larger (eg.512). "#define BUFFER_SIZE 512" Please be patient for my influent English. *************************************************************** Dr. Tatsuro MATSUOKA Department of Molecular Design and Engineering Graduate School of Engineering Nagoya University Furo-cho, Chikusa-ku, Nagoya, 464-8603, Japan E-mail mat...@nu... Tel. +81(Japan)-52-789-3274 FAX +81(Japan)-52-789-3273 **************************************************************** |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-01-26 14:09:00
|
Tatsuro MATSUOKA wrote: > If "void PostString(HWND hwnd, char *pc)" > > in pgnuplot.c is modified by > > "void PostString(HWND hwnd, unsigned char *pc)" > > , it looks like work well. While that may appear to work well, I doubt it's the right way of going at it. The data passed to this function are actually type char *, not unsigned char *, and casting a pointer from one type to another is always a dangerous thing to do, even more so if it's supposed to happen this silently, by argument conversion. The correct method would rather appear to be a cast of the character being sent to 'unsigned char', as it's passed to the Windows API function PostMessage. > The buffer size is rather small. (80) I think it should be larger > (eg.512). > > "#define BUFFER_SIZE 512" What do you think would be gained by that? Please note that the size of this buffer may very well be a critical parameter that determines how well pgnuplot works in a somewhat busy Windows environment. |
|
From: Tatsuro M. <mat...@nu...> - 2005-01-27 02:05:09
|
Thnak you for your reply,
>While that may appear to work well, I doubt it's the right way of going
>at it. The data passed to this function are actually type char *, not
>unsigned char *, and casting a pointer from one type to another is
>always a dangerous thing to do, even more so if it's supposed to happen
>this silently, by argument conversion. The correct method would rather
>appear to be a cast of the character being sent to 'unsigned char', as
>it's passed to the Windows API function PostMessage.
Does your suggestion mean that change for the function PostString should be like below?
************************************************************
void PostString(HWND hwnd, char *pc)
{
while( *pc ){
PostMessage( hwnd, WM_CHAR,(unsigned int) ((unsigned char) *pc), 1L );
/* CRS: should add a check of return code on PostMessage. If 0, the
message que was full and the message wasn't posted. */
pc++;
}
}
**************************************************************
According to the windows SDK page, the type of third parameter of PostMessage is UINT
so that casting (unsigned int) is added.
In the Gnuplot Thead in Japan, it was pointed out that
this modification might be effective for people using the iso-8859-* encoding .
Unfortunately we cannot try this, because we do not have a such computer environment.
>
>> The buffer size is rather small. (80) I think it should be larger
>> (eg.512).
>>
>> "#define BUFFER_SIZE 512"
>
>What do you think would be gained by that? Please note that the size of
>this buffer may very well be a critical parameter that determines how
>well pgnuplot works in a somewhat busy Windows environment.
Sometimes I used the script which includes more than 80 character per line.
If this BUFFER_SIZE is critical, I will notice this from now
when I use pgnuplot. Thanks!!
Sincerely yours
Tatsuro MATSUOKA.
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-01-27 08:21:10
|
Tatsuro MATSUOKA wrote:
> Does your suggestion mean that change for the function PostString should be like below?
> ************************************************************
> void PostString(HWND hwnd, char *pc)
> {
> while( *pc ){
> PostMessage( hwnd, WM_CHAR,(unsigned int) ((unsigned char) *pc), 1L );
> /* CRS: should add a check of return code on PostMessage. If 0, the
> message que was full and the message wasn't posted. */
> pc++;
> }
> }
> **************************************************************
No. The secondary cast to (unsigned int) is unnecessary, and
potentially dangerous (because the real parameter type is WPARAM, not
unsigned int). I've checked into a CVS a version that casts to unsigned
char.
> According to the windows SDK page, the type of third parameter of PostMessage is UINT
> so that casting (unsigned int) is added.
If the type were unsigned int, such a cast would be superfluous --- C
silently applies it already.
>>>The buffer size is rather small. (80) I think it should be larger
>>>(eg.512).
>>>
>>>"#define BUFFER_SIZE 512"
>>
>>What do you think would be gained by that? Please note that the size of
>>this buffer may very well be a critical parameter that determines how
>>well pgnuplot works in a somewhat busy Windows environment.
>
> Sometimes I used the script which includes more than 80 character per line.
So what? Did the existing buffer size of 80 cause you any trouble with
those lines?
|
|
From: Tatsuro M. <mat...@nu...> - 2005-01-27 09:48:19
|
>No. The secondary cast to (unsigned int) is unnecessary, and >potentially dangerous (because the real parameter type is WPARAM, not >unsigned int). I've checked into a CVS a version that casts to unsigned >char. >If the type were unsigned int, such a cast would be superfluous --- C >silently applies it already. Thank you for your comments. PostMessage( hwnd, WM_CHAR, (unsigned char) *pc, 1L ); Is it OK? It look like works well here. >> Sometimes I used the script which includes more than 80 character per line. >So what? Did the existing buffer size of 80 cause you any trouble with This is my complete misleading. I'm sorry. Sincerely yours, Tatsuro MATSUOKA |
