[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference dssdev::decforms

Title:	DECforms
Notice:	This is not an official software support channel. Kit info: 4.L
Moderator:	DSSDEV::FORMS

Created:	Thu Mar 23 1989
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4004
Total number of notes:	16520

3980.0. "ASCII character data handling" by EWBV05::OHSHIMA (Yuichi Ohshima, System Support Tokyo) Fri Feb 07 1997 03:03

	We have a question about data handling of DECforms/Japanese V2.1b on 
	OpenVMS Alpha V6.2-1H3. 

	In case of handling data like binary '00'+ ASCII character '41';
	'0041', the character 'A' was displayed on VAX platform with 
	DECforms/Japanese V1.4. But on Alpha with DECforms/Japanese V2.1b, 
	none character is displayed. Is this owing to DECforms V2.1b 
	specification ? 

	Our customer handle like illegal data from IBM machine, they want to 
	display character for this case. We also try to do this on OpenVMS 
	VAX with DECforms V2.1b, the result is same on Alpha. 
	Is there any method to display character for such data ?

	Thank you,
	regards,
	Yuichi Ohshima,
	System Support Tokyo.

T.R	Title	User	Personal Name	Date	Lines
3980.1	Forwarded note.	DSSDEV::DINTINO		`Mon Feb 10 1997 08:58`	6
	I sent your note to Benzi Eilon in Israel who led the effort to build a Japanese version of DECforms. We, here in U.S., do not have access to his build/test environments. Domenic
3980.2	I need an example	TAVENG::BENZI	Benzi Eilon	`Mon Feb 10 1997 09:49`	9
	Ohshima-san, I was not involved at all in DECforms during V1.4 time. So, in order to understand the situation, I need an example how this '0041' got entered into a form so it should be displayed. Please provide a small example which reproduces the problem. Benzi
3980.3	Problem was reproduced	TAVENG::BENZI	Benzi Eilon	`Wed Feb 26 1997 10:12`	22
	We have reproduced the problem using a test program delivered by Ohshima-san. The problem was traced to a code change in module FORMS_MGR_CCT_FIELD.B32 routine DISPLAY_IMAGE. This change explicitly looks for the first NULL character in the string to be displayed and sets the string end at this point, treating the data as a null terminated string. In the example given, the field to be displayed had 5 leading NULL characters followed by 5 ASCII characters. The calculated string length was ten in V1.4 but is zero in newer versions. This change was inserted in V2.0, both for the Latin and Japanese cases. I believe that it is an improvement over the old code and I don't think that the code should be modified back. As explained above, it has nothing to do with special handling of ASCII characters in a Japanese environment. So, I think that the user, who relied on an undocumented support, should modify his program to remove leading NULL characters before sending the text data (coming from an IBM machine) to the form. Even better, the NULLs should be removed as near as possible to the place where they are generated (i.e., on the IBM machine).