Re: cvs tagged?

Quite alright and you have great skills as a project organizer:-)

The going is slow at ties with a few jumps of success every now and
then.  Reading MSDN docs is a headache.  I've seen more than my share of
the catastrophic failure exception:-/
I too believe the new marshaling should be brand new with completely
different design.  For example, I'm making variants right inside of nio
Buffers for each individual argument.  Then stack them seamlessly with
direct memory in the invoke's DISPARAMS structure.  No need to send
instructions or casing on var types. The TypeBrowser takes care of this
decision and leaves the code running fast and seamless.  No peeling a
linear stream of bytes any more. Hardly call it marshalling:-)  If the
COM creates the argument all the others are independent and unaffected.
COM can also change an arguments size and it will be less of a problem(
The only problem there is a new Buffer needs to be made).

Also considering making multiple invokes to take care of the different
return types efficiently.

I'm experimenting with JAWT right now so that the Visual COM controls I
wish to test with can be used without the catastrophic failure exception
happening.

For events I need to test having a Jawin native callback function
satisfy the vtable but I'm unsure yet.

More later and best regards,
Roger

Morten Andersen wrote:

> Hi Roger,
>
> Just a quick mail before I head to bed, I will try to take part in your
> refactorings over the weekend hopefully. Sorry for not having commented
> on any of your ideas before this.
>
> Roger I Martin PhD wrote:
>
>> Is cvs tagged for the latest release?
>>
>
> Yep. I tagged it with "jawin_2_0_a1" as stated in the release notes:
> http://sourceforge.net/project/shownotes.php?release_id=315102
>
>> It would be helpful if changes I'm making could be pushed in for
>> discussion but I don't want it difficult to get the current version.
>>
>
> Yes I aggree in that. And I have been wanting to mail you of my view of
> the best way to change the marshalling in a (maybe) destructive way:
> 1) Since we increased the major number (1 -> 2), and we still haven't
> released  a non-alpha in the 2.x series, I think that nobody can blame
> us for messing with new functionality.
> 2) So I think your changes should go into HEAD. And since we have a tag
> immediately before the changes, we can always make a branch at that if
> anybody wants to work on the old marshalling (I assume this is what you
> wanted too?)
>
> And about the copy of jawin.rc.ori to jawin.rc: If I remember correctly,
> this is something I introduced to include Win32 version information into
> the Jawin.dll file (look at the properties for it in explorer, and you
> will be able to see the build and version information for the exact
> release). The copy of the jawin.rc.ori to jawin.rc is basically a
> filtering copy where version information in it is replaced with version
> information from global.properties (the same version information that
> goes into the manifest file in the jar). I hope this doesn't give you to
> much problems (I mostly build using the "ant -Dcpp.compile.enabled=true"
> line, and seldom using the GUI, but your build-preferences may be
> different).
>
> Best Regards and good to see that you have found time and energy to work
> on the much discussed marshalling.
> Morten
>