API Support Forum
User Profile

Viewing User Profile for: jlanawalt


About

Feb 12, 2009 07:48 PM

Dec 14, 2016 11:08 AM

Dec 14, 2016 11:10 AM

http://www.geckosoftware.com/

Contact
Send Private Message


Post Statistics
jlanawalt has contributed to 88 posts out of 5593 total posts (1.57%) in 5563 days (0.00 posts per day).

20 most recent posts:

API Support » OEC API COM .NET Framework supported versions? Dec 14, 2016 @ 11:08 AM (Total replies: 4)

OK, so it requires .NET 2.0, not .NET 2.0 and higher (certainly not .NET 4+). We also want to keep a wide range of compatibility, especially to support Windows 7 and 10 at the same time. The FAQ lead me to believe it could run on all later versions of .NET and so I thought I was doing something wrong when it didn't work.

The platform conflict getting the COM API to initialize wasn't an 32 / 64 bit issue, it was attempting to run it on a system with .NET 4.6 and no .NET 2.0. I wanted see if the COM API would run without .NET 2.0. It didn't appear to work.

Our application isn't new and it doesn't naively use .NET. We've been developing it since before Windows 7 came out and it is written in C++ using MFC. My understanding is that unless we switch to using the CLR ourselves, perhaps using C++/CLI, we need a COM interface to interact with managed code.

To recap my questions.

Does the API COM .NET framework run without any issues on .NET 4.5 or 4.6?


From my testing it seems the answer is No.

Can the API COM .NET framework be made to run on .NET 4.5 and 4.6 while still working with systems with .NET 3.5 or even the old .NET 2.0 installed?


I don't know what dependencies your COM API has beyond the .NET managed dlls like API.dll, or if API.dll works on all verions of .NET. Because I don't know this, I don't know if it could be as simple as your adding supportedRuntime version="v4.0" to the application configuration file so that it would "just work" on Windows 8 & 10 like it currently "just works" on Vista and 7 and, if you install the .NET 3.5 framework, on XP.

--
Jacob Anawalt
API Support » OEC API COM .NET Framework supported versions? Dec 05, 2016 @ 10:06 AM (Total replies: 4)

I tested on a Windows 10 system with .NET 4.6 and it fails to create the COM instance, so I guess the question is, can the API COM .NET framework be made to run on .NET 4.5 and 4.6 while still working with systems with .NET 3.5 or even the old .NET 2.0 installed?
--
Jacob Anawalt
API Support » OEC API COM .NET Framework supported versions? Dec 02, 2016 @ 05:09 PM (Total replies: 4)

Hi,

Does the API COM .NET framework run without any issues on .NET 4.5 or 4.6? We'd like to install on Windows 8 and 10 without messing with missing .NET 3.5.

Your documentation's FAQ it says:
What are technical requirements for OECAPI?
Windows XP and higher. .NET 2.0 and higher

When I run the installer for OEC API COM 3.5.14.6 on Windows 10 the Setup gives a warning

.NET Framework v2.0 not detected. Continue installation?


If I continue I get to another dialog, for Windows Features saying

Windows Features
An app on your PC needs the following Window Feature:
.NET Framework 3.5 (includes .NET 2.0 and 3.0)

Download and install this feature
Windows will get the files that it needs from Windows Update and complete the installation.

Skip this installation
Your apps might not work correctly without this feature.
Cancel


It tells windows to download the required files. Then later "The following feature was successfully installed" so your installer handles this, but it would be nicer if none of that was necessary.

Thanks,
Jacob
--
Jacob Anawalt
API Support » Connect failed, invalid pointer address Jun 26, 2014 @ 12:56 PM (Total replies: 2)

Interesting. We don't give our users direct access to that value, it is hard coded as either sim.openecry.com or prod.openecry.com depending on if they choose the "Demo" or "Real" radio button at login so the host value should always be the same from any customer.

The customer was using a different setup. They were using Bootcamp on a Macbook Pro with only Windows 7 installed. They were going to take a break until the end of this month and order a new computer (but I think it was going to be another Mac...)

Thank you for the insight,
--
Jacob Anawalt

API Support » OEC API COM File versioning request Jun 26, 2014 @ 12:43 PM (Total replies: 3)

Great, I look forward to having version numbers on the OECAPICOM installer's file name, the file properties, and on OECAPICOM.dll's properties.

Quote: Also, it is currently impossible to develop new code using any new OEC API COM API.exe dlls and also maintain existing code using the OEC API COM exe that has the older dlls used by our current users. If the old and new OEC API COM API.exe to had different version numbers, this would not be the case.


I want to restate that my request didn't have anything to do with the COM exported UUID versioning that I believe is required to have two versions of OEC API COM installed at the same time. Just simply file versions for OECAPICOM.dll, OEC API COM 3.5.exe installer, and expanding the naming of the installer to match the OECAPICOM.dll file version.

If your next version will also have UUID versioning to allow multiple versions to exist, we welcome that as well.

Thank you,
--
Jacob Anawalt

