xmlvm-users

[xmlvm-users] Multiple inner classes inheriting from each other lead to a gcc error.

[Brian S. <bri...@go...>]

Hi,

I'm completely new to XMLVM, but due to the external circumstances, I'm
forced to do something rather advanced with it, that is, a crosscompilation
of the Java 6.0 Collections Framework to Objective C. You might argue that
it might be better to use native Objective C collections and write bridges,
but as I need to get the same behaviour as on Java, I thought crosscompiling
would be nice. To make things easier for XMLVM I already used
Retrotranslator to crosscompile the Java 6.0 classes to Java 1.2, and
checked their validity on J2ME. As far as I can tell, my Java classes are
1.2 compilant and working, but crosscompilation to Objective C has its
quirks.

Let me first outline the class layout:

abstract class AbstractList extends AbstractCollection implements List
{
    class Itr implements Iterator
    {
        //...
    }

    class ListItr extends Itr implements ListIterator
    {
        //...
    }

    //..
}

AbstractList has two inner classes and one of those inherits from the other
one. The problem is, that both AbstractList$Itr and AbstractList$ListItr
have the following synthetic member in their bytecode:

final synthetic AbstractList this$0;

Crosscompilation to Objective C works fine and yields two files, each having
the line

@public packagename_AbstractList_* this$0;

but because one class extends the other, I get this error from gcc:

error: duplicate member 'this$0';

One option would be to change my Java code, but the Collections Framework
has at least 4 Classes with multiple (even more than two) inner classes
which inherit from each other. So I guess this case should somehow be
handled by the XMLVM crosscompiler, but I'm completely unsure how this would
be done. When emitting the interface in xmlvm2objc.xsl, we would need to
check if there is any superclass which is also an inner class, thus having a
this$0 field. I think this might be beyond the complexity of what should be
done here, isn't it?

Im happy about any advice.

With best regards,
Brian

Re: [xmlvm-users] Multiple inner classes inheriting from each other lead to a gcc error.

[Arno P. <ar...@pu...>]

Brian,

you are certainly pushing XMLVM to the limits. I do agree with you that 
a native Objective-C version would be the way to go. But one can 
certainly argue that there is a bug because we cannot handle the code 
you try to cross-compile.

Can you please do me a favor and generate a small, self-contained 
example that demonstrates the problem? That would be the easiest for me 
to investigate and (hopefully) fix the bug.

Arno


Brian Schimmel wrote:
> Hi,
> 
> I'm completely new to XMLVM, but due to the external circumstances, I'm 
> forced to do something rather advanced with it, that is, a 
> crosscompilation of the Java 6.0 Collections Framework to Objective C. 
> You might argue that it might be better to use native Objective C 
> collections and write bridges, but as I need to get the same behaviour 
> as on Java, I thought crosscompiling would be nice. To make things 
> easier for XMLVM I already used Retrotranslator to crosscompile the Java 
> 6.0 classes to Java 1.2, and checked their validity on J2ME. As far as I 
> can tell, my Java classes are 1.2 compilant and working, but 
> crosscompilation to Objective C has its quirks.
> 
> Let me first outline the class layout:
> 
> abstract class AbstractList extends AbstractCollection implements List
> {
>     class Itr implements Iterator
>     {
>         //...
>     }
> 
>     class ListItr extends Itr implements ListIterator
>     {
>         //...
>     }
> 
>     //..
> }
> 
> AbstractList has two inner classes and one of those inherits from the 
> other one. The problem is, that both AbstractList$Itr and 
> AbstractList$ListItr have the following synthetic member in their bytecode:
> 
> final synthetic AbstractList this$0;
> 
> Crosscompilation to Objective C works fine and yields two files, each 
> having the line
> 
> @public packagename_AbstractList_* this$0;
> 
> but because one class extends the other, I get this error from gcc:
> 
> error: duplicate member 'this$0';
> 
> One option would be to change my Java code, but the Collections 
> Framework has at least 4 Classes with multiple (even more than two) 
> inner classes which inherit from each other. So I guess this case should 
> somehow be handled by the XMLVM crosscompiler, but I'm completely unsure 
> how this would be done. When emitting the interface in xmlvm2objc.xsl, 
> we would need to check if there is any superclass which is also an inner 
> class, thus having a this$0 field. I think this might be beyond the 
> complexity of what should be done here, isn't it?
> 
> Im happy about any advice.
> 
> With best regards,
> Brian
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Multiple inner classes inheriting from each other lead to a gcc error.

