This is a strange behaviour I can't figure out.
Sometimes, the AFL code editor spits out ascii code like the one in the image rather than carrying out the action, eg this is a CTRL+S. I would then have to press the "Esc" key which seems to clear whatever it is that is doing it, then perform the CTRL action again.
It seems to happen randomly, so if I get it to a point where Ctrl+S saves the file, then just hold Ctrl+S down, after a random number of seconds ( under 10 for the 3 times that I've tried ), it will start spamming this code which I've found is <0x13> in another editor that reads ascii codes.
Confirmed that <0x13> is Ctrl+S in ascii. ASCII Table - ASCII character codes - SS64.com
Ctrl S works correctly. It should be pressed only if there is an unsaved modification.
Hi @Tomasz,
I'm able to reproduce this occasionally. In the image below, you see that the Save button is enabled which means there has been changes to the formula.
If I use Ctrl+Z to undo or Ctrl+S to save, it prints the code rather than performing the undo or save action.
It's not a big issue but annoying especially when undo doesn't work.
Cheers,
Joe
I repeat - I checked it and Ctrl+S WORKS CORRECTLY. NO MATTER how I press Ctrl+S it NEVER produces any codes. So it is NOT AmiBroked doing that, but some third party that you installed on your computer. You might be using AutoHot key or similar programs that install global keyboard hooks or you have virus or something that interecepts normal keyboard operation.
Here are the steps that can be used to reproduce the issue @Tomasz @mordrax. Minimal software installed, new windows install; certainly no AutoHot key. Would be happy to demonstrate in a new VM as well if that would help.
If IBGateway is required to trigger the problem, then most possibly IBGatweway is the culprit. Try WITHOUT IBGateway.
Thanks for going to the effort of reproducing this @vmonkey , this was a showstopper for me at the time and I wanted to have realtime data feeds so stopping IBGateway isn't a great workaround.
I have since moved on from AFL editor to using Sublime text, VSCode, both of which works without the weird error and comes with modern code editor support for various quality of life features I've come to rely on so it's worked out well for me.
I was not suggesting not using real-time feed. I was saying: try if the same happens WITHOUT IBGateway. The principle idea for finding issues is elimination of variables.
As I wrote I can press Ctrl+S millions of times and it never produces any visible codes in the editor.
FWIW, the ASCII char 19 (0x13 that is visualized in the Scintilla editor as DC3) original usage is explained here:
FWIW 2... DC3 appears also if you press the sequence <ctrl><shift>s (without the need to open the TWS Gateway)
Ctrl+Shift+S is NOT Ctrl+S. It is different key combination. Save accelerator key is Ctrl+S NOT anything else.
The trick to replicating the issue is to close IBGateway while AmiBroker is still connected to it using the IB datafeed plugin, but before the user changes the data source to 'local database'.
It creates the red 'ERROR' notice down in the plugin status window. After a couple of seconds delay, the interface will allow you to go into the database settings and switch the data source from the Interactive Brokers data plugin to a 'local database'.
After performing these steps, is where the user should be able to see the intermittent problem when using the AFL editor to edit.. I could not replicate the issue otherwise.
i use VSCode for Python. Do you have a language support extension for AFL in VSCode? I use the Amibroker AFL editor which works fine for me. I was just wondering what extension you use in VSCode to support AFL. Thanks
I have to re-iterate, that AFL Editor provides features NOT to be found in external editor for AFL.
They are fine for languages like Python or C++ BUT NOT FOR AFL.
In External editors, you won't see in-line error reporting, there is no syntax check, there is no special handling of "Apply indicator", No automatic "Send to analysis", no AFL code snippets, no parameter call tips. External editors don't know how to reset parameters when, etc, etc.
You are going to have a LOT OF problems with using 3rd party editors for AFL as AFL Editor does many things behind scenes that you are not aware of.
Plus AFL Editor is order of magnitude FASTER than Visual Studio. I hate the delay that VS Code and Visual Studio has even with simple typing. The only usable editor from Microsoft that does not have this dreaded typing delay is Visual C++ 6 from 1998 (but not because Microsoft was great then, but because 20+ years passed and computers were able to catch up with Microsoft's inability to write fast code).
Editor in VS2022 is a CRAWLING, not working.
So it is HIGHLY DISCOURAGED to use 3rd party editors for AFL.
Unfortunately, there is no language server support for AFL outside of AB that I know of. I did toy with the idea of making one, at least for the global variables (eg C and Close) but decided not to deviate that much from my project.
I started using snake/camel case + hungarian to explicitly set my variables apart and made up a lot of conventions to avoid global variable clashes, imperative programming woes. Having global vars shadow local ones was a particularly nasty bug in the early days... so I enforce var declaration.
All that Tomasz detailed above is true. You do not get:
However, and this is highly subjective, as a programmer by trade, these are not the most important productivity features that I needed and I was able to find workarounds for all of them to my satisfaction. So I've made my workflow with VSCode by doing things such as:
creating afl scripts such as enums.afl and constants.afl that removes all guesswork of magic numbers, VSCode will give you intellisense like sublime text, for symbols even though it doesn't know the language extension
having the bible (language reference) always there, you can navigate this with only keyboard shortcuts too (AFL Function Reference), after a while you build up your own libs or a working knowledge of how functions are structured
exclusively using _TRACE/F, with windows debug log, changing the logging levels via AFL parameters
What I need the most in an editor is:
And I completely agree with you @Tomasz that MS Visual Studios is slow as s**t, the last time I touched that was in early 2010s before they added function reference counting to every. single. function. that I didn't care about.
So after being part of this community the last few months, writing 2-3k lines in AFL, answering questions here, I have realized that what I'm doing is not feasible for the majority of people coming here asking basic programming questions and Tomasz's advice completely makes sense.
This is why I don't want to promote my workflow here. It would distract from making the trading systems and create more support problems.
However, for me, I found the AB IDE started being restrictive as I hit about 5 - 10 files ( which isn't recommended ), include/_once had quirks and definitely as I started to go above 1-2k loc, scaling was becoming an issue so I chose to invest my time to make a workflow outside of AB.
To give you an idea, this is my VScode project, it's pretty small and I've found VSCode to be a pleasant surprise after being convinced intellij was the way to go for the last 5 yrs.
If you're just starting out in AB, or do not have 5-10+ yrs programming exp, stick with AB's IDE, you'll get a lot more done within the ecosystem.
If you're writing anything more than a few files, 1k+ loc systems and thinking of going outside of AB, PM me and I'll be happy to share details. But just beware, if you step outside AB, you've got to be capable enough to own your choice. This means constantly searching the forum and diagnosing your own issues.
It is interesting comment. Could you elaborate what you mean with "superior search functionality" and "switching between files". I am not sure what you are missing in search features in AFL Editor and what is wrong with using TABS to quickly switch between AFL files?
As to multi-cursor editing I can add it in the next version 
As for cursor history navigation - do you want that to be line-based (only keep track of last visited lines) or track movements down to single character position within line?
Please don't take this as criticism of the AFL editor, also, I'm just one anecdotal voice. The devs I work with have very different workflows ranging from vi/emacs to notepad++ and everything in between.
Having said that, I don't care for most of the "advanced" features in IDEs but across all the editors I've used, I've come to rely on a core set to navigate codebases which I can typically find in all IDEs ( MS Visual studios, sublime text, atom, intellij variants like webstorm, pycharm, etc..., now vscode )
So to answer your questions:
w.r.t superior searching
this screenshot shows two ways of navigation:
Ctrl + Shift + F finds strings in all files.
Ctrl + Shift + P lets me go to a file ( if I happen to remember the file name of what I'm looking for which is surprisingly not often... )
So let's say I want a color, but I've forgotten what color I want, I can either
Ctrl + [ to cursor back to where I was or Ctrl + ] to go forward to colors again to pick another color.
( I lied, I didn't use snake case but rather stayed with AB's camel case for AB globals )
Now, colorGreen is already defined in AB, so I leave this as comment for VSCode to pick up via intellisense and it doesn't conflict with my afl scripts. This is a workaround for using VSCode instead of the nice intellisense support in AB AFL editor.
w.r.t switching files
Part of it is demonstrated above with Ctrl + Shift + P, but it's also about easily splitting the screen, and being able to find definitions of my own functions and be able to navigate back/forth cursor positions so I can look at my implementation then go back to continue coding.
w.r.t multi cursor, sublime text was the first editor where I really found the power of it, and I've never looked back, it's just something that I ( no one else around me that I know of ) depend on. So I've converted AB's constants, enums, statuses across to global variables in a couple of minutes using multi cursor support. They sit in enums/status/constants.afl
And so this just allows me to be really confident that I don't have any typos, make it easy to reference all status types, strongly type the action as enums so I don't get the numbers mixed up ( eg. was actionBacktest 4 or 5? to me, it's actionBacktest = 4 in enums.afl ). It's repeating what is already in AB... I know... but yeah.
( I know I don't need all these statuses... when it becomes a performance issue, I'll consider not including it everywhere, until then, I'd rather have it and not think about it )
w.r.t cursor history navigation
I've honestly never thought about it. The main usage is when I navigate to one of these places and want to go back to my code quickly:
And so the ability to find code only using the keyboard and jump between own code, searched code, library code is the main motivation.
Given that, I would not expect the back navigation to take the cursor to the previous character that I've typed, but rather to a trigger point defined by some list of things like the points above.
@Tomasz I do want to stress that I'm not expecting these quality of life features in AB's AFL editor itself, nor would I likely be persuaded to go back to the editor.
I think I'm a niche use case who can look after myself to get what I want. I'm also not wedded to VSCode... honestly did not expect to be back on a M$ product... but it actually works well and has the extensions I need for CMake, cpp, rust, elm, js, react , dbt/sql, terraform, markdown etc... all the stuff I use during the day so why not.
As a suggestion, perhaps looking into making a language server for AFL is a powerful way to tap into existing editor support for the major IDE vendors. Rather than adding IDE features to your editor, it's exposing your language to existing editors through a common interface and will widen your audience.
This is actually what @empottasch was asking about and what I would have used/contributed to had it existed as an open source project.
Sorry for the long post, hope it's been useful,
Cheers,
Joe
While AFL editor changes are being discussed - I'll throw in my 2 cents. I'd love two things:
Currently the double clicking on the AFL in the chart window will place the file into the active chart window. I never use this functionality as I exclusively use linked files to my charts. An check box could be placed in settings that would allow user to have this functionality if they don't like the default behavior.
@mordax thank you for the detailed feedback