Re[4]: [amibroker] Run time debugging for includes, AmiBroker Email List Archive

Yes, but we don't have a programmable custom programmable button in the Editor main menu. We could even write the code in afl!

A small external script file could be written to both embed the include file and then strip it when you're finished with the debugging.

On Tue, Feb 10, 2009 at 2:18 PM, Herman <psytek@xxxxxxxx> 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.

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.

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.

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