Hello all, When Microsoft went from DOS to Windows, they changed the default character set from ASCII to ANSI. These are identical for characters 0 through 127, but different for characters 128 to 255, which include the accented characters. This gave us major fits here where we are bilingual (French and English).
In any event, the so-called “hard space” is now CHAR(160). CHAR (255) is now “ÿ”, the infamous “umlaut-y” that those of you who have systems converted from DOS will have often seen. It’s often handy to type a hard space while working with R:Base. Just hold an [Alt]-key while typing 0160 on the numeric keypad. The font called “Terminal” uses the old ASCII character set. Here is how the French phrase “ la fête est à l'été ” would look in Terminal font: la fête est à l'été. The same phrase in terminal font would show as “ la fˆte est … l'‚t‚ ” in an ANSI font. Regards, Stephen Markson The Pharmacy Examining Board of Canada 416.979.2431 x251 From: [email protected] [mailto:[email protected]] On Behalf Of Dennis McGrath Sent: January-06-15 16:47 To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Fixed field file It is different based on the font that you pick. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Bruce A. Chitiea Sent: Tuesday, January 06, 2015 3:19 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Fixed field file [Alt-255] was a real fave back in the day. I still find it working in various Windows-based applications. Works in Outlook. Didn’t Microsoft introduce a different [Alt-xxx] for HdSpace in Windows 95? Bruce From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Dennis McGrath Sent: Tuesday, January 06, 2015 6:51 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Fixed field file It is really funny how inconsistent various viewers are about interpreting LF and CR. LF is a linefeed which originally created a new line. CR originally just returned the cursor to the beginning of the line. And Microsoft (or whoever) made a major mistake in not retaining 255 as a blank character. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Karen Tellef Sent: Tuesday, January 06, 2015 8:43 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Fixed field file What do you mean, Dennis? See my response below (I'll strip all posts and just show it). I tried just a 13, just a 10, and a 13/10. Putting a 13 in there anywhere created a double cr karen -----Original Message----- From: Dennis McGrath <[email protected]<mailto:[email protected]>> To: RBASE-L Mailing List <[email protected]<mailto:[email protected]>> Sent: Tue, Jan 6, 2015 8:34 am Subject: [RBASE-L] - Re: Fixed field file How about adding a CR character at the end? 2 cR’s may not be a problem, it is the LF that makes a new line. Dennis McGrath Well, Albert's solution ALMOST works. It does indeed put a carriage return exactly where I want it, so it retains the 675 blank spaces at the end. However, it puts an extra carriage return (therefore a blank row) between each row of data. Is there a way to suppress that, like a "write.... continue" would? Here's the relevant code and how different "vCRLF" variables evaluated: SET WIDTH 1500 SET VAR vCRLF = (CHAR(013)) SET HEADINGS OFF SET SELMARGIN 1 OUTPUT MIB.TXT SELECT ( LJS(SGET(policy_no,12,1),50) + LJS(tmpUniqueText,50) + LJS(ssn,9) + LJS(firstname,50) + + ....... + (SFIL(' ',675)) + .vCRLF )=1450 + FROM tmpMIB OUTPUT SCREEN Value of vCRLF: char(013) + char(010) this puts a blank row between each data row char(013) same as above char(010) does not retain the blank spaces, does a carriage return right after last data Karen
