[Kde-bindings] Qyoto: contructing a QPalette from a QColor

[Richard Dale]

On Wednesday 18 October 2006 00:09, Arno Rehn wrote:
> Am Montag, 16. Oktober 2006 11:26 schrieb Richard Dale:
> > On Sunday 15 October 2006 16:38, Arno Rehn wrote:
> > > Am Samstag, 14. Oktober 2006 22:04 schrieb Arno Rehn:
> > > > Hi,
> > > >
> > > > I've just tried to port the Qt tutourial t11 to C# and came across
> > > > the following error when trying to construct a QPalette from a
> > > > QColor:
> > > >
> > > > [error message]
> > > >
> > > > It confuses me, that the stacktrace goes up to libsmokeqt.so.
> > > > The example in qtruby is functional. Is there a need for special
> > > > marshalling code or so?
> > >
> > > I've just tried some more things and the same problem occurs when
> > > constructing a QRegion from a QRect. One thing they all have in common
> > > is that they can be part of a QVariant. I looked through the QtRuby
> > > code and didn't see any declaration of these types that cause problems
> > > (QRegion and QPalette, there are more if I'm right). They're only in
> > > "class Variant < Qt::Base". What does this mean?
> >
> > The problem was that there was no code to resolve ambiguous methods that
> > were overloaded, when there was more than one possible candidate in the
> > Smoke lib. It should be fixed now - so I hope this QRegion constructor is
> > part of the same problem. We need to add a cache of C# MethodInfo to
> > Smoke lib method ids so that the lookup only needs to be done once, as
> > it's probably a bit slow - ie a Hashtable with a key of the MethodInfo
> > for the method with a value of the Smoke method id as an int.  That's
> > what QtRuby and PerlQt do, and we should do the same for Qyoto..
> >
> >     static private Hashtable methodCache = new Hashtable();
> >     ...
> >     methodCache[callMessage.MethodBase] = (object) methodId;
>
> I've just written some code for this, but it doesn't work as expected.
> Somehow the MethodBase returned by 'callMessage' differs from the one
> returned by a normal Type-instance. This is a part of my code (methodCache
> is a global Hashtable containing other Hashtables for each class which in
> turn contain the methodIds):
>
> 		private void SetupMethodTable(Type klass) {
> 			Hashtable hash = new Hashtable();
> 			Console.WriteLine(klass.ToString());
>
> 			foreach (MethodInfo mi in klass.GetMethods(BindingFlags.Instance |
> 									BindingFlags.Public |
> 									BindingFlags.Static |
> 									BindingFlags.NonPublic)) {
>
> 				[Code for retrieving the mungedName]
>
> 				int methodId = FindMethod(mungedName, mi);
> 				hash.Add((MethodBase) mi, methodId);
> 			}
> 			methodCache.Add(klass, hash);
> 		}
>
> Now if we want to retrieve our methodId from the Hashtable like this:
>
> Hashtable methodIds = (Hashtable) methodCache[_instance.GetType()];
>
> int methodId = (int) methodIds[(MethodInfo) callMessage.MethodBase];
>
> we will get
>
> Unhandled Exception: System.NullReferenceException: Object reference not
> set to an instance of an object
>
> but only for some classes, not for all.
> One way to work around it would be to create a method signature for each
> method on-the-fly and set this one as a key in the Hashtable, but this
> would cause several other difficulties and espacially a major slowdown
> (I've already tried it).
> Maybe I do something wrong, but I would leave it as it is at the moment.
OK, I was going to cache the method once it had been looked up for the first 
time rather than doing it all in advance. I think the disadvantage of doing 
it all up front is additional start up time, and extra memory use to cache 
all methodIds even if they had never been called. Is '(MethodInfo) 
callMessage.MethodBase' always the same for a given method, or does it get 
created each time a method is invoked via SmokeInvocation.Invoke()? And I 
wasn't sure why the code in SmokeInvocation.cs has a test:

if (callMessage.MethodSignature != null) {
...

Is that right? I was meaning to check if it was needed.

A key of a string consisting of classname + SmokeMethod() signature, instead 
of the MethodInfo would work.

On the other hand if it doesn't work, it sounds like premature optimization 
and we're better off working on other things for now as you say. 

-- Richard