× 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.



Oh it's definitely a bug. I messed with it a little and discovered that it
seems to happen with any parameter with more than one value specified for
the options() keyword. Any SINGLE value is formatted properly (ie not
there) but multiple values are all there, each as an extra parameter with
extra colons and end parens for each one. Try this example:

d someProc pr extproc( 'someProc' )
d parm1 1a const
d parm2 1a options( *omit: *varsize )
d parm3 1a options( *nopass: *omit )
d parm4 1a options( *nopass: *varsize )
d parm5 1a options( *varsize )
d parm6 1a options( *nopass )
d parm7 1a options( *omit )
d parm8 * value options( *string: *trim )

and you get

someProc(::*varsize)::*nopass)::*varsize):::::*trim))


And anyway if you think about things other than RPG, it DOES make complete
sense to use ( *omit: *nopass ) if you are planning on calling it from a C
program. *NOPASS is great from within RPG I suppose, but does not work
when calling the routine from a C module using a procedure pointer because
the "operational descriptors" are not available (the ILE environment is not
all that integrated after all). *OMIT is better in that case as you can
pass a NULL easily from C and it appears "omitted" to RPG.

Stu




On Wed, Jan 4, 2017 at 2:50 PM, Brian Parkins <goodprophet.bp@xxxxxxxxx>
wrote:

-----Original Message----- From: Stuart Rowe

When I ctrl-space for a procedure, and I pick the one I want and press
Enter, a sort of "template" or "guide" is emplaced into my source code with
the colons to indicate the parameter separation. Keen!

The weird thing is when the procedure has *NOPASS or *OMIT parms, the
emplaced "template" looks really bizarre. Here's a prototype:

d abumAppendField...
d pr n extproc(
d *cnowiden:
d 'abumAppendField'
d )
d abumField likeds( abumField_t )
d const
d options( *varsize )
d abumMsg likeds( abumMsg_t )
d options( *varsize )
d maxlen like( int_t )
d const
d options( *omit: *nopass )

When I ctrl-space and highlight the function and press Enter, I get this:

abumAppendField(:::*nopass));

Not sure what good the *nopass does at this juncture -- but when there are
like 10 of them, it looks REALLY bizarre escpecially when it has to wrap
the line because it got too long due to all the *nopass stuck in there.

Is this on purpose? What is it supposed to indicate to me as part of a
function call? I like it in the prototype picture I get with ctrl-space,
but it seems kind of senseless to emplace it into the source like that.
-----------------------------
Stuart, maybe LPEX is getting "confused" by the definition of the last
parameter (MAXLEN) in the list. Although OPTIONS(*OMIT:*NOPASS) is
perfectly legal, it doesn't make complete sense to have _both_ values
specified for the _last_ parameter. Try removing one of the values, (e.g.
*OMIT) and I think you'll find CTL+SPACE will work a little better. (I
have to agree that this appears to be a "bug" in the Content Assist
function.)

Brian.






--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.
--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.