Re: [Fwd: jawin2.0alpha1 issues]

Ahh sorry for not looking at the sourceforge message list.

The @name is a problem.  The greater problem I believe is the otherwise
should be eliminated if all types are handled.  The otherwise ought to
say "type not supported" as an ugly 'for now'. Do you know what type got
to it?

The second parameter will be wrapped.  Thanks.

Also I cleaned up the compile warnings of org_jawin_win32_ITypeInfo.cpp
about order of operations involving shifts.  Particularly Variant.cyVal
and Variant.pcyVal.  Don't have a test case yet.  If this fixes or is
needed by anyone, let me know.


Morten Andersen wrote:

> Hi Michael,
>
> I am not really an expert on the transformations in the Type Browser, so
> I am forwarding your message to the Jawin mailing list.
>
> Thanks for making us aware of this.
>
>
> Roger and Josh, you are the XSLT experts, if you can find time for it,
> can you verify whether Michael is correct about these issues.
>
> /Morten
>
> -------- Original Message --------
> Subject: jawin2.0alpha1 issues
> Date: Wed, 25 May 2005 23:48:14 -0700
> From: madkins <[email protected]>
> To: [email protected]
> CC: [email protected]
>
> Message body follows:
>
>
> Hi Martin,
>
> I think I've found a few issues with the latest alpha release of
> jawin in relation to the type browser:
>
> dispatch.xsl
> -----------------
> 1) in the "wrap-primitive" template, in the otherwise section,
> you are using @name instead of $name. This causes a bug
> where on the generated set (put) for a variant array property,
> the code that is generated is:
> Put( "ParamName", ParamName, value )
> Instead of:
> Put( "ParamName", index, value )
>
> Also in the "CallPropertyPut" template,
> where there are 2 parameters,
> parameter 2 should be wrapped up the same way as
> parameter 1.
>
>
> TypeParser.java
> -------------------------
> In buildUserDefinedDescription,
> for case TYPEKIND.TKIND_ENUM:
> in addition to calling node.setTypeConfig I believe you need to
> follow this with a call to:
> node.setTypeName and specify that the typeName is "int" for
> enum parameters. Otherwise these parameters have a blank
> type name and so no type is output during code generation.
>
>
> Anyway, just wanted to pass this on to you. If you want any
> further information, just let me know.
>
> Thanks,
> Michael.
>
>
>
> --
> This message has been sent to you, a registered SourceForge.net user,
> by another site user, through the SourceForge.net site.  This message
> has been delivered to your SourceForge.net mail alias.  You may reply
> to this message using the "Reply" feature of your email client, or
> using the messaging facility of SourceForge.net at:
> https://sourceforge.net/sendmessage.php?touser=1284942
>