Topic: Autodesk.Windows.TaskDialog with Callback doesn't work under 2013

[kaefer]

So I'm taking e.g. this example of a TaskDialog with Callback and CallbackData, which works up to 2012 but dies under 2013 with an InvalidCastException in the method private unsafe int PrivateShow(IntPtr hwndOwner, out bool verificationFlagChecked, out int radioButtonResult). The fun thing is to observe that its implementation in AdWindows.dll hadn't been changed between the releases, courtesy of ILSpy.

Can anybody confirm?

[zoltan]

.NET Reflector reveals that the exception is happening when the instance of MyData that is set to the CallbackData property of TaskDialog tries to get cast to IntPtr.

That's all of the help that I can give, sorry.

[TJK44]

kaefer, I'm getting the same InvalidCastException error at this line (2012 & 2013)

Code: [Select]

    td.Show(Application.MainWindow.Handle)


[kaefer]

.NET Reflector reveals that the exception is happening when the instance of MyData that is set to the CallbackData property of TaskDialog tries to get cast to IntPtr.

That's all of the help that I can give, sorry.

Thank you! That confirms what I suspected, albeit I can't make hand or foot out of it - except that it's somehow supposed to marshal managed data:

Code: [Select]

if (this.mpCallbackData != null)
{
tASKDIALOGCONFIG.lpCallbackData = (IntPtr)this.mpCallbackData;
}
How does the version of the framework play into this? 2013 needs mscorlib, Version=4.0.0.0, while 2012 can do with mscorlib, Version=2.0.0.0.

[TheMaster]

How does the version of the framework play into this? 2013 needs mscorlib, Version=4.0.0.0, while 2012 can do with mscorlib, Version=2.0.0.0.

That's clearly a bug. You can't cast anything boxed in a System.Object to an IntPtr, and trying to do that doesn't give you the address of a reference type if that's what's in the object.

Even if casting to an IntPtr were possible, I don't see how it can possibly work, as the GC can move the object around in memory. If the object isn't moved it might work, otherwise it will fail.

Typically, a pinned GCHandle is needed to hold a reference to managed data in native code.

Another possible problem is that when you have a reference to a managed object stored in an IntPtr, the reference to the managed object must be kept alive and reachable in order to ensure it doesn't get garbage collected.