Problem mit <DllImport("gdi32.dll")>

Ah ok. Aber könnte man LPPICTDESC nicht auch als LPStruct marshallen? Muss da nachher mal was probieren.

Ja klar. Marshallen als LPStruct für PICTDESC wäre natürlich eine Möglichkeit. Wäre dann sowas wie VarPtr(PICTDESC). Unter VB6 würde das aber keiner so machen und einfach die Struktur ByRef übergeben. Ich füge mal noch hinzu das der erste Parameter von OleCreatePictureIndirect auch NULL sein kann. An der Stelle macht es VB6 einem auch etwas leichter. Den ersten Parameter ByRef lpPictDesc As Any auslegen und schon kann man die Struktur so übergeben oder halt ByVal 0& (NULL) übergeben.

@VaporiZed DTF hat das sehr gut erklärt das der 5 Parameter ByRef sein muss. Das * sagt Dir auch das hier ein Pointer auf ein Array mit Pointern zurück gegeben wird. An die einzelnen Pointer kommst dann mit Pointer = zurückgeben Pointer der API + (SizeOf(Pointer) × index einer For/Next). Alternativ kopierst mit Marshal.Copy vom zurückgeben Pointer der API in ein Pointer-Array um. Das es mit ByVal Pointer-Array funktioniert dürfte klar sein wenn Du Dir die Formel anschaust, um an den einzelnen Pointer zu kommen bzw. was Marshal.Copy macht. Aber dazu müsstest die API ja zweimal aufrufen weil Dir ja vorher nicht bekannt ist, wieviele Pointer da zurück gegeben werden -> Return der API.

Byval 0& das finde ich sogar Genial! Wenn man sich nun mal meine Signatur anschaut:


Der Parameter piconid ist auch als out optional gekennzeichnet, hab aber das ref weggelassen, weil ich es in diesem Fall nicht brauchte, so ein ByVal 0& würde es möglich machen auch piconid als ref zu deklarieren selbst wenn nicht gebraucht. Einfach nur 0/null macht der Kompiler in C# nicht mit wenn als ref angegeben. So muss ich mehrere Deklarationen haben, wenn ich diese Parameter optional halten will, hier sinds dann 4 Deklarationen. Alternative wäre sinnlose Variablen zu nutzen, aber das ist nicht mein Stil.

-Franky- schrieb:

Wie ich immer sage: Kompliziert ist relativ. Die einen können es, die anderen tun sich schwer aber versuchen es und andere verweigern es sich mit der Materie zu beschäftigen.

Da hatte ich glatt vergessen was zu dazu sagen, ich denke wenn jemand C++ kann fällt dem das viel leichter. Ich werde oft im privaten wegen irgendwelchen WinAPI Zeug gefragt, die Leute die fragen, haben mit C++ nichts am Hut. Ich kann mich aber auch noch an meine ersten Exceptions mit der WinAPI erinnern, da tat ich mich auch schwer, hab mich aber durchgeboxt. Als ich irgendwann C++ ohne "Stützräder" konnte, ja seit dem geht's i.d.R. locker flockig aus dem Handgelenk.

@DTF Ich kann kein C++ programmieren. Ich kann C++, und andere Programmiersprachen, aber relativ gut lesen. Ist aus der Not heraus geboren da viele Beispiele und die Doku nicht in meiner favorisierten Programmiersprache vorliegen und dann beschäftigt man sich automatisch damit. Ok, ich mach das aber auch schon ein paar Jahrzehnte und daher fällt mir das auch etwas leichter.

Ja C++ lesen zu können ist auch ein Vorteil. Aber ein paar Dekaden Erfahrung ist da doch der größere Vorteil im Vergleich zu C++ lesen können, sobald es klick gemacht hat, klappst einfach. Je Erfahrener umso eher machts auch klick. Hat man erstmal "ein paar Jahre auf dem Buckel", kanns im normalfall recht einfach sein. Bei mir hats wie gesagt nachdem ich C++ konnte richtig laut geklickt, was NET+WinAPI angeht.

@DTF Ok, jetzt wird es etwas Offtopic. Das Problem das ich sehe, warum sich soviele schwer damit tun, ist das man halt nur NET kennt. Da ist alles in irgendwelchen Klassen weggekapselt und man muss sich keine Gedanken darüber machen was da wirklich im Hintergrund passiert. Man nutzt es einfach und fertig. Das da ebenfalls die ganz normalen WinAPIs und COM-Interfaces zum Einsatz kommen wissen nur die, die auch mal einen Blick hinter die Kulissen von NET werfen. Wer weis denn so Adhoc auf die schnelle das WPF z.B. die Windows Imaging Component (WIC) nutzt um Bilder zu laden/zu speichern usw? Du vllt. schon, aber kafffee auch? Und das WIC nicht nur unter WPF funktioniert?

-Franky- schrieb:

Und das WIC nicht nur unter WPF funktioniert?

Die WIC-API habe ich durch den WICTextureloader aus dem DirectXTK kennengelernt. War dann ein wenig neugierig, hab ein wenig dazu gelesen, mich dann aber nicht näher damit beschäftigt.
github.com/microsoft/DirectXTK…in/Inc/WICTextureLoader.h
github.com/microsoft/DirectXTK…/Src/WICTextureLoader.cpp

Also Factory holen um damit einen decoder zu erstellen um durch den an die Frames zu kommen, hab ich da noch im Kopf. Aber in wie weit kafffee sich mit sowas beschäftigt, bzw. solchen Themen ist mir nicht bekannt. Muss man ja auch nicht, nur weil man WinAPI unter NET verwenden will. Aber ein Blick in die C++ Doku sollte er trotzdem einfach mal machen, wenn es um solch eine Methode geht. Am wichtigsten sind einfach die Datentypen, nun weiss kafffee auch was es mit in, out, in/out unter C++ auf sich hat, dem Senkrechtstart in die WinAPI-Welt steht kaum noch was im Wege, naja zumindest kann er nun das eigenstädige Tippen einer solchen Funktion mal versuchen.

Mir ging es eher darum kafffee zu sagen das WIC (WPF) bessere Methoden bereit stellt als von einem hBitmap ein WPF-Bitmap zu erstellen weil dadurch der Alphakanal verloren gehen kann und das ein WPF-Bitmap von WPF-BitmapSource ableitet. Im günstigsten Fall werden noch nicht einmal zusätzliche WinAPIs benötigt und es reichen die ganz normalen Namespaces/Klassen von NET dazu.