I rechecked the current version 1.22 Beta (RC 2) and have two general questions to JIVariant data types:
1.
To convert any data type to a readable String the most suitable method is
String.Valueof(myVariant.getObject())
for all data types I currently deal with, except VT_BSTR, which requires
myVariant.getObjectAsString().getString()
What's the reason to have that annoying JIString type, requiring a type check and special handling everywhere... ?
BTW: I understand this annoyance is out of your scope:
myString = myVariant.getObject(); // Type mismatch: cannot convert from Object to String
myString = "" + myVariant.getObject(); // ok
2.
Why does myVariant.getObjectAsLong() only work on VT_I8 ?
Similar for any other data types ...
I work on ADODB and have to deal with different tables holding data in various types.
Type safety is nice, but I want to be as generic as possible and supply a long variable for any integer data type. Any VT_Ix fits nicely into into a long, doesn't it?
Any nice way to work whithout explicit switches for a dozen data types?
----------------------------------
In my unterstanding the big benefit of Variants is that you should be able to care as little as possible about the current actual data type?
This is not an urgent help topic. All works great (Thanks again, Vikram), it's just a background question.
(I fear, after a final release chances are even less that you will ever change the special JIString behaviour ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Michael,
Good to hear from you again. To answer your questions:-
1. JIString encapsulates 3 types of strings LPCSTR , LPWSTR and BSTR. I did not want to create separate datatypes for each String.
2. Long is VT_I8 in the MS world (64 bit , 32 + 32 LE). I had to keep this for correct mappings between the 2 worlds. If you are certain that what you will receive will be a number, why not use the getObject() and type cast to the necessary class...or have I understood you completely wrong ?
There is still some time for the Final release , I am getting some really strange issues from some users. But for you , since Variants only support BSTR, what I can do is have the getObjectAsString return the Java String directly. But the impact of this needs to be considered (deprecate and remove).
Thanks,
best regards,
Vikram
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> 1. JIString encapsulates 3 types of strings LPCSTR , LPWSTR and BSTR. I did not want to create separate datatypes for each String.
-- Very good ;)
> what I can do is have the getObjectAsString return the Java String directly.
-- That's just consistent, IMO. All the other getObjectAsXxx() refer to a java type Xxx and return that. Consistently, the current method should be named getObjectAsJIString() (if anyone needs it ;)
> But the impact of this needs to be considered (deprecate and remove).
-- That's why i mention it now. After a formal release, it's a definitely different situation.
(using a beta or RC we always risk fix and recompile with a newer version. I'm definitely willing to do so)
> 2. Long is VT_I8 in the MS world
-- I completely agree. (Though there are native types in the MS world as well. Goal of Variant is to handle any data type issues behind the scenes.)
My point was that getObjectAsXxx() should return a data type Xxx, and do it's best to cast or translate the source data. But that's really only convenience. It just leads to ignore those getObjectAsXxx() methods and use getObject() instead.
> There is still some time for the Final release , I am getting some really strange issues from some users
-- I just want to repeat this is really low priority. I appreciate your efforts on j-Interop.
A Great Tool. I'm happy to have found it. Thanks and all the best to you.
Data Fiddler
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Vikram,
I rechecked the current version 1.22 Beta (RC 2) and have two general questions to JIVariant data types:
1.
To convert any data type to a readable String the most suitable method is
String.Valueof(myVariant.getObject())
for all data types I currently deal with, except VT_BSTR, which requires
myVariant.getObjectAsString().getString()
What's the reason to have that annoying JIString type, requiring a type check and special handling everywhere... ?
BTW: I understand this annoyance is out of your scope:
myString = myVariant.getObject(); // Type mismatch: cannot convert from Object to String
myString = "" + myVariant.getObject(); // ok
2.
Why does myVariant.getObjectAsLong() only work on VT_I8 ?
Similar for any other data types ...
I work on ADODB and have to deal with different tables holding data in various types.
Type safety is nice, but I want to be as generic as possible and supply a long variable for any integer data type. Any VT_Ix fits nicely into into a long, doesn't it?
Any nice way to work whithout explicit switches for a dozen data types?
----------------------------------
In my unterstanding the big benefit of Variants is that you should be able to care as little as possible about the current actual data type?
This is not an urgent help topic. All works great (Thanks again, Vikram), it's just a background question.
(I fear, after a final release chances are even less that you will ever change the special JIString behaviour ;)
Hi Michael,
Good to hear from you again. To answer your questions:-
1. JIString encapsulates 3 types of strings LPCSTR , LPWSTR and BSTR. I did not want to create separate datatypes for each String.
2. Long is VT_I8 in the MS world (64 bit , 32 + 32 LE). I had to keep this for correct mappings between the 2 worlds. If you are certain that what you will receive will be a number, why not use the getObject() and type cast to the necessary class...or have I understood you completely wrong ?
There is still some time for the Final release , I am getting some really strange issues from some users. But for you , since Variants only support BSTR, what I can do is have the getObjectAsString return the Java String directly. But the impact of this needs to be considered (deprecate and remove).
Thanks,
best regards,
Vikram
> 1. JIString encapsulates 3 types of strings LPCSTR , LPWSTR and BSTR. I did not want to create separate datatypes for each String.
-- Very good ;)
> what I can do is have the getObjectAsString return the Java String directly.
-- That's just consistent, IMO. All the other getObjectAsXxx() refer to a java type Xxx and return that. Consistently, the current method should be named getObjectAsJIString() (if anyone needs it ;)
> But the impact of this needs to be considered (deprecate and remove).
-- That's why i mention it now. After a formal release, it's a definitely different situation.
(using a beta or RC we always risk fix and recompile with a newer version. I'm definitely willing to do so)
> 2. Long is VT_I8 in the MS world
-- I completely agree. (Though there are native types in the MS world as well. Goal of Variant is to handle any data type issues behind the scenes.)
My point was that getObjectAsXxx() should return a data type Xxx, and do it's best to cast or translate the source data. But that's really only convenience. It just leads to ignore those getObjectAsXxx() methods and use getObject() instead.
> There is still some time for the Final release , I am getting some really strange issues from some users
-- I just want to repeat this is really low priority. I appreciate your efforts on j-Interop.
A Great Tool. I'm happy to have found it. Thanks and all the best to you.
Data Fiddler