× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Vern/Buck,

Like Vern after opening a source physical file member, pressing the end
key on any source line moves me to the end of the data in that line, not
column 80 or 81. At least most of the time. I have had occasions where it
does move to column 80 (92 for RPGLE). I wish I could reproduce an
instance of this with any consistency. I know Buck says it's never trimmed
the source on opening, but I have to disagree. LPEX has trimmed the
trailing blanks on opening source members for me for years--at least most
of the time. I spent a good 30 to 45 minutes trying to get a member to
open that wouldn't trim the blanks on opening. Nothing I tried would leave
me with 80 or oops 92 columns. Today, the end key is ALWAYS taking me to
the end of the non-blank data and never to the end of the source record
(column 80 or 92--depending on the source type).

And I am on version 9.1.1

Michael

"WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx> wrote on 02/17/2015 01:00:04 PM:
----- Message from Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> on Tue,
17 Feb 2015 11:40:38 -0600 -----

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

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.