Re: Source Opens with trailing spaces not trimmed

OK, now I, who HAVE used WDSC/RDp/RDi/RDP (again), am getting confused on just what is the problem being stated.

Buck just posted that the editor has never trimmed the trailing spaces. Michael, you say the exact opposite. I'm inclined to go with your view, but see my thoughts here.

I have always been able to click in the area after the last non-blank. If I then hit the End key, it usually positions back to just after that last non-blank - and I'm using RDi 9.1.whatever is the latest. So this suggests that RDi does recognize the end of data, without trailing blanks.

I can drag or otherwise paste text into that "empty" space, and then the intervening blanks are there, as I expect them to be.

When I save into a PF-SRC member, the existence of these trailing blanks seems unimportant - and they are not recognized when the member is opened again, so far as I can tell. I will not speak about IFS-stored source - we are not using it at all.

I will use the TRIM command sometimes, if only to make the END key work better or to clean things up if I want to copy/paste from RDi into a text editor, say.

I have to wonder if any of the behavior is inherited from the BRIEF editor in Code/400 (IIRC). But maybe that doesn't matter.

I have to wonder if what people say is "not trimming trailing spaces" is just thinking that, because we can click in the "empty" space, that there are "real" blanks there - they probably are not! Until you do some paste into that area.

OK, enough for now - the waters are murky enough!

Vern

On 2/17/2015 10:36 AM, MichaelQuigley@xxxxxxxxxx wrote:

John-

I'm sure it doesn't make sense to you not being a user. Of course your
comments don't make sense to me being a long-time user of WDSC, RDi, and
all the versions in between.

The editor has always trimmed the trailing spaces when opening source
members. Then when saving source members, there's no need to pad the
spaces as it's data being written to a fixed length field (SRCDTA) and
character field data is always padded with spaces.

e.g.,
dcl-s SampleField char(10);

SampleField = 'A';

SampleField will contain 'A '--i.e, with the extra nine spaces on
the end.

If you want to understand RDi, maybe you could try it sometime.


"WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx> wrote on 02/17/2015 11:00:08 AM:

----- Message from John Yeung <gallium.arsenide@xxxxxxxxx> on Tue,
17 Feb 2015 07:57:45 -0500 -----

To:

"Rational Developer for IBM i / Websphere Development Studio Client
for System i & iSeries" <wdsci-l@xxxxxxxxxxxx>

Subject:

Re: [WDSCI-L] Source Opens with trailing spaces not trimmed

On Tue, Feb 17, 2015 at 4:41 AM, Paul Bailey <PaulBailey@xxxxxxxxxx>

wrote:

We also have that problem, and we don't use the IFS to
store the source.

This strikes me (as someone who doesn't use RDi, but uses other
programmer's editors for Windows) as very odd. If your source is in

source

physical files, then the record lengths are fixed; and in principle, you
*should* have blank spaces at the end of every line, to pad the record.

Not in the editor John.

(I
presume this is what Charles meant when he said the "trailing space

issue"

should only be for folks with source in (stream files in the non-QSYS
portion of) the IFS.)

. . .
. . .
. . .

John Y.