Originally Posted By: jcl
Do you mean a code like "AAPL-OPT-150-20180303-USD"? That's not supplied by the plugin. It is an internal code used only by Zorro for sending strike, expiry and other parameters to the IB plugin. The API does not know this code. If broker APIs have similar codes in internal lists, they are then broker specific, and not used by Zorro.

Yes, that's it! laugh

Did you know that Zorro has been sending IB codes to my Ally plugin for options, and that my plugin had to parse the IB codes and translate them to Ally codes? (Look at my source. I distinguish between "Zorro Assets" and "Ally Assets".)

This approach is not feasible for my new plugin, since it supports many brokers, and therefore many broker codes.

I have a new idea:

1) Zorro calls GET_OPTIONS or GET_FUTURES.
2) Plugin fills CONTRACT structs.

BUT... instead of filling in the exchange info for the time variable, the plugin sends a uint32_t value instead. This will act as an Asset ID number.

Before: strcpy to CONTRACT.time the exchange name, eight bytes max.
New approach: memcpy eight bytes to CONTRACT.time: "ID#\0xxxx", where "ID#\0" is a header, and "xxxx" is the uint32_t Asset ID number which the plugin has memorized.

Plugin will be responsible for memorizing the Asset broker code associated with each Asset ID number.

3) Plugin returns number of structs.

4) NEW FEATURE: Zorro will see that the plugin has filled out the CONTRACT time value in a certain way (such as with a header) and instead of sending an IB code upon BrokerAsset, will send a string indicating the ID number, so that my plugin can retrieve the broker code.

For example: "ID#123456789";

5) My plugin parses this string and retrieves the ID number. Now it knows what broker code to use.

Can this be implemented?

Last edited by AndrewAMD; 12/18/17 14:59. Reason: struct handling clarification