Herman,
reply embedded below.
On Feb 10, 2009, at 2:18 PM, Herman wrote:
Re Idea #1: A new editor window would not display/highlight errors
because the code is not in-line. The extra editor window is not
really needed: I always have my Include files open in another tab so
that I can edit them immediately without looking for them. You just
edit them, and save them when done - very simple and effective.
Idea #1 is just to open the file in an editor window by pointing to
the #include statement in the AFL. Nothing more. That part has
nothing to do with displaying the errors. This is a convenience for
all the rest of us who do not keep all of our 20 include files open
all the time. Opening it in a new tab of the editor window would be
just as good.
However, I did not know that the formula editor was a tabbed editor.
How do I get to that feature? Or else, I am not sure what you mean by
keeping all your include files open in another tab.
What I do is have my Charts Tab in the main AB side tabs set to the
include folder so I can find the right include file more easily. Not
nearly as easy as just pointing and clicking as in idea#1 though.
Even well organized there can be a lot to look through to find the one
of interest if you are serious about using include files to their
fullest. But as I said, I could live without idea #1.
The most powerful debugging method for Include files is to include
them back into the code. There are many errors that can only be
detected that way - including some that AB might not look for. . To
add a feature that expands/collapses the include is probably much
easier to implement for TJ complex error tracking. Remember to that
we can work with nested includes, being able to expand/collapse only
what is needed is preferential to having many windows open up.
While I agree that it would be convenient to operate that way, I don't
think it would be easy to implement. 80% of application code is GUI.
What you suggest would seem to be a GUI nightmare to me. The fact is
that the include files are inline when executed and all the error
tracking is in place now. The problem is just to index the error
context to the editor window with the error. That is already being
computed.
The issue you brought up that now includes can be nested is a real
one. However, the same principle of forwarding the error to the next
include file window can be generalized and still work.
Rather than lament and regurgitate an idea that has already been
rejected, I am looking for a different idea that is acceptable to TJ,
and that will provide a better environment to debug our complex code
than we now have. It is time to let go of the old and forge a new path.
Another outstanding related feature request - I don't remember when
i made it, must be very long ago - is related to the above. It would
allow you to highlight a section of code and then save it as an
include file wherever you want. AB would, after saving, replace the
highlighted code with the proper #include file in your code. This
would be a real time saver.
This would actually be of no interest to me for the way I work. I
save a blank.afl file in the include folder or a nested one. If I
want to make a section of code an include, first I write some comments
in front of the code that describe the function of the section and how
to #include it. That is the part that I leave in the main code. Then
I save the whole thing including those comments to the blank.afl and
save it as per the file name I documented already. This takes 2
minutes and I have a nice new include file.
BR,
Dennis
Best regards,
herman
Tuesday, February 10, 2009, 1:45:03 PM, you wrote:
>
Herman,
I went to vote for your idea, but I see that it was rejected and
closed. However, the INTENT of the idea is a VERY GOOD one.
Perhaps we just need to simplify what is being requested and define
it better so that it will get 90% of the benefit for 10% of the work
by TJ.
It would be great to be able to work with #include files from the
start of the development, which is the direction I am moving
towards. To do that, we need to be able to highlight both editor
code checks and runtime errors.
The editor already checks the syntax of the formulas with all the
included files and will highlight the #include statement of the file
that contains the error.
IDEA #1 How about Shift-Right Click in the #include line would give
a contextual menu option to open the include file in a new editor
window? That gives quick access to displaying the AFL inside the
include. Editing and saving the file is just a normal editor window
operation. Opening the file could be a manual operation, but with a
lot of include files, this could be a hassle. This could be a stand
alone suggestion in its own right.
Then the next and more important thing we need is to be able to
highlight an error in the include file editor window.
IDEA #2 Use the col number in the error line of the main formula to
index into the open window of the include file. Also display the
error at the bottom of the editor window just like the AFL check
does now, but the line and col numbers reindexed to the open window
of the include file. This can be a stand alone suggestion.
I would even be willing to type in that col number by hand if it
would get it implemented sooner, but doing something like right
clicking on the error line to bring the include file to the front
and doing the #2 operation would be far superior.
I believe that would bring include file debugging up to the same
level as regular AFL code check in the editor window.
The next step would be to bring the runtime errors up to the same
level. Once again, we have a line number to the #include statement,
and a col number to the character position inside the file. The
obvious choice is to get the error transfered to the main formula
editor window (which must be open of course), and then it could be
handled in the same way as above.
IDEA #3 Right click on the error message in the runtime log window
to transfer the information to an open editor window to operate as
in idea #2. This would not only help with included file debugging,
but also with straight inline formula runtime debugging. This is
also a stand alone suggestion.
So each of the three ideas brings a useful piece of convenience to
debugging. However, all three together make a complete package of
debugging improvements.
What do you think?
BR,
Dennis
On Feb 10, 2009, at 11:34 AM, Herman wrote:
Hi Dennis,,
Debugging include files is never easy. I suggested once that when we
right-click on "#include" a menu item would pop up that allows the
user to expand/re-collapse the include file. This way errors are
properly highlighted and other bugging techniques, and execution
checks, can be applied. See my suggestion #764 on the feedback center.
Right now we have to do this manually - which, when the include
files are large, easily leads to copy/paste errors.
best regards,
herman
Tuesday, February 10, 2009, 11:20:47 AM, you wrote:
> Hello,
> I have been reorganizing my trading system to a very modular
approach
> using #include for each of the functional modules. My main program
> has become a shell of the various included files.
> When I click an on-chart button, I got a runtime error today that
just
> flashed once and then was gone -- variable 'x' used without being
> initialized at line 555 col 4843. I guessed it was part of a
> ParamTrigger() like button click processing, since the program ran
> after that.
> Line 555 points to an #include statement, but what is column 4843?
> would that be the 4843 character of the file? The actual error
> detected was in line 100 of the include file, so an average of 48
> characters per line would be reasonable with the dense way I code
AFL.
> Is there a quick and easy way to locate the nth character of the
file
> within the Formula Editor for the next time an error inside an
include
> happens (and there will be many now)?
> Best regards,
> Dennis
> ------------------------------------
> **** IMPORTANT ****
> This group is for the discussion between users only.
> This is *NOT* technical support channel.
> *********************
> TO GET TECHNICAL SUPPORT from AmiBroker please send an e-mail
directly to
> SUPPORT {at} amibroker.com
> *********************
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
> For other support material please check also:
> http://www.amibroker.com/support.html
> *********************************
> Yahoo! Groups Links
