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



Hi Edmund!

As far as I know, I'm using the one that updates automatically. I'm not sure how to tell; I think it's in the threads here, but I notice that if I change a name in the source I can see the name change in the outline.  Also, I'm only on 9.6.0.1; I haven't updated to 9.6.0.2.  Here's a quick rundown.  I have a source member that, with all the lines uncommented, fails.  Let me start at the failure point.

1. dcl-f and dcl-s statements in place.  I hit refresh on the outline.  Hover works, but context assist does not.
2. I comment out the dcl-s lines, without hitting refresh.  Hover and context assist both work.
3. I uncomment the dcl-s lines.  Hover works, context assist does not.

So it turns out that, I can comment and uncomment those lines and the context assist fails and returns without requiring an outline refresh in between.  That requirement was a figment of my imagination.  :)

And once I realized that a refresh was not necessary, I could do more tests and was able to ascertain something.  It didn't matter which definitions I commented out.  It had more to do with the total number of definition lines.  I tend to declare a whole bunch of named constants for message IDs, literal constants, indicator offsets, and so on.  Basically if I have too many of those, context assist stops.  I can get to a state where commenting out one dcl-s or dcl-c,  any one, makes context assist come back. Uncomment that line, context assist stops working again.  Comment a DIFFERENT line, and context assist come back.

This playing around leads me to think there's a hardcoded limit somewhere that I'm hitting.  Basically, once that threshold is reached, commenting and uncommenting a single definition makes context assist work or fail.

As a final data point, I went back to 9.5.  The same source, fully uncommented, has no problems.  Context assist works fine.  So it's something that changed for 9.6.



On 5/5/2018 8:09 PM, Edmund Reinhardt wrote:
So Joe, are you using the static outline where you have to manually hit
Refresh or the new one which updates on every keystroke?



----- Original message -----
From: Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
Sent by: "WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx>
To: wdsci-l@xxxxxxxxxxxx
Cc:
Subject: Re: [WDSCI-L] File declaration disables context assist
Date: Sat, May 5, 2018 2:34 PM

Unfortunately, it turns out to be more complicated (which is why I
haven't been able to nail it down so far). If I comment out a block of
dcl-s definitions, then it works even with all the file definitions. If
I leave that block of definitions in place, then some combination of
file definitions breaks it, but it's not clear which combination (I have
five externally described files in addition to the WORKSTN file, and
commenting most of them out makes the symptom go away). Putting the
block of dcl-s back in makes different combinations of files fail.

The crazy thing is that throughout every test the constant is visible in
the outline. The hover even works - I can position my cursor over a
place where the constant is used, and it pops up the constant's
definition. So the parsing that finds all the fields is working. It
just looks like the context assist stops functioning; any definition
from my program is not recognized. Basic RPG constructs are fine (BIFs
and opcodes) but not my definitions.

Unfortunately, the only way to test each condition is to refresh the
outline, and since that takes a minute or so, that means I'm limited to
the number of tests I can do. I've run 30 or so tests today and that's
over two hours of my day gone. I'm out of testing time, but I'll try
some other things later perhaps.

On 5/5/2018 1:12 PM, Jon Paris wrote:
> Be interesting to know if this was unique to (say) an IndDS situation
Joe - or if it is simply any file. I guess you might be able to regain
display field access by using an externally derived DS based on the
display file formats.
>
> Just out of interest, does it also apply if the file is declared as a
template?
>
> I can't really do any testing because my context assist has been
flakey ever since V9.5!
>
>
> Jon Paris
>
> www.partner400.com
> www.SystemiDeveloper.com
>
>> On May 5, 2018, at 1:27 PM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
wrote:
>>
>> One of the most painful problems to me is when context assist stops
working. I find it happens more often than not in SQLRPGLE members and
I've tried to find the culprit. I just narrowed it down pretty
significantly, although I still have some work to get a minimal case.
>>
>> If, in my SQLRPGLE program, I have a workstation file declared as so:
>>
>> dcl-f CEPANZD workstn indds(dsInds);
>>
>> Then CTRL-space stops working. Since this is my standard workstation
definition, this means that I effectively cannot use SQLRPGLE without
giving up significant functionality. Now that I know the line of code
that breaks it, I'm going to try to create a minimal case, but this is
the root cause. I just wondered if anyone else had noticed the loss of
context assist.
>>
>> I can make context assist come back by commenting out just that
declaration. Uncomment it, and context assist stops working again. So
I have a rather half-baked work around, although even then I can't
prompt for my display file fields.
>>
>> This is really bad for me. It has actually caused me not to use
SQLRPGLE in complex programs because I rely on the context assist.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.