Re: question - jawin

Robert Hastings wrote:

>I followed the thread to the end, but don't see exactly which types are not
>supported? Roger can you quickly share that info?
>
>
I'm thinking it was referring to interface types; not object types.  The
CoClasses
Interfaces
Modules
Records
Unions

Was this the wrong take on the question?

>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
>>>
>>>
>>
>>
>
>
>