Fwd: [Kde-java] A curious problem with QSqlCursor

[David Goodenough]

On Tuesday 26 October 2004 10:14, Richard Dale wrote:
> On Monday 25 October 2004 18:37, David Goodenough wrote:
> > On Monday 25 October 2004 11:10, David Goodenough wrote:
> > > Looking at this further, when you create a java QSqlCursor this results
> > > in a C++ QSqlCursorBridge which is derived from the C++ QSqlCursor
> > > being created.  The calculateField method is not declared as part of
> > > that sub-classing, so it never gets called.  The QSqlCursorBridge class
> > > should include this method, and then that method should call the
> > > calculateField method in the java class, taking care as with the polish
> > > method not to have a recursion problem.  The default method for this
> > > class should call the C++ default method.
> > >
> > > Now I presume that these callbacks, like polish, are declared by the
> > > code that generates these bridge classes based on something like
> > > their being virtual?  If so I am confused why the virtual methods of
> > > QSqlCursor are not being processed, as calculateField is virtual (at
> > > least in the the version of qsqlcursor.h that is installed on my
> > > machine. The only difference I can see is that polish is a public
> > > method, while calculateField is a protected method.  However I get lost
> > > reading Perl scripts, and as kalyptus is a Perl script I got well and
> > > truely lost.
> > >
> > > David
> >
> > I have done some further work, and when I run kalyptus (from HEAD)
> > against the Qt 3.3 headers, I do get a calculateField method in the
> > QSqlCursor implementation.  Perhaps all that is needed is to run
> > kalyptus against all the headers?
>
> The kalyptus in the HEAD branch doesn't add callbacks for methods like
> QSqlCursor.calculateField() either. With limited time I can't work on the
> next version of the java bindings at the same time as the current ones to
> get anything working for KDE 3.4.
>
> Here is how the current virtual method callbacks are generated and
> implemented. In kalyptusCxxToJNI.pm look for 'sub virtualMethodCallbacks'.
> The perl code to generate void method callbacks like polish() is here:
>
>    } elsif( $m->{ReturnType} eq 'void' and $#argTypeList eq -1) {
>     $jbridgeCode .= "\tvoid $name() {\n";
>     $jbridgeCode .= "\t\tif
> (!QtSupport::voidDelegate(this,\"$qobjectType\", \"$name\")) {\n";
>     $jbridgeCode .= "\t\t\t" . $parent->{astNodeName} . "::$name();\n";
>     $jbridgeCode .= "\t\t}\n";
>     $jbridgeCode .= "\t\treturn;\n\t}\n";
>
> It tests for a return type of 'void' with no args, and generates
> appropriate code in the *JBridge C++ classes. To add
> QSqlCursor.calculateField() it would need to check for a return type of a
> Qt instance (QVariant in this case), with a single QString arg as a
> parameter.
>
> Then in QtSupport.cpp, there is a method:
>
> bool
> QtSupport::voidDelegate(void * object, const char * className, const char *
> methodName)
> {
> ..
>
> Which calls a method in org/kde/qt/Invocation.java via JNI. So you would
> need another one of those in QtSupport.cpp, along with a corresponding java
> invoke() method in Invocation.java.
>
> -- Richard

OK, I will take a look at this and see if I can make some sense of it.  

Presumably I should use the code for _BRANCH or have you let the other
fixes through to _HEAD?

Looking more closely I see what you mean about kalyptus not handling this
even in _HEAD.  It would appear simply to create the method and get it to
call the cpp default method rather than trying to invoke the java method.

Although I see that somewhat radical changes are proposed (at least for the
SQL bits of Qt) for Qt 4, I presume that for KDE 3.4 the Qt bits are likely to 
remain much as they are, i.e. that KDE 3.4 is aimed at Qt 3.3.

One last question (for the moment).  Where is the build procedure for taking
the qt include libraries and rebuilding the kalyptus built bits.  As far as I 
can see the normal make does not invoke kalyptus.

David