EMA ElementList access problem
Hi,
We are using Elektron Message API C++ edition, and have problem with accessing EMA ElementList object after it is created. Below is a very simple code snippet for the usage of the ElementList. Looks like that there is problem with Decoder in the ElementList whis is null and all operation on the element list throws access violation exception:
ElementList elementList;
elementList.addArray("", OmmArray().addInt(9).addInt(8).complete()).complete();
EmaString st = elementList.toString();
bool b = elementList.hasInfo(); // ----> this line throws an access violation exception
while (elementList.forth()) // ----> this line throws an access violation exception too
Actually whatever operation we call on newly created element list it throws an exception.
Do you know the reason for this? Or is it known issue?
Thanks
Regards
Best Answer
-
It seems to be restriction of EMA C++ mentioned in section 3.2.3 Data Class from EMA Developer Guide.
The EMA does not support immediately retrieving data from freshly created OMM containers or messages.
Based on the description above, this should be the case you are experiencing.
0
Answers
-
Thanks for the answer @moragodkrit. Is it possible to have an elementlist stored as a class member and pass it as search list for the retrieved FieldList when calling forth method, instead of creating it every time when iterating thorough filed list? In the documentation it is mentioned that Data class and all classes that inherit from it are designed as temporary short-lived objects. And for this reason do not use them as storage or caching devices. But the code seems working. Thanks
0 -
Though the codes works for now, as far as I understand it may have the case that EMA might need to clean up internal object and it may affect the EMA object you stored as a class member. The Data class was designed as temporary short-lived objects therefore we suggest you to copy the data you need from the ElementList or FiledList object and keep it in your own datstructure of class instead.
0 -
Thanks @moragodkrit. Yes we could keep our own structure. But every time we wish to iterate through received field list, we have to create ElementList and pass it to the forth method of fieldList, and it won't be efficient. The forth method only gets reference to Data as parameter, which in this case is a ElementList as search list.
0
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 60 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