Invalid callee. - DailyFX Forex Forum

brenzosa · #1 (**permalink**) 08-16-2009, 06:35 PM

Hi,

I recently updated Order2Go (this morning, actually) and am now getting an error message "Invalid callee." when executing CreateEntryOrder() which used to work before.

Anyone know if there are any new requirements on CreateEntryOrder() in the latest build?

Thanks!
Bren

Nikolay.Gekht · #2 (**permalink**) 08-17-2009, 12:12 PM

DISP_E_BADCALLEE is a system error which usually appears during the marshaling operation when destination object is wrong or is already destroyed.
Could you please provide more details on your problem:
1) Which programming language do you use? In case C++ is used and you use the ATL wrappers, did you rebuild your application to let the compiler recognize changes in the interfaces? (Unlike almost all other languages, C++ with ATL wrappers uses early binding by interface instead of late binding by dispids and requires recompiling of the code).
2) How to you can the CreateEntryOrder method?
3) Do you call the CreateEntryOrder method from the same thread which was used to create the core and desktop objects?
4) Does problem appear in the CreateEntryOrder method itself? (For example, if you get the method parameters from other objects, could you please store them into local variables prior to call CreateEntryOrder)?
5) Does problem appear every time or from time to time?
All this information will greatly help to find the real cause of the problem.
Thank you.

brenzosa · #3 (**permalink**) 08-22-2009, 09:01 PM

Hi Nikolay,

Thanks very much for your reply. I reverted to the pre-update version last week and everything worked fine, but I'm worried that one day I will have no choice but to upgrade to latest version and things won't work again.

To answer your questions:

1) I am using Java using Groovy with Scriptom to get COM+ support which always dynamically links to the components.
2) Sorry I didn't understand the question,...
3) No, I am calling from a different thread -- this used to work before the update so if this is a new requirement, then maybe that's the reason.

However, the call to GetPriceHistoryUTC() succeeds which is running on the same thread that calls CreateEntryOrder() (which subsequently fails)

4) Yes it happens in the dispatch call to CreateEntryOrder method itself (Java Stack Trace points specifically to the call)
5) Problem appears every time, no exceptions.

Thanks!

Nikolay.Gekht · #4 (**permalink**) 08-23-2009, 09:07 PM

Quote:

Originally Posted by brenzosa

1) I am using Java using Groovy with Scriptom to get COM+ support which always dynamically links to the components.

Thank you for the information. We will try to reproduce the situation.

Quote:

Originally Posted by brenzosa

2) Sorry I didn't understand the question,...

Sorry, I thought faster than typed. The question was "How do you call..." However, all other responses describe situation clearly. Thank you and sorry again for the inconvenience.

Quote:

Originally Posted by brenzosa

3) No, I am calling from a different thread -- this used to work before the update so if this is a new requirement, then maybe that's the reason.
However, the call to GetPriceHistoryUTC() succeeds which is running on the same thread that calls CreateEntryOrder() (which subsequently fails)

Here is not any new requirement. The question was asked in order to reveal more details, since the error is related with cross-threading calls.

Nikolay.Gekht · #5 (**permalink**) 08-23-2009, 10:05 PM

While we're trying to reproduce the situation, could you please ensure that:
1) The instances of the FXCore.CoreAut, FXCore.TradeDeskAut and all event sink (if you use it) objects are kept in the static fields of the application class in order to avoid premature releasing by the heap manager. I encountered such problems in environments with the automatic memory management.

2) You use the synchronization for all invocations of the TradeDeskAut class in order to avoid simultaneous calls of the TradeDeskAut interface from the concurrent threads.

Nikolay.Gekht · #6 (**permalink**) 08-25-2009, 11:43 AM

We reproduced the problem with the invalid callee in the groovy. It looks like the VariantByref does not process the output variant values in the correct manner. We will look for the workaround. I'll keep you informed.

Nikolay.Gekht · #7 (**permalink**) 08-26-2009, 11:39 AM

Yes, the version was confirmed.

Below is the code which surely brings the problem in any release of the O2GO

Code:

import org.codehaus.groovy.scriptom.*;
import com.jacob.com.Variant;

Scriptom.inApartment
{
  def core = new ActiveXObject('Order2Go.Core')
  def td = core.CreateTradeDesk('trader')

  println("Connecting...")
  td.Login("user", "password", "http://www.fxcorporate.com/Hosts.jsp", "Demo")
  println("Connected.")
  println(td.IsLoggedIn())

  def offer = td.FindMainTable("offers").Rows.Item(1)
  def account = td.FindMainTable("accounts").Rows.Item(1)

  def accountID = account.CellValue("AccountID")
  def amount = account.CellValue("BaseUnitSize")
  def instrument = offer.CellValue("Instrument")
  def bid = offer.CellValue("Bid")
  def ptsize = offer.CellValue("PointSize")
  def rate = bid - ptsize * 100
  def buy = true

  VariantByref order_id = new VariantByref("")
  VariantByref di = new VariantByref(false)

  println("Create an entry order...")
  td.CreateEntryOrder(accountID, instrument, buy, amount, rate, 0, 0, 0, order_id, di)
  println("Order is created")

  println(order_id.value)
  println(di.value)
}

CreateEntryOrder shall receive parameters order_id and di as VARIANT*. Scriptom sends it as BSTR* and VARIANT_BOOL* datatypes. As far as I can see from their code, they do not support VARIANT* parameters via VariantByref at all. You have to:
- ask Scriptom developers to provide the correct handling of the COM parameter
- choose other language or COM interop tool
- develop a simple COM-based workaround which provides the interface as Scriptom can call (really, this is a couple of hours of work).
BTW, I can develop such workaround for you if you aren't familiar with C++. Please, contact me to discuss this variant if you're interested.

Unfortunately, we cannot adopt the API for the whole heap of the products which has only limited support of the COM interface, so this fix can't be done directly in the API.