Keith, I also use TextPad and no, I don't know of any that will do the include/exclude thingy. Maybe a C targeted editor will make it pretty for you.
d On Wed, Feb 11, 2009 at 1:35 PM, Keith McCombs <[email protected]>wrote: > Dingo -- > There are many third party editors available which support structured > languages very well (for example, TextPad, which I use). Are there any that > already support the functionality of embedding and striping of include > files? If not, maybe there should be. > > On the same vane, are there any with built in 'prettify'? I appreciate > TJ's effort in adding that feature to the AB Editor. However, I do not use > it, because I don't like the particular results. For example, I do not like > a space after a '(' nor before a ')', or a carriage return before the '{' in > an if statement, and indent only two characters. Also, I don't take sugar > in my coffee. > -- Keith > > dingo wrote: > > 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/ >> >> >> >> >> >> >> >> >> >> >> >> > > > >
