LCID for ProxyObject is hardcoded and inconsistent

[matthiasblaesing]

@dhakehurst while working with excel I noted, that I'd need to change th used LCID for the COM invocations. Excel formulas are interpreted locale dependent and here unifying to the english locale helps development. I already overrid the LCID manually and got the expected locale (I'm on german locale, and could now send english formulas).

While looking through the ProxyObject code, I noticed, that you decided to use different default LCIDs:

GetIDsOfNames is using LOCALE_USER_DEFAULT
Invoke is called with LOCALE_SYSTEM_DEFAULT

From my perspective this looks inconsistent. Is there a reason for this?

I'd like to make the locale configurable, my idea:

• add a "getLCID" method to the factory (by default reporting what is today reported as LOCALE_USER_DEFAULT)
• add a "setLCID" method to the factory to be able to override the method
• make ProxyObject use getLCID to determine the LCID to use

The big question: would this be enough and workable or are more complex methods needed? Instead of a fixed LCID I could imaging an LCIDMapper, that takes a target object and java.lang.reflect.Method and returns the LCID to use.

[dhakehurst]

Your suggestion seems fine to me.
I don't remember a reason for picking one LCID over another.

On 16 May 2016 at 21:16, matthiasblaesing notifications@github.com wrote:

@dhakehurst https://github.com/dhakehurst while working with excel I
noted, that I'd need to change th used LCID for the COM invocations. Excel
formulas are interpreted locale dependent and here unifying to the english
locale helps development. I already overrid the LCID manually and got the
expected locale (I'm on german locale, and could now send english formulas).

While looking through the ProxyObject code, I noticed, that you decided to
use different default LCIDs:

GetIDsOfNames is using LOCALE_USER_DEFAULT
Invoke is called with LOCALE_SYSTEM_DEFAULT

From my perspective this looks inconsistent. Is there a reason for this?

I'd like to make the locale configurable, my idea:

• add a "getLCID" method to the factory (by default reporting what is
  today reported as LOCALE_USER_DEFAULT)
• add a "setLCID" method to the factory to be able to override the
  method
• make ProxyObject use getLCID to determine the LCID to use

The big question: would this be enough and workable or are more complex
methods needed? Instead of a fixed LCID I could imaging an LCIDMapper, that
takes a target object and java.lang.reflect.Method and returns the LCID to
use.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#659

[matthiasblaesing]

@dhakehurst I implemented it as described. I pushed a sample branch:

https://github.com/matthiasblaesing/jna/tree/simple_com_thread_2

this branch holds the reintroduction of the simplified threading factory and the LCID change. I'd appreciate it, if you could have a look at it.

[dhakehurst]

I will look when I can, am in the middle of a different project at present,
so it will be a couple of weeks before I can look.

Many thanks for this.

On 23 May 2016 at 20:21, matthiasblaesing notifications@github.com wrote:

@dhakehurst https://github.com/dhakehurst I implemented it as
described. I pushed a sample branch:

https://github.com/matthiasblaesing/jna/tree/simple_com_thread_2

this branch holds the reintroduction of the simplified threading factory
and the LCID change. I'd appreciate it, if you could have a look at it.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#659 (comment)