It is not "limitation". It works as documented.
AmiBroker works in multiple threads, each chart has separate thread, so AFL editor does. Everything is massively multithreaded and separate. AFL Editor is separate from chart. When you use debugger it does not stop the chart, does not use chart code, it does not block UI, it runs completely separately and independently from chart and uses Backtest "action", not "chart" action.
The editor does not have "visible bars". Only CHART has that concept. Also since there can be dozens of charts each having different zoom level and different values for visible bars changing constantly (for example using real-time data) you would have hard time figuring out what is happening.
As I wrote you, if you want to see "firstvisiblebar" and "lastvisiblebar" from CHART, you have to place _TRACE() in the CHART.
Also you should use, as I wrote before Status("action") to know in what context you are running
printf("%g", Status("action") );
Status function is documented here AFL Function Reference - STATUS
As to "doesn't work as expected", AmiBroker works as documented.
Your expectations should be based on DOCUMENTATION,
not on assumptions.
If you read the manual about the Debugger, here:
https://www.amibroker.com/guide/h_debugger.html
you would notice this:
So for example if you have code like below, the code inside 'if' statements won't execute unless it is actually run in the chart (indicator) or in portfolio backtest in New Analysis window.
if( Status("action") == actionIndicator )
{
// breakpoint placed here won't trigger under debugger
because condition above is not met
}
if( Status("action") == actionPortfolio )
{
// breakpoint placed here won't trigger under debugger
because condition above is not met
}
AmiBroker executes code in various contexts indicated by "action" status. Parts of the code can be conditionally executed in certain contexts using statements like shown above. This allows for example to call Plot() only in charts and access backtest object only when it is available.
As of version 6.10, the debugger runs the code with actionBacktest context. To debug code that is run conditionally in other contexts, you can temporarily disable the conditional check, but please note that you still can not access certain objects because they are simply not available. Specificaly GetBacktesterObject() when called anywhere outside second phase of portfolio backtest within New Analysis would return empty (Null) object. In the future this limitation may be removed.
It can be frustrating for developers to hear unfair comments like "the software has limitations or doesn't work as expected," especially when the software functions exactly as documented. This frustration stems from several key factors:
- Effort and Expertise: Developers invest significant time and effort into designing, coding, testing, and documenting software. When a user criticizes the software without fully understanding how it works or reading the documentation, it can feel like the developer's hard work and expertise are being overlooked or dismissed.
- Pride in Craftsmanship: Many developers take pride in their work, striving to create reliable, efficient, and well-documented software. Hearing that the software "doesn't work as expected" can be demoralizing, particularly when the software functions correctly according to its specifications. It can feel like their craftsmanship is being undervalued.
- Misplaced Blame: When users don't take the time to understand how to properly use the software, they may place the blame on the software for their own mistakes or lack of understanding. This misplaced blame can be frustrating because it shifts responsibility away from the user, who may not have taken the necessary steps to learn how the software operates.
- Communication Gap: Unfair comments often highlight a communication gap between the developer and the user. Developers may feel that they have done their part by providing clear documentation, but if users don't read or comprehend it, the software may be perceived as flawed. This gap can be frustrating because it points to a disconnect between the developer's intentions and the user's experience.
- Impact on Reputation: Negative feedback, even when unfair, can impact a developer's or a software's reputation. In today's interconnected world, such comments can spread quickly and affect how others perceive the software, potentially leading to decreased usage or adoption. Developers may feel that their reputation is at stake, even when the criticism is unfounded.
- Desire for Improvement: Developers often want to improve their software based on constructive feedback. However, when feedback is based on user misunderstanding rather than actual issues, it doesn't provide actionable insights. This can be frustrating because it doesn't contribute to the software's growth or refinement.
- Empathy for Users: Developers often care about their users and want them to have a positive experience. When users struggle due to a lack of understanding, developers may feel a mix of frustration and empathy, knowing that the experience could have been better if the user had engaged with the available resources, such as documentation or tutorials.
In summary, unfair comments can hurt developers because they often reflect a misunderstanding or lack of appreciation for the effort, skill, and care that went into creating the software. It can feel like an unearned criticism that doesn't accurately reflect the reality of the situation, leading to frustration and a sense of being unappreciated.