[Kde-bindings] Qyoto: showstopper bug - help needed

Dimitar Dobrev dpldobrev at yahoo.com
Sat Jun 16 18:21:39 UTC 2012


Hi, Steven,

Thanks for your reply. I've fixed part of the problem: 3 missing breaks in the giant switch for QEvents (see my changes from today). However, invalid casts still occur in other places like this ExpandedTo method.

I'm not completely sure if what you point to is a bug or not. Basically, mapPointer is not a cache as I initially thought but a mapping between an unmanaged and a managed object. This is why I wrote that when that line was commented out calls to a single property returned different managed objects. So, unmapPointer removes the managed object when the unmanaged one is destroyed (you can see for yourself where unmapPointer is used). However, I think that no objects must be unmapped in the marshallers but then I'm not sure why FreeGCHandle is necessary. Arno, could you please shed some light on this?

Steven, as you can see, I'm not yet an expert on the code myself but I'd do my best to answer any questions you may have on it.



________________________________
 From: Steven Boswell II <ulatekh at yahoo.com>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Saturday, June 16, 2012 8:40 PM
Subject: Re: [Kde-bindings] Qyoto: showstopper bug - help needed
 

I'm having a heck of a time understanding the source code, given that it's not documented in any significant way, but the first obvious thing I noticed is that, in all of the marshalling functions that call mapPointer(), none of them call unmapPointer(); instead, they call FreeGCHandle directly.  Could that be the source of the problem?


________________________________
 From: Dimitar Dobrev <dpldobrev at yahoo.com>
To: KDE bindings <kde-bindings at kde.org> 
Sent: Wednesday, June 13, 2012 3:51 PM
Subject: [Kde-bindings] Qyoto: showstopper bug - help needed
 

Hi all,

The workaround for the bug causing an invalid cast - the commenting out of the mappointer call in qyoto-qtcore/native/handlers.cpp - is not correct because it causes different managed objects to be returned for subsequent calls to the same property. So this bug has to be fixed otherwise Qyoto is completely useless. Please, if anyone has any idea, it would be of help. Here are my few findings:

1. The mentioned hack gives some hint what might be wrong - I think that the problem is that initially the wrong object is constructed but as it is not saved when it is being requested it is created anew, and this time correctly; this, I believe, is confirmed by a QDropEvent with type() == QEvent.Type.QDragMove that is tried to be passed to a QDragMove event handler; that is, the type() method gives the correct result but the object type (QDropEvent) is wrong;

2. Subsequent calls to failing methods work properly. For example on my machine this method in QSize:

        public new QSize ExpandedTo(QSize arg1) {
            object[] smokeArgs = new object[] {
                    typeof(QSize),
                    arg1};
            return ((QSize)(this.interceptor.Invoke("expandedTo#", "expandedTo(const QSize&) const", typeof(QSize), false, smokeArgs)));
        }

may crash with "Unable to cast object of type 'Qyoto.QItemSelectionModel' to type 'Qyoto.QSize'." but if I call it again (tried this a few times in the Visual Studio watch window) the error doesn't appear any more, that is, the correct type is returned.

_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings



_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20120616/1afa73f9/attachment.html>


More information about the Kde-bindings mailing list