[Arno P. <ar...@pu...>]

Never mind my last message. I know the source of the problem. Here is an 
example that will break XMLVM:


class TestBase {
     public int x;
}


public class TestDerived extends TestBase {
     public int x;
}

In Objective-C you can only have one member of the same name along an 
inheritance path. Kind of makes sense when you consider that Objective-C 
is a dynamically typed language.

I'm not sure what is the best way to deal with this. Name mangling comes 
to mind (include the class name in the member's name), but perhaps there 
is an easier way.

Arno



Brian Schimmel wrote:
> Hi,
> 
> I'm completely new to XMLVM, but due to the external circumstances, I'm 
> forced to do something rather advanced with it, that is, a 
> crosscompilation of the Java 6.0 Collections Framework to Objective C. 
> You might argue that it might be better to use native Objective C 
> collections and write bridges, but as I need to get the same behaviour 
> as on Java, I thought crosscompiling would be nice. To make things 
> easier for XMLVM I already used Retrotranslator to crosscompile the Java 
> 6.0 classes to Java 1.2, and checked their validity on J2ME. As far as I 
> can tell, my Java classes are 1.2 compilant and working, but 
> crosscompilation to Objective C has its quirks.
> 
> Let me first outline the class layout:
> 
> abstract class AbstractList extends AbstractCollection implements List
> {
>     class Itr implements Iterator
>     {
>         //...
>     }
> 
>     class ListItr extends Itr implements ListIterator
>     {
>         //...
>     }
> 
>     //..
> }
> 
> AbstractList has two inner classes and one of those inherits from the 
> other one. The problem is, that both AbstractList$Itr and 
> AbstractList$ListItr have the following synthetic member in their bytecode:
> 
> final synthetic AbstractList this$0;
> 
> Crosscompilation to Objective C works fine and yields two files, each 
> having the line
> 
> @public packagename_AbstractList_* this$0;
> 
> but because one class extends the other, I get this error from gcc:
> 
> error: duplicate member 'this$0';
> 
> One option would be to change my Java code, but the Collections 
> Framework has at least 4 Classes with multiple (even more than two) 
> inner classes which inherit from each other. So I guess this case should 
> somehow be handled by the XMLVM crosscompiler, but I'm completely unsure 
> how this would be done. When emitting the interface in xmlvm2objc.xsl, 
> we would need to check if there is any superclass which is also an inner 
> class, thus having a this$0 field. I think this might be beyond the 
> complexity of what should be done here, isn't it?
> 
> Im happy about any advice.
> 
> With best regards,
> Brian
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Multiple inner classes inheriting from each other lead to a gcc error.

[Brian S. <bri...@go...>]

Hi Arno,
you're right, the problem is not specific to internal classes. I was unsure
if in the example you provided those two fields called "x" are the same ones
or different ones which just happen to have the same name. I extended the
test so that it showed me what's the expected behavior on Java:

public class Test
{
    public static void main(String[] args) {
        TestDerived b = new TestDerived();
        b.setXbase(1);
        b.setXderived(2);

        System.out.println("b.x                (should be 2): " + b.x);
        System.out.println("b.getXbase()       (should be 1): " +
b.getXbase());
        System.out.println("b.getXderived()    (should be 2): " +
b.getXderived());
        System.out.println("((TestBase)b).x    (should be 1): " +
((TestBase)b).x);
        System.out.println("((TestDerived)b).x (should be 2): " +
((TestDerived)b).x);
    }
}

class TestBase {
    public int x;

    int getXbase()
    {
        return x;
    }

    void setXbase(int x)
    {
        this.x = x;
    }
}

class TestDerived extends TestBase
{
    public int x;

    int getXderived()
    {
        return x;
    }

    void setXderived(int x)
    {
        this.x = x;
    }
}

So we should try to find a solution that ensures the same behavior on
Objective C, and the code above might be useful the check it.

On the other hand, I don't know if anybody would seriously implement
something like that, that is, using two fields with the same name and rely
on then being handled independantly.

In my case (the multiple inner classes) the both fields called "this$0" may
be independant fields, but they are final and guarenteed to contain a
reference to the same object, so it does not matter to me if XMLVM somehow
confuses the two.

By the way, I guess the same problem might pop up for other target platforms
too.

Brian


2009/9/9 Arno Puder <ar...@pu...>

>
> Never mind my last message. I know the source of the problem. Here is an
> example that will break XMLVM:
>
>
> class TestBase {
>     public int x;
> }
>
>
> public class TestDerived extends TestBase {
>     public int x;
> }
>
> In Objective-C you can only have one member of the same name along an
> inheritance path. Kind of makes sense when you consider that Objective-C
> is a dynamically typed language.
>
> I'm not sure what is the best way to deal with this. Name mangling comes
> to mind (include the class name in the member's name), but perhaps there
> is an easier way.
>
> Arno
>
>
>
> Brian Schimmel wrote:
> > Hi,
> >
> > I'm completely new to XMLVM, but due to the external circumstances, I'm
> > forced to do something rather advanced with it, that is, a
> > crosscompilation of the Java 6.0 Collections Framework to Objective C.
> > You might argue that it might be better to use native Objective C
> > collections and write bridges, but as I need to get the same behaviour
> > as on Java, I thought crosscompiling would be nice. To make things
> > easier for XMLVM I already used Retrotranslator to crosscompile the Java
> > 6.0 classes to Java 1.2, and checked their validity on J2ME. As far as I
> > can tell, my Java classes are 1.2 compilant and working, but
> > crosscompilation to Objective C has its quirks.
> >
> > Let me first outline the class layout:
> >
> > abstract class AbstractList extends AbstractCollection implements List
> > {
> >     class Itr implements Iterator
> >     {
> >         //...
> >     }
> >
> >     class ListItr extends Itr implements ListIterator
> >     {
> >         //...
> >     }
> >
> >     //..
> > }
> >
> > AbstractList has two inner classes and one of those inherits from the
> > other one. The problem is, that both AbstractList$Itr and
> > AbstractList$ListItr have the following synthetic member in their
> bytecode:
> >
> > final synthetic AbstractList this$0;
> >
> > Crosscompilation to Objective C works fine and yields two files, each
> > having the line
> >
> > @public packagename_AbstractList_* this$0;
> >
> > but because one class extends the other, I get this error from gcc:
> >
> > error: duplicate member 'this$0';
> >
> > One option would be to change my Java code, but the Collections
> > Framework has at least 4 Classes with multiple (even more than two)
> > inner classes which inherit from each other. So I guess this case should
> > somehow be handled by the XMLVM crosscompiler, but I'm completely unsure
> > how this would be done. When emitting the interface in xmlvm2objc.xsl,
> > we would need to check if there is any superclass which is also an inner
> > class, thus having a this$0 field. I think this might be beyond the
> > complexity of what should be done here, isn't it?
> >
> > Im happy about any advice.
> >
> > With best regards,
> > Brian
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Multiple inner classes inheriting from each other lead to a gcc error.

[Arno P. <ar...@pu...>]

actually, it gets even more complicated, because you can also write 
super.x. In this case the inheritance hierarchy is searched for the next 
occurrence of x (and yes, they are distinct members).

I think I have an idea on how to solve this. Need to brood about it a 
little more...

Arno


Brian Schimmel wrote:
> Hi Arno,
> you're right, the problem is not specific to internal classes. I was 
> unsure if in the example you provided those two fields called "x" are 
> the same ones or different ones which just happen to have the same name. 
> I extended the test so that it showed me what's the expected behavior on 
> Java:
> 
> public class Test
> {
>     public static void main(String[] args) {
>         TestDerived b = new TestDerived();
>         b.setXbase(1);
>         b.setXderived(2);
>        
>         System.out.println("b.x                (should be 2): " + b.x);
>         System.out.println("b.getXbase()       (should be 1): " + 
> b.getXbase());
>         System.out.println("b.getXderived()    (should be 2): " + 
> b.getXderived());
>         System.out.println("((TestBase)b).x    (should be 1): " + 
> ((TestBase)b).x);
>         System.out.println("((TestDerived)b).x (should be 2): " + 
> ((TestDerived)b).x);
>     }
> }
> 
> class TestBase {
>     public int x;
>    
>     int getXbase()
>     {
>         return x;
>     }
>    
>     void setXbase(int x)
>     {
>         this.x = x;
>     }
> }
> 
> class TestDerived extends TestBase
> {
>     public int x;
>    
>     int getXderived()
>     {
>         return x;
>     }
>    
>     void setXderived(int x)
>     {
>         this.x = x;
>     }
> }
> 
> So we should try to find a solution that ensures the same behavior on 
> Objective C, and the code above might be useful the check it.
> 
> On the other hand, I don't know if anybody would seriously implement 
> something like that, that is, using two fields with the same name and 
> rely on then being handled independantly.
> 
> In my case (the multiple inner classes) the both fields called "this$0" 
> may be independant fields, but they are final and guarenteed to contain 
> a reference to the same object, so it does not matter to me if XMLVM 
> somehow confuses the two.
> 
> By the way, I guess the same problem might pop up for other target 
> platforms too.
> 
> Brian
> 
> 
> 2009/9/9 Arno Puder <ar...@pu... <mailto:ar...@pu...>>
> 
> 
>     Never mind my last message. I know the source of the problem. Here is an
>     example that will break XMLVM:
> 
> 
>     class TestBase {
>         public int x;
>     }
> 
> 
>     public class TestDerived extends TestBase {
>         public int x;
>     }
> 
>     In Objective-C you can only have one member of the same name along an
>     inheritance path. Kind of makes sense when you consider that Objective-C
>     is a dynamically typed language.
> 
>     I'm not sure what is the best way to deal with this. Name mangling comes
>     to mind (include the class name in the member's name), but perhaps there
>     is an easier way.
> 
>     Arno
> 
> 
> 
>     Brian Schimmel wrote:
>      > Hi,
>      >
>      > I'm completely new to XMLVM, but due to the external
>     circumstances, I'm
>      > forced to do something rather advanced with it, that is, a
>      > crosscompilation of the Java 6.0 Collections Framework to
>     Objective C.
>      > You might argue that it might be better to use native Objective C
>      > collections and write bridges, but as I need to get the same
>     behaviour
>      > as on Java, I thought crosscompiling would be nice. To make things
>      > easier for XMLVM I already used Retrotranslator to crosscompile
>     the Java
>      > 6.0 classes to Java 1.2, and checked their validity on J2ME. As
>     far as I
>      > can tell, my Java classes are 1.2 compilant and working, but
>      > crosscompilation to Objective C has its quirks.
>      >
>      > Let me first outline the class layout:
>      >
>      > abstract class AbstractList extends AbstractCollection implements
>     List
>      > {
>      >     class Itr implements Iterator
>      >     {
>      >         //...
>      >     }
>      >
>      >     class ListItr extends Itr implements ListIterator
>      >     {
>      >         //...
>      >     }
>      >
>      >     //..
>      > }
>      >
>      > AbstractList has two inner classes and one of those inherits from the
>      > other one. The problem is, that both AbstractList$Itr and
>      > AbstractList$ListItr have the following synthetic member in their
>     bytecode:
>      >
>      > final synthetic AbstractList this$0;
>      >
>      > Crosscompilation to Objective C works fine and yields two files, each
>      > having the line
>      >
>      > @public packagename_AbstractList_* this$0;
>      >
>      > but because one class extends the other, I get this error from gcc:
>      >
>      > error: duplicate member 'this$0';
>      >
>      > One option would be to change my Java code, but the Collections
>      > Framework has at least 4 Classes with multiple (even more than two)
>      > inner classes which inherit from each other. So I guess this case
>     should
>      > somehow be handled by the XMLVM crosscompiler, but I'm completely
>     unsure
>      > how this would be done. When emitting the interface in
>     xmlvm2objc.xsl,
>      > we would need to check if there is any superclass which is also
>     an inner
>      > class, thus having a this$0 field. I think this might be beyond the
>      > complexity of what should be done here, isn't it?
>      >
>      > Im happy about any advice.
>      >
>      > With best regards,
>      > Brian
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      >
>     ------------------------------------------------------------------------------
>      > Let Crystal Reports handle the reporting - Free Crystal Reports
>     2008 30-Day
>      > trial. Simplify your report design, integration and deployment -
>     and focus on
>      > what you do best, core application coding. Discover what's new with
>      > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      > _______________________________________________
>      > xmlvm-users mailing list
>      > xml...@li...
>     <mailto:xml...@li...>
>      > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> 
>     ------------------------------------------------------------------------------
>     Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>     30-Day
>     trial. Simplify your report design, integration and deployment - and
>     focus on
>     what you do best, core application coding. Discover what's new with
>     Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>     _______________________________________________
>     xmlvm-users mailing list
>     xml...@li...
>     <mailto:xml...@li...>
>     https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> 
> 

Re: [xmlvm-users] Multiple inner classes inheriting from each other lead to a gcc error.

[Arno P. <ar...@pu...>]

Brian,

I just committed a patch that should hopefully fix the bug you've 
encountered. Basically I generate getter/setter methods for instance 
members and use name mangling for the declaration of the instance member 
to avoid naming conflict.

Give it a try and let me know if this works now.

Arno


Brian Schimmel wrote:
> Hi Arno,
> you're right, the problem is not specific to internal classes. I was 
> unsure if in the example you provided those two fields called "x" are 
> the same ones or different ones which just happen to have the same name. 
> I extended the test so that it showed me what's the expected behavior on 
> Java:
> 
> public class Test
> {
>     public static void main(String[] args) {
>         TestDerived b = new TestDerived();
>         b.setXbase(1);
>         b.setXderived(2);
>        
>         System.out.println("b.x                (should be 2): " + b.x);
>         System.out.println("b.getXbase()       (should be 1): " + 
> b.getXbase());
>         System.out.println("b.getXderived()    (should be 2): " + 
> b.getXderived());
>         System.out.println("((TestBase)b).x    (should be 1): " + 
> ((TestBase)b).x);
>         System.out.println("((TestDerived)b).x (should be 2): " + 
> ((TestDerived)b).x);
>     }
> }
> 
> class TestBase {
>     public int x;
>    
>     int getXbase()
>     {
>         return x;
>     }
>    
>     void setXbase(int x)
>     {
>         this.x = x;
>     }
> }
> 
> class TestDerived extends TestBase
> {
>     public int x;
>    
>     int getXderived()
>     {
>         return x;
>     }
>    
>     void setXderived(int x)
>     {
>         this.x = x;
>     }
> }
> 
> So we should try to find a solution that ensures the same behavior on 
> Objective C, and the code above might be useful the check it.
> 
> On the other hand, I don't know if anybody would seriously implement 
> something like that, that is, using two fields with the same name and 
> rely on then being handled independantly.
> 
> In my case (the multiple inner classes) the both fields called "this$0" 
> may be independant fields, but they are final and guarenteed to contain 
> a reference to the same object, so it does not matter to me if XMLVM 
> somehow confuses the two.
> 
> By the way, I guess the same problem might pop up for other target 
> platforms too.
> 
> Brian
> 
> 
> 2009/9/9 Arno Puder <ar...@pu... <mailto:ar...@pu...>>
> 
> 
>     Never mind my last message. I know the source of the problem. Here is an
>     example that will break XMLVM:
> 
> 
>     class TestBase {
>         public int x;
>     }
> 
> 
>     public class TestDerived extends TestBase {
>         public int x;
>     }
> 
>     In Objective-C you can only have one member of the same name along an
>     inheritance path. Kind of makes sense when you consider that Objective-C
>     is a dynamically typed language.
> 
>     I'm not sure what is the best way to deal with this. Name mangling comes
>     to mind (include the class name in the member's name), but perhaps there
>     is an easier way.
> 
>     Arno
> 
> 
> 
>     Brian Schimmel wrote:
>      > Hi,
>      >
>      > I'm completely new to XMLVM, but due to the external
>     circumstances, I'm
>      > forced to do something rather advanced with it, that is, a
>      > crosscompilation of the Java 6.0 Collections Framework to
>     Objective C.
>      > You might argue that it might be better to use native Objective C
>      > collections and write bridges, but as I need to get the same
>     behaviour
>      > as on Java, I thought crosscompiling would be nice. To make things
>      > easier for XMLVM I already used Retrotranslator to crosscompile
>     the Java
>      > 6.0 classes to Java 1.2, and checked their validity on J2ME. As
>     far as I
>      > can tell, my Java classes are 1.2 compilant and working, but
>      > crosscompilation to Objective C has its quirks.
>      >
>      > Let me first outline the class layout:
>      >
>      > abstract class AbstractList extends AbstractCollection implements
>     List
>      > {
>      >     class Itr implements Iterator
>      >     {
>      >         //...
>      >     }
>      >
>      >     class ListItr extends Itr implements ListIterator
>      >     {
>      >         //...
>      >     }
>      >
>      >     //..
>      > }
>      >
>      > AbstractList has two inner classes and one of those inherits from the
>      > other one. The problem is, that both AbstractList$Itr and
>      > AbstractList$ListItr have the following synthetic member in their
>     bytecode:
>      >
>      > final synthetic AbstractList this$0;
>      >
>      > Crosscompilation to Objective C works fine and yields two files, each
>      > having the line
>      >
>      > @public packagename_AbstractList_* this$0;
>      >
>      > but because one class extends the other, I get this error from gcc:
>      >
>      > error: duplicate member 'this$0';
>      >
>      > One option would be to change my Java code, but the Collections
>      > Framework has at least 4 Classes with multiple (even more than two)
>      > inner classes which inherit from each other. So I guess this case
>     should
>      > somehow be handled by the XMLVM crosscompiler, but I'm completely
>     unsure
>      > how this would be done. When emitting the interface in
>     xmlvm2objc.xsl,
>      > we would need to check if there is any superclass which is also
>     an inner
>      > class, thus having a this$0 field. I think this might be beyond the
>      > complexity of what should be done here, isn't it?
>      >
>      > Im happy about any advice.
>      >
>      > With best regards,
>      > Brian
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      >
>     ------------------------------------------------------------------------------
>      > Let Crystal Reports handle the reporting - Free Crystal Reports
>     2008 30-Day
>      > trial. Simplify your report design, integration and deployment -
>     and focus on
>      > what you do best, core application coding. Discover what's new with
>      > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      > _______________________________________________
>      > xmlvm-users mailing list
>      > xml...@li...
>     <mailto:xml...@li...>
>      > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> 
>     ------------------------------------------------------------------------------
>     Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>     30-Day
>     trial. Simplify your report design, integration and deployment - and
>     focus on
>     what you do best, core application coding. Discover what's new with
>     Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>     _______________________________________________
>     xmlvm-users mailing list
>     xml...@li...
>     <mailto:xml...@li...>
>     https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> 
>