API Support » Connect failed, invalid pointer address Jun 02, 2014 @ 06:38 PM (Total replies: 2)

We have a customer that cannot log in. The OnError callback LPDISPATCH exception ex->Message is:

Connect to OEC Server failed. Please check your internet connection.
The system detected an invalid pointer address in attempting to use a pointer argument in a call


I have seen the .NET stack trace dialog about pointer addresses when a different version of OECAPICOM is installed and registered. This is nothing like that message and no other OEC program is installed on the system.

How can we find out what pointer argument had an invalid address on their system?

What is the likely cause of this error?

Thank you,
--
Jacob Anawalt

API Support » OEC API COM File versioning request Mar 26, 2014 @ 03:48 PM (Total replies: 3)

Hi,

I noticed that the latest OEC Trader Demo installer is named "OEC Trader Demo 3.5.13.2.exe". This is great! I no longer have to dig through "OEC Trader Demo 3.5 (#).exe" files in my Downloads folder to figure out which one is which. I also noticed that it has the file resource set with a matching File version and Product version of 3.5.13.2, so I can double check there in case the name gets changed.

It would be very helpful if the file name of "OEC API COM 3.5.exe" were to also update in the same way, and if it's resource had the file and product versions set. It would be nice if they were incremented like OEC Trader.

I also noticed that the file and product versions of API.dll and CommLib.dll installed by OEC Trader Demo 3.5.13.2.exe are 3.5.13.0 and the file and product versions of Trader.exe is 3.5.13.2. That is pretty handy when trying to figure out which ones go together. I don't know what the .2 means. Maybe you had a few internal builds where all you changed was the UI. That seems like a reasonable way to version it.

Could OECAPICOM.dll be versioned like Trader.exe appears to be, since it is also a consumer of API.dll and CommLib.dll assemblies?

Then we could talk about what version of OECAPICOM.dll we have without looking at a bunch of time stamps and file sizes. I wouldn't expect them to have the exact same version down to the build level, but if it had the same major.minor.patch we could feel more confident that we have the same feature set as OEC API and OEC Trader.

PS. This doesn't have anything to do with the COM exported UUID versioning. Just simply file versions for OECAPICOM.dll, OEC API COM 3.5.exe installer, and expanding the naming of the installer to match the OECAPICOM.dll file version.

Thank you for the consideration,
--
Jacob Anawalt

API Support » Querying API version Mar 26, 2014 @ 03:17 PM (Total replies: 6)

The Assembly tags at the top of the pages in the API documentation make more sense now:

Assembly: API (in API.dll) Version: 3.5.0.0 (3.5.12.0)

Thank you for putting that and the version history in there.

I noticed that starting in September of 2013 you began incrementing the API.dll and CommLib.dll assembly file versions and noting those versions in the change logs. It is also appreciated.
--
Jacob Anawalt

API Support » Querying API version Mar 26, 2014 @ 02:30 PM (Total replies: 6)

Is it the Assembly File Version that is updated, or also the Assembly Version?

That code returns v = {3.5.0.0}

I checked out the OEC API Example from GitHub and added that call in InitializeComponent of MainForm.Designer.cs, just after oecClient1 is created. I copied API.dll, CommLib.dll, and ProtoSharp.Core.dll from Trader Demo 3.5 (3.5.12.2).

Using this code:


System.Reflection.Assembly oecapiAssembly = System.Reflection.Assembly
.GetAssembly(oecClient1.GetType());
System.Version v = oecapiAssembly.GetName().Version;
System.Diagnostics.FileVersionInfo fvi =
System.Diagnostics.FileVersionInfo.GetVersionInfo(oecapiAssembly.Location);


I get:
v = {3.5.0.0}
fvi.FileVersion = "3.5.13.0"

The FileVersion matches API.dll Windows Explorer Properties for the File version and Product version.

The docs said I could copy the assemblies from OEC Trader or use NuGet. I can use NuGet if that would have a different result.
--
Jacob Anawalt

API Support » Querying API version Mar 26, 2014 @ 01:52 PM (Total replies: 6)

Like this?

System.Version v = System.Reflection.Assembly
.GetAssembly(oecClient1.GetType()).GetName().Version;
--
Jacob Anawalt

API Support » Querying API version Mar 26, 2014 @ 01:06 PM (Total replies: 6)

Hi,

Is there a method for asking the API what it's version is?

I looked through the documentation but may have overlooked it.

Thank you,
--
Jacob Anawalt

API Support » Invalid pointer address in attempting to use a pointer argument in a call Apr 26, 2013 @ 02:27 PM (Total replies: 0)

Hi,

We get the following error trying to connect with OECAPICOM and with OEC Trader Demo 3.5 on a particular system:

System Error: Connect to OEC Server failed. Please check your internet connection. The system detected an invalid pointer address in attempting to use a pointer argument in a call.

Has anyone seen this before?
What can we do to fix it?
--
Jacob Anawalt

API Support » OnError Index was out of range. Dec 19, 2012 @ 01:26 PM (Total replies: 1)

