Indy - MessageParts auf Attachment prüfen
-
Hallo, wie gut, dass es dieses Forum gibt.
In der Indy-Hilfe steht folgender Satz und ich habe mich gewundert, warum Body weiterhin leer bleibt, obwohl ich mich genau nach der Hilfe gerichtet habe:
When NoDecode is False, the message will be retreived and the message body is stored in Body in its MIME-encoded form.
Entweder haben mich meine Englischkenntnisse in die Irre geführt, oder diese Aussage ist falsch.
Noch eine andere Frage passend hierzu, da ich BCB-Neuling bin:
Wie setze ich den in der Hilfe angegeben Beispielcode für BCB um? Und zwar geht es nur um dieses Zeile:
if (Msg.MessageParts.Items[i] is TIdAttachment)ich habe es mit
if (Msg->MessageParts->Items[i] is TIdAttachment)versucht. Aber leider ohne Erfolg.
Ich bekomme folgende Fehlermeldung:[C++ Fehler] MainForm.cpp(717): E2377 In If-Anweisung fehlt )
der Cursor steht hinter dem i von [i]
-
Kann mir denn keiner sagen, wo der Fehler liegt? Oder muss ich mich erst stundenlang durch die Suchergebnisse lesen, die ich (noch) nicht habe, da ich auch gar nicht weiß wonach ich eigentlich suchen soll bei dem Problem.
Das dürfte doch für alte BCB-Hasen kein Problem sein, oder?
-
Was soll "is" genau sein?
Das ist schlicht kein gültiger C(++)-Code... dynamic_cast wäre hier wohl dein Freund (so als schuss ins Blaue) hab leider grad keine Doku da zu Indy...
-junix
-
"is" ist, soweit ich weiß, kein gültiger Vergleichsoperator in C++. Deswegen bildet er sich ein, dass die Anweisung bereits nach dem ...[i] zuende sein müssen und will dort die Klammer haben.
Da wirst du wohl anders rangehen müssen.
-
In Delphi wird "is" dafür benutzt, um zu gucken, ob eine Klasse einem bestimmten Klassentyp entspricht.
Gibt es nichts vergleichbares in C++?... dynamic_cast wäre hier wohl dein Freund (so als schuss ins Blaue) ...
ein Cast ist hier völlig fehl am Platz, da ich ja nicht casten, sondern den Typ vergleichen will.
... hab leider grad keine Doku da zu Indy...
das hat nichts mit Indy zu tun, sondern ist typischer Delphi-Source.
-
Jacques schrieb:
Gibt es nichts vergleichbares in C++?
Nein.
Jacques schrieb:
... dynamic_cast wäre hier wohl dein Freund (so als schuss ins Blaue) ...
ein Cast ist hier völlig fehl am Platz, da ich ja nicht casten, sondern den Typ vergleichen will.
Nicht zwingend. Informiere dich mal über dynamic_cast. Man kann das Teil etwas äh, "misbrauchen".
Jacques schrieb:
... hab leider grad keine Doku da zu Indy...
das hat nichts mit Indy zu tun, sondern ist typischer Delphi-Source.
Dabei gings nicht um deinen code sondern darum, dass ich nicht weiss von welchem Typ TMessage::MessageParts::Items ist und ich somit auch nicht wissen kann, welche Methoden das Ding eventuell zur Verfüngung stellt. Allerdings hast du offensichtlich ne Indy Doku, also steck deine Nase mal da rein.
-junix
-
junix schrieb:
Dabei gings nicht um deinen code sondern darum, dass ich nicht weiss von welchem Typ TMessage::MessageParts::Items ist und ich somit auch nicht wissen kann, welche Methoden das Ding eventuell zur Verfüngung stellt. Allerdings hast du offensichtlich ne Indy Doku, also steck deine Nase mal da rein.
Ich habe mir von der Indy-Seite die Beispiele runtergeladen. Die sind aber wie schon gesagt in Delphi geschrieben. Schau dir mal meinen ersten Beitrag an. Da siehst du den Delpi-Source und wie ich versucht habe den Umzusetzen.
Mir ist es völlig egal, von welchen Typ das Ding ist. Ich möchte eigentlich nur wissen, wie ich die Typen vergleichen kann bzw. den Delphi-Source nach C++ umsetzen kann. Also etwas vergleichbares wie "is". Das steht auch nicht in der Indy-Doku.
Ich werde mich dann mal mit dynamic_cast beschäftigen, verstehe allerdings nicht, warum du, wenn du weißt wie es geht, das hier nicht reinschreibst. Das würde mir einiges an Hilfe-Lesen und ausprobieren erparen.
-
Jacques schrieb:
verstehe allerdings nicht, warum du, wenn du weißt wie es geht, das hier nicht reinschreibst.
Weil du mehr lernst, wenn du die (hier nicht allzu schwere) Lösung selbst findest. Und zwar nicht nur über das Problem selbst sondern auch über Wege zur Problemlösung allgemein.
Tip: sieh dich hier im Forum und FAQ nach dynamic_cast um. Ba gibt's haufenweise Code-Beispiele, die sich auf dein Problem anwenden lassen.
-
Jacques schrieb:
Mir ist es völlig egal, von welchen Typ das Ding ist.
Völlig falsche Einstellung. Würdest du den Typ kennen, würdest du eventuell feststellen, wie du das Problem lösen kannst, denn du würdest die Möglichkeiten die dieser Typ bietet kennen. Genau so wie du seine Herkunft und seine Erben kennen würdest.
Jacques schrieb:
Ich möchte eigentlich nur wissen, wie ich die Typen vergleichen kann bzw. den Delphi-Source nach C++ umsetzen kann. Also etwas vergleichbares wie "is".
Sofern die Klassen das nicht implemenitert haben (siehe VCL ClassNameIs), gar nicht.
Jacques schrieb:
Das steht auch nicht in der Indy-Doku.
Nein, aber z.B. die Ahnenreihe von TIdAttachment (Hierarchie)
Jacques schrieb:
Ich werde mich dann mal mit dynamic_cast beschäftigen,
Da gibts nicht viel zu beshcäftigen. Lies mal in der FAQ was zum Thema dynamic_cast steht, lies in der Hilfe nach und schau d ir mal die HIerarchie von TIdAttachment und den Typ von TIdMessage::MessageParts::Items an. Mit dem Wissen sollte es anschliessend klingeln.
Jacques schrieb:
verstehe allerdings nicht, warum du, wenn du weißt wie es geht, das hier nicht reinschreibst. Das würde mir einiges an Hilfe-Lesen und ausprobieren erparen.
Genau deshalb. Damit du lernst die Dokumentation zu benutzen, damit du lernst wie man an Probleme herangeht und weil man selbsterarbeitetes grundsätzlich besser im Kopf behält als wenn einem etwas einfach vor den Latz geknall wird.
Hier findest du noch weitere Gründe dafür im einführenden Abschnitt. Ich würde dir allenfalls auch empfehlen den ganzen Artikel zu lesen.-junix
-
junix schrieb:
Genau deshalb. Damit du lernst die Dokumentation zu benutzen, damit du lernst wie man an Probleme herangeht und weil man selbsterarbeitetes grundsätzlich besser im Kopf behält als wenn einem etwas einfach vor den Latz geknall wird.
Hier findest du noch weitere Gründe dafür im einführenden Abschnitt. Ich würde dir allenfalls auch empfehlen den ganzen Artikel zu lesen.Ich habe 6 Jahre mit Delphi Programmiert, deshalb hab ich mir nur dei Einführung gelesen. Auch ich habe schon viele Dinge durch Zufall in der Hilfe gefunden. Was mich an der BCB-Hilfe nervt, ist dass man zu einigen Dingen Object-Pascal-Hilfen bekommt. Die haben imho nix in der BCB-Hilfe zu suchen.
OK, das wird jetzt ein wenig OT. Nur eines noch: Dieses Forum hier hat mir in sehr kurzer Zeit schon viel geholfen. Ich benutze Grundsätzlich erstmal die BCB-Hilfe und die Suchen-Funktion hier im Forum. Und erst, wenn ich dann nicht zum Ziel komme mache ich einen neuen Thread auf. War in den letzten Tagen relativ aktiv hier und du solltest eigentlich gemerkt haben, dass ich versuche überflüssige Fragen zu meiden. Und manchmal hat man auch einfach nicht die Lust und Zeit dazu sich näher mit etwas zu beschäftigen, wenn es doch schon 100 Leute gibt, die einem die Lösung in einem Satz sagen können. Manchmal ärgere ich mich wirklich über die Art, wie einem hier nur auf die Hilfe verwiesen wird. Es gibt ja auch situationen, wo einem die Hilfe auch nicht weiterhilft, weil man es einfach nicht versteht oder so.
-------------------
so und nu ist schluss mit OT. 
-
So, noch ein Toppic-passender Nachtrag:
mit ClassNameIs funktioniert das ganze.
-
Sicher Lobenswert dein Verhalten. In der Tat passiert es, dass die Hilfe an manchen stellen nicht komplett nach C++ migriert wurde. (v.a. bei BCB1) unterdessen allerdings glaube ich, dass die Hilfe zu 99.9% sauber ist. Ich hab (BCB6) bisher keine Pascal_stellen mehr gefunden.
Dass die Indy-Hilfe nur ObjectPascal ist, ist wirklich schrott.. aber das Mirgrieren sollte eigentlich kein Porblem sein, wenn du die beiden Sprachen etwas kennst.Das problem beim Lösungen in einem Satz hinhauen ist, dass da oft noch klärendes Wissen dazu vermittelt werden müsste, weil man genau wissen sollte, was man da eigentlich treibt. Deswegen geht mir z.B. auch die Hutschnur hoch, wenn ich jemanden sowas posten sehe auf eine Frage eines Anfängers:
// In einem Eventhandler für Buttons (Sender ist vom Typ "TObject *" AnsiString Sendername_AS = dynamic_cast<TButton *>(Sender)->Name;Was geschieht hier nun? Es funktioniert einwandfrei, solange die Funktion nur von einem Button ausgelöst wird und keiner NULL oder andere Zeiger übergibt. Der Anfänger ist glücklich und glaubt sein Allheilmittel gefunden zu haben. Was er nicht weiss ist, dass wehe, wenn das Objekt auf das Sender zeigt mal nicht ein TButton Objekt oder ein Abkömmling davon ist, das Ganze mit einer shcönen Zugriffsverletzung hochgeht. Wieso? dynamic_cast liefert - wie du unterdessen vermutlich weisst - nur dann != NULL zurück, wenn das Objekt auf das der Zeiger zeigen soll auch wirklich der Zielklasse entspricht. Ansonsten ist NULL. (Weshalb man immer erst auf NULL prüfen sollte)
Hätte der Anfänger nämlich sich noch über dynamic_cast belesen und sein Hirn dabei einschalten können, wäre ihm aufgefallen, dass dynamic_cast nicht immer einen gültigen Zeiger zurückliefert.
Das nur als Erklärung.
Hast du die Lösung für das Problem unterdessen gefunden?
-junix
-
Meine Source-Zeile sieht jetzt so aus:
if (MailMsg->MessageParts->Items[MsgIndex]->ClassNameIs("TIdAttachment"))Das Beispiel aus meinem ersten Beitrag stammt übriegens aus der mitgelieferten Hilfe und nicht aus den Beispielen.
Abgesehen davon nutze ich den BCB6 Pro und ich habe schon jede Menge Pascal-Code gefunden. Aber die Borland hilfe war noch nie sauber. Auch die Übersetzungen aus dem englischen lassen manchmal zu wünschen übrieg. Egal ob Delphi oder BCB. Frage mich, ob die das noch mal irgendwann schaffen, die Hilfe in richtiges Deutsch zu übersetzen. Auch die Indy-Hilfe ist nicht Korrekt. Der erste Teil meines Postings gehört eigentlich in den Thread "Indy - Mail abholen: Body bleibt leer". Und da hatte ich ihn auch mal hingeschrieben ist aber auf wundersame weise in diesen Thread gewandert.
Weil genau das Problem mit dem leeren Body hatte ich, habe dann die Fastnet-Kompos benutzt und bin jetzt doch wieder bei den Indys gelandet.
C++ kenn ich halt nur ein wenig und ich habe auch niemanden, den ich hier direkt fragen kann. Bei Delphi war das anders. Da hatte ich gar nicht die Möglichkeit ins Internet zu gehen, dafür aber 2 Kollegen, die man fragen konnte.
-
Indy ist ein 3rd-Party-Paket, das dem BCB kostenlos beigelegt wird, von Borland aber nicht offiziell supportet wird. Vergleichbar wohl mit den Office-Serverkomponenten oder QuickRep.
Was das NoDecode-Problem betrifft, das war doch offensichtlich gelöst. Da sich der Thread in Richtung TIdMessageparts entwickelte wurde der entsprechende Teil abgetrennt. Falls du doch noch NoDecode-Fragen haben solltest kannst du sie im entsprechenden Thread stellen.
-
ich meinte, dass dieser Teil noch in den anderen Thread gehören müsste, da dort nicht steht, dass die Hilfe falsch ist.
Hallo, wie gut, dass es dieses Forum gibt.
In der Indy-Hilfe steht folgender Satz und ich habe mich gewundert, warum Body weiterhin leer bleibt, obwohl ich mich genau nach der Hilfe gerichtet habe:
Zitat:
When NoDecode is False, the message will be retreived and the message body is stored in Body in its MIME-encoded form.Entweder haben mich meine Englischkenntnisse in die Irre geführt, oder diese Aussage ist falsch.
Dass die Indy-Kompos nicht von Borland supportet werden weiss ich auch. Wollte nur sagen, dass eben nicht nur Borland fehler macht. Kam vielleicht nicht richtig rüber.
Vielleicht könntet ihr das ja noch in den entsprechenden Thread packen, dass die Hilfe die Angaben zu NoDecode genau umgedreht hat. Ich denke, dass es noch viele Leute gibt, die sich wundern und stundenlang drüber nachdenken, warum es in der Hilfe so steht, aber nicht funktioniert. Ansonsten noch mal ein dickes Lob an die Mods. Ihr bringt wenigstens Ordnung hier hinein. In vielen anderen Foren steht was an falscher Stelle und dann bleibt das da. Und ihr korriegiert auch mal Überschriften, was ich sehr gut finde.