That's already doable by using SetForeign()
1 Like
As for Code Check it technically cannot "check all variations" because it actually executes the code and you can't execute both paths of if-else at the same time because this would lead to obvious fatal errors.
Example:
x = StaticVarGet("test");
if( IsNull( x ) )
{
// if 'x' is null make sure that 'y' is zero (not null)
y = 0;
}
else
{
// doing "all variations" would mean running code that expects x to be NOT null here with Null variable
y = x; // now y would be Null while programmer wanted it to be non-null
}
Another example
x = Param("x", 0, 0, 100 );
if( x != 0 ) y = Close / x; // running this with x == 0 would result in division by zero error
It is worth mentioning that Code Check And Profile does THREE things, not one:
- performs parsing (and that checks ALL PATHS, syntactically). Parsing means language grammar check and checking for syntactic correctness. It happens BEFORE execution
- performing EXECUTION (that may only execute certain conditional paths) - this checks for RUNTIME errors. Runtime errors are those that need actual run to be detected.
- performing PROFILING (i.e. measuring the time needed to execute each function call in given formula)
Also, on a side note, GraphXSpace should not be renamed because X in that variable is from "eXtra" space. It means "eXtra graph space". It is not referring to co-ordinates, but to eXtra space above and below chart. Besides backward compatibility is crucial for AmiBroker users and AmiBroker has 30-year tradition of keeping backward compatibility as much as technically possible, so you just don't rename identifiers that are used by lots of existing formulas.
1 Like
This idea could be useful (in particular for the date and ticker but any number of columns on the left side is better).
Furthermore, when we continue to work in the same analysis (in particular in the "explore" mode) and have "customized" the layout of the columns to be displayed, it would be useful if the same layout was preserved the next time the same formula is executed (i.e. I would continue to see only the previously selected columns - while now they are all reselected every time).
It would also not be bad if the layout of the selected columns could be saved in the projects.
1 Like
Windows ListView control does not support such feature like column freezing. Implementing it requires total rewrite of entire of listview. It is not economically viable, too much effort for too little effect.
In the first post I have added implementation schedule showing features suggested here that are already accepted and being worked on. The table will grow one item at a time as the work on subsequent suggestions continues.
3 Likes
Soon to appear version 6.90.2 with two of the suggestions from this list already implemented.
3 Likes
Tickets on Watchlist can be assigned Color Attributes or Tags, for Assigning Preference of Entries or Quality of Signal, Fast reviewing, etc..
2 Likes
Let me try to understand this concept of "color attributes" or "tags" better as there are 2 mutually exclusive yet similar suggestions posted.
- One suggestion by @Sergei wants those 'colored flag' to be assigned to symbols (apparently ONE color per ONE symbol)
- The other suggestion by @Robx mentions "tickets on watch lists", which is a bit unclear, but seems like it wants to have different colors depending on watch list.
What is unclear to me:
-
what added value should those "colors" give compared to existing classification into Groups (single assignment of symbol to group) and Watchlists (multiple assignments of single symbol to multiple watchlists)
-
should be one color per symbol or multiple colors. If multiple colors, I have no idea how do you want to display "multiple colors" in single text (single symbol)
-
What is intended purpose of those "colors" as compared to existing categories
-
Where those "colors" would be displayed (in symbol list only, or elsewhere) and assigned.
This is an additional classification within Watchlists.
Analogy 1: This is a SubWatchlist within a Watchlist.
Analogy 2: Watchlists are an âX-axisâ classification. Coloured flags are âY-axisâ classification. We get a two-dimensional classification.
Colour is an easy way to add an additional classification within an existing one. It is very clear and visual.
This helps to reduce the number of Watchlists.
Examples.
I have Watchlists: Sectors, MegaCap, Semiconductors, Finance, Homebuilds, ....
Inside each Watchlists I mark with coloured flags:
- Securities I bought in long.
- Securities I bought in short.
- Securities I plan to buy and need to keep track of every day.
- Securities with new High and Low to monitor.
- ...
One colour can simply and clearly indicate a symbol. If there are several colours, it is not clear how to indicate one symbol with them?
These colours will be displayed:
- In the symbol list.
- In the Symbols Pane, where you will find Markets, Groups, Sectors, .... Add a folder âColoured Flagsâ or just âFlagsâ. Inside the folder, a list of colours.
Be sure to add AFL functions for working with flags: Set, Del, Get.
But since you are suggesting it as "another dimension", this means that SINGLE symbol might have hundreds of colors. It is impossible to display them at once.
For example when you are in "All" leaf, there are all symbols listed and some of them might have hundreds of color tags assigned.
For me it looks way to complicated. I already imagine complaints like "I have found a BUG !!!! I have set the color and it disappeared!!", from people not understading the concept that one symbol might have zillions of colors and that color change when you change the watch list selection and what happens if watch list is NOT selected category (like you are within group, not watch list).
No. I'm suggesting that ONE symbol can have ONE color.
If I need to specify two "attributes" per symbol, I do it by changing the color.
Example. If I bought a stock, the color is red. If I bought it in short, I will put a different color and that's it.
Can make 10 colors. Set up colors and their names in Preferences.
I initially thought that you wanted ONE color per ONE symbol, but then you
have changed your descriptions and you wrote "This is a SubWatchlist within a Watchlist.". This clearly indicates hierarchy connected with watchlists, which means that say symbol "AAPL" may have "RED" color in watch list 1, and "BLUE" in watch list 2.
So it has "RED" and "BLUE" at the same time!
Imagine that you are in the "ALL" category. Then this symbol has TWO colors.
You also wrote:
"Analogy 2: Watchlists are an âX-axisâ classification. Coloured flags are âY-axisâ classification. We get a two-dimensional classification."
This also suggests that for each "X" (watch list) you can have separate "Y" (color)
This is also what @Robx seemed to want, because he clearly mentioned
"Tickets on Watchlist can be assigned Color Attributes or Tags"
Clearly the "WATCHLIST" is mentioned as some kind of "parent" to those "colors".
If you just wanted ONE COLOR per ONE SYMBOL, without ANY REFERENCE to any other category/watchlist, then this feature should be described as:
"add a COLOR TAG that can be assigned to symbol (one color tag per one symbol), that is consistently displayed regardless of other category given symbol belongs to"
BOTTOM LINE:
- a SINGLE color assignment per symbol is easy to understand and could be added
- a MULTIPLE color assignment per symbol is IMHO too complex and would lead to confusion/support issues
Yes, that's exactly what I meant.
I didn't phrase it accurately earlier.
OK, let us wait what @Robx has to say about that proposal.
Technically this is actually what GROUPS already do. A symbol can belong to ONE GROUP. There is a "GROUP" category that shows up in the symbol list.
You can assign symbols to groups using AFL.
The only thing is that we might add colors to groups.
This is a plugin I'm already using. It's the one I wrote about.
I wrote two similar functions in JavaScript and Python. The Python call was much slower.
When I create composites, the calculation goes through all bars. As a result, the Python call slows down the code a lot.
My suggestion was to ask to see if it is possible to increase the performance of this plugin still?
No AmiPy plugin can't be done any faster because it is NOT the plugin that slows you down but Python interpreter itself.
AmiPy plugin does NOT do any calculations by itself. AmiPy just uses PYTHON runtime and all python code is executed by Python embedded within the plugin. It is done as explained in the docs: 1. Embedding Python in Another Application â Python 3.12.5 documentation So the speed is totally governed by your Python code and Python runtime. Python is generally slow unless you use specialised libraries like NumPy to do number crunching.
-
The maximum number of Industry up to 1024, the maximum number of Sector to 256.
-
The AFL editor can save working sessions and allow users to restore previous sessions.
-
The AFL editor can use VIM keybinding for fast movement, regex replace and search.
-
MQTT database plugin for RT data. -
Users can custom define the database AUX* column name and increase more custom columns
-
ViewâZoomâRange pops dialog window for typing in date/time range
-
Capability for combining multiple strategies and showing each and combined equity curve.
No, everything that you see in the Preferences dialog is meant to be GLOBAL (per program installation / per Windows user), not per chart.
Users pretty often don't understand what these preferences are.
The preferences settings are the DEFAULTS or MAXIMUMS. They are meant as "per installation" settings.
"The number of chart sheets" for example is the MAXIMUM number of tabs you would EVER use. You should NEVER EVER decrease it. You can however increase it. Chart sheets do not take any memory. You are not saving anything by decreasing it. Set it to maximum you ever wanted. If you don't need that many, you just don't use the extra ones (leave them as they are) .
Also "Default zoom" is the DEFAULT, it is not actual chart zoom, but the DEFAULT that is applied when NEW chart is created. It is "starting value" not actual value that chart uses later.
MQTT is a protocol, not data source. There is absolutely zero standards for delivery of market data using MQTT protocol.
There more I think about those "colors" the more I am inclined into just adding color definition to GROUPS. So group can be assigned a "color" and any symbol belonging to that group gets that color.
Groups already fit into categories structure, there are already functions that manipulate all categories including groups. It would just add another visible clue that given symbol belongs to given group if group has defined (non-standard) color.