×
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.
It took me a little time to figure out what it was doing, then a little longer to adapt to it, but now I find it very useful. There was a piece of ugly, deeply nested fixed format code I had to alter recently, adding another intermediate DO loop to it (gag!), and the feedback made it easier for me to put the new ENDDO in the correct place among all the existing ENDIFs. Yes, it can be distracting, but I find it less so than the error messages popping in from the syntax checker. Just my opinion, of course.
Dave Shaw
________________________________
From: Edmund Reinhardt <edmund.reinhardt@xxxxxxxxxx>
To: Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries <wdsci-l@xxxxxxxxxxxx>
Sent: Thursday, November 7, 2013 10:51 AM
Subject: Re: [WDSCI-L] Squiggly yellow lines
Thanks for the example Stuart,
I have worked through it and RDi is behaving properly in each instance.
Without a semicolon, the next line is interpreted as being a continuation
of the current incomplete one and therefore is not parsed correctly. In
the example below, the next line is a FOR statement, so its ENDFOR
statement is orphaned etc.
One improvement we have delivered in the meantime is to automatically
provide an ENDSL; as soon as you hit enter on the SELECT;
But the yellow squigglies are giving you feedback that your syntax is
broken and my tooling is not going to provide an accurate model until it is
fixed. If you were to run a compile you would likely get many more
messages. This is of course why you done try to compile on every
keystroke, but getting instant feedback, does tell you if you should even
attempt a compile because the code is incomplete.
This is how the most modern IDEs provide feedback on the syntactical
correctness of your code as you enter it. It may give you some incentive
to make sure that your source is roughly syntactically correct, in which
case our tooling can provide you better support.
I understand that this may be distracting, but as you get used to it, I
think you will find it useful immediate feedback. If you know you are only
part way through coding a statement, you can safely ignore them. But if
you think you are working with valid code and you see them, it is a very
useful flag, that you missed something.
As to the fact that the errors are further down in the code, I understand
that this would be confusing as it may not be obvious which syntax error is
causing the complaint at a later point in the source. A good strategy is to
fix the first line with an annotation first, because that fix may cause the
rest of the source to be understandable and all other annotations to
disappear. You can tell which line is the first offender by looking at the
top yellow indicator on the RIGHT-HAND side of the editor. The right-hand
side has annotations for errors on every line in the entire source. If you
click on them, it will take you to the offending line. The left-hand side
only has annotations for the lines that are currently visible.
In many ways this is not unlike fixing compile errors, except that this
feedback is immediate and only highlights MAJOR syntactic problems.
As an Amazon Associate we earn from qualifying purchases.
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.