ELC FAQ – General

201. What is the current version of ELC/ADE?

The current versions of ELC and related products are listed in the first post of their respective threads. Bamboo has done a good job of keeping everything up to date and has maintained version numbers and revision histories.

Latest
ELC v1.05
ADE v1.07

If you are unsure of the version of any product you can just reinstall it and ‘overwrite all’.

With regards to ELC

Originally posted by Bamboo
You can check what version you have by opening the ELC_Version.txt file from the ELCollections.zip file. If you don’t have that file, you don’t have the latest version.

With regards to ADE

Originally posted by Bamboo
You can find out what version of ADE you have by opening the ADE_Version.txt file from the ADE.zip file. If you don’t have that file, then you don’t have the latest version.


202. Which versions of TS does ELC/ADE work with?

ELC, ADE etc have been tested with versions 8.0 upto version 8.3 Build 1631.

ELC definately does NOT work with TradeStation 2000i. This is because it uses a DLL which is incompatible with TS 2000i. There are no plans to make ELC compatible with earlier versions of TS.


203. When would you use ELC and when ADE?

ELC is the main application. It contains the data structures (Maps and Lists) that are used to build other applications. ADE was built entirely using ELC. So ADE is just a subset of ELC.

ADE was designed to save a copy of its data for every bar on the chart. Therefore, ADE can be used for backtesting. Also, ADE was only designed to pass key/value pairs i.e. “open”/1088.25

ELC is generally used for passing real-time data because it does not save copies of data on every bar (though of course you can do this if you want). ELC is usually faster and uses less memory than ADE because it does not have the overhead of saving data for every bar.


204. What are the differences between ELC/ADE and GlobalVariable.dll

See the page Comparing GVs, ELC, ADE, TZS and GD for a detailed comparison.

Originally posted by eKam
The doc of ELCollections says this (emphasis mine): Note that a collection can only be shared within a single application. Charting, RadarScreen, and OptionStation are different applications, so a collection cannot be shared across them. That would be the reason to keep GV.

Bamboo, any plans to improve ELCollections to work across applications?

Originally posted by Bamboo
You’re right. If you need to pass information across application boundaries (e.g. from charting to RadarScreen or vice versa), then you need to use GlobalVariables.

For most cases where you need to pass information around inside an application (e.g. from chart to chart, indicator to indicator, or symbol to symbol within RS), I believe that ELCollections will be a superior tool.

Because of the high flexibility of ELCollections’ data structures, writing a version that works cross-process is very challenging. It’s probably not impossible, but it would be a big chunk of work. (For the technically minded, it would mean writing custom allocators for STL.) I’m not ruling it out, but I’m not promising it any time soon either!

Originally posted by Bamboo
For example, you could create a shared MapSS, which maps strings to strings. The keys of the map could be your “variables”, and the associated string values could be the “variable values”. One nice advantage of this technique over GVs is that the map provides you with a “namespace” so that you don’t have to do something like prefix all your variable names to prevent conflicts. (If you want to pass data from charts to RadarScreen or vice versa, you still need to use GVs though.)

I forgot to mention another advantage of maps – they use a tree-based search, whereas named GVs use a much slower linear search for the variable name. The performance difference probably won’t be perceptible for small numbers of variables, but could become quite significant for larger numbers.

205. File Utilities

205.1. What File Utilities exist within ELC/ADE?

There are a number of low level file utilities within ELC/ADE that can be used in addition to the inbuilt EL commands Print and FileAppend. These ELC/ADE file utilities have general uses within EL programming.

ELC.DirectoryCreate (DirectoryPath)

ELC.DirectoryDelete(DirectoryPath)

ELC.PathExists(FilePath)

ADE.FileExists(FileName)

ListS.FindFiles(ID, FilePattern)

You should refer to the ELC/ADE documentation for the exact usage of these utilities.

Bamboo has also written a further file utility (which is separate from ELC/ADE) called FastFileAppend.

ELC also has a number of higher level file utilities that allow you to save Maps and Lists to disk and read them back to memory. You should refer to the ELC documentation to find out more about them


206. Debugging

206.1. What debugging utilities exist within ELC/ADE?

ELC does not provide any specific debug utilities.

You can use the inbuilt TS EasyLanguage Debugger as well as the normal Print command to output debug data.

ELC/ADE has the functions ELC.RaiseError and ADE.RaiseError which should be used in preference to the TS inbuilt reserved word RaiseRuntimeError. The reasons why are discussed in Topic 206.2. The differences between ELC.RaiseError and ADE.RaiseError are discussed in Topic 206.3.


206.2. When should I use RaiseRuntimeError vs. ELC.RaiseError?

Originally posted by Bamboo
Regarding your question about ELC.RaiseError – I created this function because I found RaiseRuntimeError to be rather unreliable in conjunction with ELC/ADE. It appears that some code can actually continue to run after a runtime error is raised. This can cause downstream errors that override the original error, making it extremely difficult to figure out what happened in the first place. ELC.RaiseError sets a flag in the DLL so that no further DLL code for a study/strategy will execute after a runtime error is raised. This prevents the masking of the original error, but it wouldn’t have any effect in code that doesn’t use ELC/ADE. However, it is highly recommended to use ELC.RaiseError rather than RaiseRuntimeError in code that relies on ELC.


206.3. What is the difference between ELC.RaiseError and ADE.RaiseError?

The underlying code between the two is identical.

To call ELC.RaiseError you use

value1 = ELC.RaiseError(AppName, Message);

So you can specify the ‘AppName’. (It would be typical to use ‘AppName’ to specify the name of your application or calling code so that you can track down errors more easily).

To call ADE.RaiseError you use

value1 = ADE.RaiseError(Message);

And the ‘AppName’ is automatically set to “ADE”;

Otherwise, there is no difference.


207. What happens if ELC and ADE become incompatible with future builds of TradeStation?

Originally posted by mmillar
It’s just guesswork, but I think it’s unlikely that ELC will go out of date but pretty likely that ADE will.

ELC’s only reliance on TS is the SDK. If TS changed this and made it backwardly incompatible that would cause huge problems for lots of people. I doubt TS would do that.

ADE, however, ‘knows’ about timestamps and currently these go down to minutes. My understanding is that TS will introduce seconds at some point in the future and this will throw ADE. It will be a community effort to get ADE working again. Fortunately I don’t think it will be a huge effort.

Saying all that, although Bamboo isn’t around much he is still here and when I’ve found bugs in ELC/ADE before he has fixed them quickly.

更新于 2020年11月2日

这篇文章对您有帮助吗?

相关的话题

留言评论