Yesterday we had a customer frequently getting this message on their demo account, but I didn't notice the report until today when it seems to not be happening, at least not to me when I log into their account.

Index was out of Range. Must be non-negative and less than the size of the collection. Parameter name: Index

Is there a way we can track down what may have been causing this error with our use of OEC API COM? We have this issue occasionally and have not found the right place to log the source of this error. Usually it is a time-sensitive issue related to some order and goes away by the end of the trading session or when the order fills.
--
Jacob Anawalt

API Support » PriceToString StringToPrice round-tripping with comma decimal Dec 13, 2012 @ 05:54 PM (Total replies: 3)

Do you imagine it would be a server-side or client library fix? We can code a work-around but would like to have some idea if a fix will cause our work-around to cause problems requiring another update on our end.

Thank you,

API Support » PriceToString StringToPrice round-tripping with comma decimal Dec 10, 2012 @ 07:32 PM (Total replies: 3)

We have a customer in Europe who's computer is set to their expected locale with the comma as a decimal. We have found that the PriceToString and StringToPrice functions do not round-trip the same values when working with contracts that have a fractional format, like grain options (eg "OZCF3 C7,4")

Given the following C++ code:


_bstr_t constr("OZCF3 C7,4");
OECAPICOM::IContractPtr con = OECAPI()->Contracts->Item(constr);
if(con) {
_bstr_t string("0.06 7");
double price = con->StringToPrice(string);
_bstr_t string2 = con->PriceToString(price);
double price2 = con->StringToPrice(string2);
_bstr_t string3 = con->PriceToString(price2);
}

These are our outputs:
string {"0.06 7" (1)} _bstr_t
price 6.0087500000000000 double
string2 {"6.00 7" (1)} _bstr_t
price2 600.00874999999996 double
string3 {"600.00 7" (1)} _bstr_t

See how the value increases from 0.06 to 600.00.

We can attempt to correct for this by replacing the decimal with a comma:


_bstr_t constr("OZCF3 C7,4");
OECAPICOM::IContractPtr con = OECAPI()->Contracts->Item(constr);
if(con) {
_bstr_t string("0,06 7");
double price = con->StringToPrice(string);
_bstr_t string2 = con->PriceToString(price);
}

string {"0,06 7" (1)} _bstr_t
price 0.068750000000000006 double
string2 {"0.06 7" (1)} _bstr_t

When we work with non-fractional values this drift does not happen. Also we find it interesting that while the parsing expects a comma, the string formatting does not produce one.

FIX Support » Multiple connections? Dec 06, 2012 @ 02:45 PM (Total replies: 1)

The OEC FIX API documentation dated Wednesday, April 13, 2011 says "OEC servers support only one user connection: new connection via OEC Trader will disconnect FIX connection of
this user."

Is this still the case? Will a connection from a FIX client boot all other OEC Trader connections, or can multiple clients connect as we can between different registered OEC One Link or OEC COM API connections?

API Support » AvgPositionList Position.Date or .Long.Timestamp and .Short.Timestamp zero Sep 21, 2012 @ 02:50 PM (Total replies: 0)

We have a demo trading account who's options orders time stamps are getting set to 0.0. We seem to get a valid number when the order is accepted and goes to working, but when the average positions changes or the account balance changes and we iterate the AveragePositionsList, we are finding that the Position.Date has a value of 0.0. If the Position.Net.Volume is long, the Position.Long.Timestamp can be zero, and if it is short, the Position.Short.Timestamp can be zero.

If we check the list moments later, in response to a user action, then we get non-zero values for those options orders.

Why would the Date or Timestamp fields be zero sometimes? What does that indicate. Is there a message we are overlooking that says "we are done updating the position's list, the time stamps are good again, check now."

Thank you

API Support » Extra options strikes at 100x Sep 18, 2012 @ 06:59 PM (Total replies: 2)

I hadn't noticed that the 100x ones were all puts in this case. We will see what we can do with that. Thank you.

API Support » Extra options strikes at 100x Sep 18, 2012 @ 02:25 PM (Total replies: 2)

We are sometimes getting extra strikes back that appear to be 100x too high.

For example, in OEC Trader Demo's option chain for the OAUDV2 (October 2012) 6AZ2 options, range all, it lists strikes from 82 to 120.

Using the same account with OECCOM API we get the IContractPtr for 6AZ2, and then after verifying it HasOptions we get it's IContractListPtr to it's Options. Iterating this list by index, we get 198 strikes with symbols from 12000 to 8200 like "OAUDV2 P12000" that don't work, and from 120 to 82 like "OAUDV2 P120" that do work.

Why do we get the extra 100x too large strikes? What is OEC Trader Demo doing to filter them out?

API Support » White Sugar (WSG) Contracts request returns in OnContractsChange as a "W" Aug 13, 2012 @ 04:56 PM (Total replies: 1)

It looks like WSG is being returned by the demo server again so we can no longer reproduce this error.

It would have been nice to know that this was server-side and what tests we ought to be doing to avoid a bad value in OnContractsChanged.