Zugriff auf Variantarray von IMAPITable Properties
-
Martin Richter schrieb:
Ansonsten hast Du recht:
Dein Code kann nur funktionieren, wenn in den VARIANTs ein Basistyp ist und kein Typ der letzten Endes wieder einen Zeiger darstellt.Ich gehe nur aus dem Grund davon aus, dass es so ist, weil ich den Code im msdn support gefunden habe: http://support.microsoft.com/kb/152294/de
Da steht ja:
Zum Extrahieren von binären Daten aus einem COleVariant-Datentyp ...
-
Und genau das ist falsch! Das Beispiel enthielt einen SafeArray auf Unsigned CHAR, also Bytes!
Du hast aber einen Safe Array auf Variants, wie Du sleber schreibst.
Das heißt Du hast weider einzelne Variants und keine Bytes!
-
Rück mal bitte etwas von dem ab was ich da geschrieben habe :). Ich verstehe die Struktur wie gesagt selbst noch nicht so ganz. Das Beispiels ist aus der msdn entlehnt.
Bloß wenn du sagst, dass da einzelne Variants drin sind, warum bekomme ich dann für jeden Einzelnen Wert den Typ 17 angezeigt? Das ist doch nach der Typenkennung in der msdn ein Byte und kein Variant, wie hier zu lesen ist: http://msdn.microsoft.com/en-us/library/3kfz157h(v=vs.85).aspx
Aber wie auch immer .... was schlägst du vor, um die Werte auszulesen?
-
Es ist ein Array von Variants. D.h. Du musst mit SafeArrayAccess lifert Dir auch einen Array of Varants. In diesem ist dann jeweils das Feld gefüllt das der Typ angibt.
Nochmal:
Das Sample sagt doch Array of UI1, OK dan liefert die SafreArrayAccess einen Array von UI1 (sprich BYTES)! Du hast einen Array von Variants, also musst Du die einzlenen Bytes aus allen Varaints zusammensuchen (wenn 17 ein UI1) ist, dass musst Du wissen. ich habe keine Lust gerade in den Headern herumzusuchen
Gute Nacht.
-
Ich lese jetzt die Werte einfach mit einer Schleife aus ... scheint zu funktionieren.
Hast du vielleicht auch eine Ahnung, wie ich an die Werte innerhalb eines vbObjects herankomme?
Es ist so das eben eine IMAPITable Property den Wert 9 hat, also prop.vt = 9 ist. Laut msdn (http://msdn.microsoft.com/en-us/library/3kfz157h(v=vs.85).aspx) ist das ein vbObject, was wohl in vc++ ein Objekt darstellt, dass von IDispatch abgeleitet ist.
Aber wie komme ich bloß an die Werte heran?
-
Wenn Du weißt was es für ein Objekt ist, kannst Du das entsprechende Property aufrufen und die Daten abfragen. In den meisten Fällen ist was das "Value" Property... Aber eigentlich müsstest Du das doch wissen, denn Du fragst die Daten ab...
-
Was ich tue, ist ein Looping über eine Set von Properties einer IMAPITable. Das sind im Einzelnen 86 unterschiedliche Properties. Ich kenne nicht einmal deren Bedeutung, geschweige denn, was diese für Daten enthalten. Also: Nein, ich habe keine Ahnung was das für ein Objekt ist. Deswegen will ich es ja ermitteln.
Ich bekomme also einen Variant, der den Varianttyp 9 hat. Das ist lt. msdn also der Typ vbObjekt. Damit kann ich bloß so nichts anfangen, weil ich nicht weiß was das für ein Objekttyp im Einzelnen ist. Ich muss also auf den/die Wert/Werte in diesem Objekt zugreifen und sie auslesen können. Das kann ich aber nur, wenn ich weiß was das für ein Objekt ist, dass vbObjekt für diesen Fall enthalt. Die Frage ist also:
Wie bekomme ich heraus, was das für ein Objekt ist, dass vbObjekt enhält?
Und: Wenn ich tatsächlich ermitteln kann, was das für ein Objekt ist: Über welche Eigenschaft kann ich den Wert auslesen, den das Objekt enthält?Wobei ich Letzteres nicht so kritisch sehe, wenn ich nur erstmal weiß, was vbObjekt für ein Objekt enthält.
-
Hat echt noch niemand hier über c++ auf ein vbObject zugegriffen, oder hat einfach keiner Lust davon zu berichten?
-
Nur mal ein Gedanke - hast du mal versucht,
typeidauf dieses Objekt loszulassen?
-
Lies bitte doch einfach mal die Beschreibung. Was für ein Interface eine Schnittstelle zurückgibt steht zu 100 Prozent eben genau in der Doku drin!
Ansonsten steht Dir IDispatch::GetTypeId zur Verfügung!Grundsätzlich: Du stocherst etwas viel im COM Nebel herum, evtl. solltest Du Dir hier noch mehr Basiswissen aneignen.
@CStoll: Da es sich um eine Com Schnittstelle handelt wird es wenig Erfolg haben, da vermutlich das Interface sogar gemarshalled ist.
-
Martin Richter schrieb:
Lies bitte doch einfach mal die Beschreibung. Was für ein Interface eine Schnittstelle zurückgibt steht zu 100 Prozent eben genau in der Doku drin!
Ansonsten steht Dir IDispatch::GetTypeId zur Verfügung!Grundsätzlich: Du stocherst etwas viel im COM Nebel herum, evtl. solltest Du Dir hier noch mehr Basiswissen aneignen.
@CStoll: Da es sich um eine Com Schnittstelle handelt wird es wenig Erfolg haben, da vermutlich das Interface sogar gemarshalled ist.
Du meinst die Doku über IDispatch in msdn oder wie?
Das mit dem GetTypeId könnte mir helfen. Ich werd mal schauen, ob ich das verwenden kann.
Welche Doku meinst du? Wie wäre es mal mit einem Link? Ist ja vielleicht auch noch für andere Leute interessant, die sich möglicherweise mal hierher verlaufen.
-
Es geht mir um COM und OLE-Automatisation...
MSDN ist viel und nicht unbedingt zielgerichtet. Aber sicherlich findest Du dort "alles".
Ich bin keine gute Adresse um Auskünfte über Tutorials zu geben.
-
Martin Richter schrieb:
@CStoll: Da es sich um eine Com Schnittstelle handelt wird es wenig Erfolg haben, da vermutlich das Interface sogar gemarshalled ist.
Daran habe ich nicht gedacht. Aber bei COM-Objekten hast du auf jeden Fall einen IUnknown in der Hand, wenn nicht sogar etwas hilfreicheres, das Informationen über den Datentyp liefern könnte.
-
CStoll schrieb:
Daran habe ich nicht gedacht. Aber bei COM-Objekten hast du auf jeden Fall einen IUnknown in der Hand, wenn nicht sogar etwas hilfreicheres, das Informationen über den Datentyp liefern könnte.
Richtig! In dem Falle sogar ein IDispatch, dass freiwillig eigentlich alles verrät.

-
Also IUnkown hat lediglich 3 Methoden zur Auswahl.
AddRef
QueryInterface
ReleaseWenn ich den Objekttyp kennen würde, könnte ich über QueryInterface wohl einen Pointer darauf bekommen. Aber! Wie gesagt, ich kenne den Objekttyp nicht.
Was wohl also benutzt werden muss, ist, IDispatch.
Ich bin noch nicht dazu gekommen, dass mit dem Typeinfo auszuprobieren. Ich schaue mir das jetzt mal an.
-
Mal ne frage:
Was erhalte ich, wenn ich das hier abfrage:
hr = variantProperty.pdispVal->GetTypeInfo(0,NULL,&pTInfo); pTInfo->GetFuncDesc(0, &pDesc); f << "memid: " << pDesc->memid << endl; f << "HEXmemid: " << hex << pDesc->memid ....variantProperty ist die Eigenschaft deren vt (Type) = 9 ist. Mit pdispVal hole ich mir einen Pointer auf das IDispatch. GetTypeInfo sollte nun also beschreibende Informationen in pTInfo schreiben usw.
Ist auch alles gut soweit. Das hier kommt dabei heraus:
memid: 1610612736 HEXmemid: 60000000Aber was bedeutet das? Oder noch anders gefragt: Gehe ich da den richtigen Weg, wenn ich Informationen über den Typ von variantProperty herausbekommen will?
-
Und warum schaust Du nicht einfach mal mit GetDocumentation nach?
Hier ein netter Artikel, der durch die gesamte ITypeInfo führt
http://spec.winprog.org/typeinfo/
http://spec.winprog.org/typeinf2/
http://spec.winprog.org/typeinf3/Teil 2+3 ist IMHO an wichtigsten
Mal grundsätzlich: Warum machst Du das nicht einfach mal mit einem Stück VBScript code und testest das aus.
Und nochmal: Warum liest Du nicht das was in der Doku steht? Dort wird Dir gesagt welche Methode welche Objekte liefert.
Lies doch erstmal einpaar Grundlagen und stocher nicht so im Nebel herum:
http://msdn.microsoft.com/en-us/library/ms221375.aspx
-
Martin Richter schrieb:
Mal grundsätzlich: Warum machst Du das nicht einfach mal mit einem Stück VBScript code und testest das aus.
Ja darüber habe ich auch schon nachgedacht. Ich bin es allerdings nicht gewohnt, dass eine so einfache Aufgabe derart kompliziert in der Umsetzung ist. Mir scheint das alles was von microhsoft kommt, ein endloses patchworking ist. Verschiedene technologien existieren nebeneinander, aber nichts greift ineinander. Und von einem schlüssigen Gesamtkonzept kann hier absolut nicht die Rede sein.
Wenn man sich hingegen mal anschaut, wie strukturiert beispielsweise das Java SDK ist, dann kann man gut erkennen, was es bedeutet ein richtige Konzept zu haben und nicht ständig etwas mit etwas anderem zu ergänzen, dann Mängel aufzudecken, und dann einen weiteren Flicken hinzuzufügen. ... echt ein Albtraum.
-
Martin Richter schrieb:
Und warum schaust Du nicht einfach mal mit GetDocumentation nach?
Dazu hab ich hier ein interessantes Zitat aus http://spec.winprog.org/typeinf2/ (vielen Dank für den Link an dieser Stelle, scheint hilfreich zu sein)
GetNames won't work, but ITypeLib::GetDocumentation will (why type names are called "documentation" is beyond me).
Ich möchte dazu sagen, dass ich das nicht so explizit poste um dich zu foppen. Bloß möchte ich nicht, dass der Eindruck entsteht COM sei intuitiv nutzbar, und das man es am Besten lassen soll, wenn man nicht von sich selbst heraus durchsteigt und bei einer ähnlichen Problemstellung direkt darauf kommt getDocumentation zu benutzen. Mir scheint bei der Benutzung von COM ist rein gar nichts intuitiv nutzbar, und für alles gibt es besondere Konzepte, deren Nutzen sich vielleicht mal später, aber einigen wohl auch niemals erschließt, wie das Zitat zeigt.
-
Wer sagt das Programmieren irgendwas mit Inituition zu tun hat.
Ich habe keine Probleme mit COM und auch nicht mit Automatisation. Nur kommt es mir vor, dass Du mit 0-Vorkenntnissen gleich einen Tieftauckurs veranstaltest.
BTW: Ich finde VARIANTs und SafeArray's ausgesprochen intuitiv, allerdings hast Du Dich da auch icht einfach dran gehalten was Du bekommst sondern was Du ein einem Sample zu einem ganz anderen Thema gesehen hast.
Geschmacksache. Vieleicht bin ich schonzu lange in diesem Geschäft um die Schwierigkeiten noch zu sehen.