Re: Variant arguments & com function calls

Hi Alex

Alex Kotchnev wrote:

> I also wanted to suggest some improvements to the Variant class. In general, now when I 
> have to use a Variant, first I have to create a new instance with "new", and 
> then assign the appropriate value using the appropriate setter method. I was wondering, 
> if in general, a few 'convenience' constructors could be added in which the constructor 
> arguments would be assigned into the appropriate value of the Variant instance e.g. new 
> Variant(int intValue) assigns the boolValue to the bool value in the class. Certainly, it 
> wouldn't make any to creae a constructor for each possible field in invariant, but it 
> would be nice if there is one for some.

You are right, the Variant class is up for a refactoring. Besides the
constructors you suggest, I have thought about decreasing the
memory-footprint of the instances of this class. Today it contains a lot
of fields each taking up memory, so I have considered refactoring it to
use an internal long and an one Object reference, and then let the
getters and setters for the simple types convert to an from this long
(eg. the java.lang.Double contains the doubleToRawLongBits() and
longBitsToDouble(), and so on for the other simple types). All
non-simple values, could be referenced by the single Object field.

But I have to find time for this refactoring, and I also know that some
of the native code for the TypeBrowser depends on the Variant layout as
it is today, so one have to be careful to change it.

> However, when I generated the Java classes using the com browser ( I generated 
> them with the release version, I am not sure if the cvs version would generate 
> differently)

I don't think there is much difference for the exact scenario you mention.

> I noticed that there were a few Win32 structures & others in cvs - should 
> generated code for MS Office to CVS ? In general, the generation worked pretty 
> smoothly with the release version however, I had to fix a few methods and arguments 
> that didn't compile. I understand that in the general case, the code generation 
> should work flawlessly; however, for newcomers to the project it will certainly add 
> value to have a generated and working interface to MS Office).

Yes that would be great, the "stubs"-folder in the root of the CVS
version is exactly for such donated code (whether handwritten or
generated and tested from the TypeBrowser)). So if you get it to work,
we would be pleased if you donated the stubs to the project.

> However, I am quite impressed with Jawin at this point and would like to use 
> the opportunity as a springboard for learning more on invoking other (non-Com 
> based) native win32 functionality from Java.

That one is a little bit tougher, as the marshalling instructions for
Win32 calls are pretty badly documented pt.

> I read over the extended how-tos and it is starting to make a lot more sense ( 
> I was even thinking of going over a Win32 programming book that I have and 
> implementing the examples in Java / Jawin).

Cool, feel free to ask if you stumbles into problems.

Best Regards
Morten