Re: question - jawin

I followed the thread to the end, but don't see exactly which types are not
supported? Roger can you quickly share that info?

Thanks,
Robert

-----Original Message-----
From: Discussion of Java/Win32/COM integration with Jawin
[mailto:[email protected]] On Behalf Of Roger I Martin PhD
Sent: Wednesday, September 21, 2005 6:40 AM
To: [email protected]
Subject: Re: [JAWIN] question - jawin

Josh Passenger wrote:

> Hi Louis,
>
> I am cc'ing this reply to the list which you probably should join if you
> decide to use jawin in anger =]
>
> It would seem that the type browser is perhaps not generating code for
> classes, delegates and interfaces.
>
> I am not quite sure why as I barely understand COM and only really got
> involed in Jawin from an interest in code generation and Swing
> programming.
>
> Roger, is there some reason why we are not generating code for these
> types?

There is no marshaling I can find for these.  The new nio version will.
Progress is coming along but it is immense and I'm wading thru  lots of
problems part time.  The classes gets into vtables and virtual functions
which act as callbacks.  What this means is the native side must be able
to call these Java functions rather than the other way around.  I
haven't found in Jawin or written my own generic mapping of the vtables
to a C function that then in turn calls the Java functions.  I could
readily make the xslts generate the Java side but I don't see how to
make the current Jawin marshaling use them.

>
> The way the type browser works is that it calls a native library
> (written by
> Roger) to read the type info from the type library and then creates an
> XML
> intermediary file which is then styled using XSL stylesheets into any
> code
> you want, for now, Jawin Java wrapper classes.
>
> Two distinct possibilities exist:
>
> 1) These types are not being extracted from the native type library

They are extracted. This part is basically finished.

> 2) The types are extracted but no XSL stylesheets or configuration
> exists to
> support their transformation.

There appears to be no marshaling available.  If someone can write them
in Jawin marshaling by hand we can readily generate them by the xslt.  I
just don't know of what will do the marshaling.

>
> The type browser is pretty configurable, check out:
>
>
http://cvs.sourceforge.net/viewcvs.py/jawinproject/jawin/config/codegenconfi
g.xml?rev=1.2&view=markup
>
>
> and you can see that interfaces are supported but classes and
> delegates are
> not (coclasses are).
>
> Also check out the other config files:
>
> http://cvs.sourceforge.net/viewcvs.py/jawinproject/jawin/config/#dirlist
>
> For an idea of how the whole editor hooks together.
>
> Adding support for these new types might involve some native code
> changes to
> the extractor, perhaps some changes to the XML serializer and definitely
> some new XSL stylesheets.
>
> To write the xsl stylesheets, you have to have some idea what java
> code you
> want to generate and obviously know some rudimentary xsl.
>
> Hope this helps, we welcome contributions so if you want to add some new
> functionality, just yell onto the list and someone might add you as a
> developer with CVS commit if thats what you want,
>
> Regards,
>
> Josh
>
>>
>> Josh  -   I'm in desperate need of talking to someone about Jawin
>> functionality.   In the typebrowser, I recently ran Code Generation on 2
>> different COM dlls that I needed to wrap with JNI, but unfortunately
>> only
>> about 70% of the dll functions had stubs created for them.
>>
>> Is there someone that may be able to explain to me why some stubs are
>> missing?      I get access to 30% more functionality when calling the
>> Libraries from Visual Studio .Net as opposed to calling these same
>> functions from within JBuilder.
>>
>> If someone could at least confirm that I need to manually write the
>> JNI for
>> the missing stubs, then that is ok.   But I just need to know that
>> I'm not
>> headed down a dead-end street...
>>
>> If you can help, or know someone who can, I'd appreciate it.   I'd be
>> happy
>> to send the dll files to them to try to figure out why some of the stubs
>> are not generated.
>>
>> I know exactly which methods from the COM dlls that are not
>> accessible from
>> within JBuilder  (see below xx  -  red "highlights")
>>
>> Thanks,
>>
>> Lou Morgan
>>
>>
>>
>>
>>
>> for instance....  below with the xx are missing after running Code
>> Generation on GbxCtrl.dll
>>
>>      GbxCtrl.dll
>>
>>
>>
>>
>>      GBXCTRLLib
>>      ( C# access to API )
>>
>>       interface  Bbx
>>       class  BbxClass xx
>>       class  BBxEventQClass xx
>>       class  BbxMsgClass xx
>>       class  GbxClass xx
>>       delegate  IBbxEvents_BBxEvent_BBxMsgEventHandler xx
>>       delegate  IBbxEvents_BBxEventEventHandler xx
>>       interface  IBbxEvents_Event xx
>>       class  IBbxEvents_SinkHelper xx
>>       interface  BBxEventQ
>>       interface  BbxMsg
>>       enum  BbxMsgId
>>       interface  Gbx
>>       enum  GbxDestId
>>       enum  GbxExchngId
>>       enum  GbxMsgId
>>       enum  GbxOrderMode
>>       enum  GbxOrderSide
>>       enum  GbxOrderTif
>>       enum  GbxOrderType
>>       interface  IBbx
>>       interface  IBbxEventQ
>>       interface  IBbxEvents
>>       interface  IBbxMsg
>>       interface  IEventQDoCallback
>>       interface  IGbx
>>       enum  __MIDL__MIDL_itf_GbxCtrl_0000_0001
>>       enum  __MIDL__MIDL_itf_GbxCtrl_0000_0002
>>       enum  __MIDL__MIDL_itf_GbxCtrl_0000_0003
>>       enum  __MIDL__MIDL_itf_GbxCtrl_0000_0004
>>       enum  __MIDL__MIDL_itf_GbxCtrl_0000_0005
>>       enum  __MIDL__MIDL_itf_GbxCtrl_0000_0006
>>       enum  __MIDL__MIDL_itf_GbxCtrl_0000_0007
>>       enum  __MIDL__MIDL_itf_GbxCtrl_0000_0008
>
>