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.
d On Tue, Feb 10, 2009 at 2:18 PM, Herman <[email protected]> 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<http://www.amibroker.com/feedback/view_bug.php?bug_id=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/ <http://www.amibroker.com/devlog/> > > > > For other support material please check also: > > > http://www.amibroker.com/support.html<http://www.amibroker.com/support.html> > > > > ********************************* > > > Yahoo! Groups Links > > > > http://groups.yahoo.com/group/amibroker/ > > > > Individual Email | Traditional > > > > http://groups.yahoo.com/group/amibroker/join > > > (Yahoo! ID required) > > > > > > mailto:[email protected]<[email protected]> > > > > > > mailto:[email protected]<[email protected]> > > > > [email protected] > > > > http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > >
