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

[Richard Dale]

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