Office: (Office 2003) Meldungsfenster bei Mailversand über MAPI

Hallo,

ich habe folgendes Problem:

Ich versende im Hintergrund über Access einen Report über MAPI Outlook ... das funktioniert auch alles total super ... leider meldet sich dann immer ein Meldungsfenster, dass im Hintergrund etwas gesendet werden soll ... nach einer kurzen Wartezeit kann dann durch Klick auf den Ja-Button der Versand dennoch gestartet werden.

Besteht eine Möglichkeit, dass dieses Meldungsfenster nicht angezeigt wird?

:)

 

Hi,

hier ist die Lösung für Dein Problem

http://www.ms-office-forum.net/forum...tlookconnector

In diesem Beitrag wird der Weg gezeigt.

Absolut top mit dem Outlook-Connector von Sascha

Servus
Peter

 

... ja, werde mal dort nachschauen ... Danke schon mal

 

Hallo,

das ist eine sicherlich super Lösung ... aber leider kann ich sie hier nicht zur Anwendung bringen ...

... ich kann hier keine DLL ins Netz bringen bzw. nicht registrieren ...


Gibt es eine andere Lösung, die eine solche Registrierung nicht benötigt?

 

Falls man den OutlookConnector auch per Latebinding einsetzen kann, könntest du die COM-dll auch ohne Registrierung einsetzen.
Stichwort: DirectCOM von Olaf Schmidt oder direkt per VBA-Codemodul nach dem Beispiel aus http://www.ppreview.net/Forum/topic.asp?TOPIC_ID=570 (Den letzten Link fand übrigens Sascha. *Smilie)

Notfalls könnte man auch auf Ereignisse per Latebinding reagieren. Das wird dann allerdings etwas umständlich.

mfg
Josef

 

... Danke Josef ... werde mir den Link mal ansehen ...

 

... vom Inhalt des Linkes habe ich nichts verstanden *frown.gif*

Etwas viel für nur einen Kopf

 

Ich las mir nun die Beschreibung unter mossSoft durch.

Dort steht:

Damit kannst du meiner Ansicht nach die Late-Binding-Variante abschreiben, da ein Add-In nur mittels Registrierung läuft.

@Sascha (falls du mitliest): Wäre es eventuell möglich, dass man die gleiche Funktionalität mittels VSTO und Click-Once bereitstellt, um das Add-In ohne Admin-Rechte verwenden zu können?
Gleich vorab: ich habe keine Erfahrung mit VSTO. *wink.gif*

mfg
Josef

 

das wäre natürlich eine geile Sache, den OLConnector ohne Registrierung
ansteuern zu können; das ist nämlich bei mir hier in der Firma auch nicht
möglich...

 

Zum Thema VSTO:
VSTO "umgeht" die Registrierung aber nicht. Wenn für das AddIn eine Registrierung notwendig ist, wird diese auch hier nötig sein.
Die Admin-Rechte sind ja nur notwendig um das AddIn zu "aktivieren" bzw. zu installieren.
Je nachdem wie die VSTO-Lösung aussieht, ist das auch hier notwendig (zumindest soweit meine Erfahrungen *g*).
Lösung/Workaround wäre evtl. die Registrierung in den Userteil zu verlagern...

 

\@Benny: Sind für die Click-Once-Registrierung Admin-Rechte erforderlich?

Genau so stellte ich mir das vor - zumindest wenn bei der Office-Installation die Unterstützung für VTSO ausgewählt wurde. *Smilie

mfg
Josef

 

Jein *wink.gif*
Die Frage ist, wo sich das AddIn registrieren will/muss.
Sobald das Richtung HKLM geht, sind i.d.R. Admin-Rechte nötig.

ClickOnce macht da m.W. keine Ausnahme, kann ich aber nicht 100% bestätigen. Müsste ich ausprobieren.
Bei mir stellt sich das Problem nicht, da ich auch meine VSTO als verschaltes MSI-Paket versorgen muss. Bzw. meine Versorger nichts anderes versorgen können/wollen *wink.gif*

 

Oder anders formuliert: kann man ein VSTO-Add-In in HKCU registrieren, damit es funktioniert?

Betrachten wir es einmal so: ich würde als Admin nicht zulassen, dass mir jemand eine Sicherheitslücke in meine Mailsystem per Add-In einschleust.
Anm.: Das geht jetzt nicht gegen den OLConnector von Sascha, sondern gegen die Möglichkeit so etwas zu machen - es könnte ja Leute geben, die damit besondere Features (wie z. B. unbemerkter Massenemailverand u. ä.) einbauen würden.

mfg
Josef

 

per Default geht es offenbar nicht.
Habe atm. nicht die Möglichkeit das im Detail zu testen, werde ich aber nachholen... interessiert mich jetzt selbst und könnte evtl. das ein oder andere im MSI erübrigen *wink.gif*

 

Ihr macht mir ja hier Sachen. *wink.gif*

Nein, der OLConnector geht nicht ohne Registrierung.
Ist ja ein OL-COM-Addin, das Zugriff auf dessen Objektmodell unter - das ist ja gerade sein Witz - dem gleichen Adressraum haben muss.

Wie das per DirectCOM gehen könnte, fällt mir gerade nicht ein. Um an das Application-Objekt von OL zu kommen, benötige ich ja das IDExtensibility-Interface in der Connector-Klasse, welches OL selbstständig abfragt.
Würde die Klasse per DirectCOM instanziert - was ohnehin ein zusätzliches Modul in OL erforderte -, dann ist es wohl zu spät, weil eine Office-App dann längst die Interface-Abfrage der Klasseninstanzen fertig hat.
Jedenfalls ist es mir bisher nicht gelungen, IDExtensibility in ein VBA-Projekt eines geladenen Dokuments/MDB/VbaProject.OTM selbst zu verfrachten.

Was die Sicherheit angeht, hatte ich ja später zusätzlich die Geschichte mit dem Passwort eingebaut, welches allerdings wiederum in den Optionen von OL eingegeben werden muss.
Daneben könnte man, wenn man das Addin per zusätzlichem Modul in OL-VBA instanzieren würde, dort eh irgedwelchen Schadcode unterbringen, weshalb OL ja auch besonderen Wert auf deaktivierte Makros legt. *wink.gif*

Mit Click-Once habe ich keine Erfahrung. Ich kann mir auch nicht vorstellen, wie es helfen sollte, da ein Office-COM-Addin halt nur geladen wird, wenn es von der entspr. App in der Registry gefunden wird.

Was ich natürlich machen könnte, ist, den Quellcode offenzulegen, damit die Funktionalität auch in OL-VBA-Modulen pur nachgebildet werden kann. Wäre möglich. Das aber ist mir zu unsicher...

Wegen dem Link in #5:
Ja, das ist nun wirklich COM und API hoch zehn.
Ich hatte damals aufgrund des Codes im Link angefangen, Routinen zu programmieren, denen man einen beliebigen Klassennamen/ProgID oder die CLSID übergibt, worauf sie die TypeLib auslesen und die Interfaces selbständig als analoge benutzerdefinierte Typen/Abbilder der VTBL in ein neues Modul schreiben - nebst erforderlichem Code zum Aufruf der Methoden per Assembler-Schnipsel (für CallWindowProc).
Das wäre an sich ein absolut geniales Teil, welches einen komplett aller Registrierungsprobleme entledigen würde. Nur hab ich's bald gelassen, weil ein Interface fast immer Properties oder Methoden enthält, die wiederum andere Interfaces als Parameter oder Rückgabewerte referenzieren, so dass deren Aufbau ebenfalls als benutzerdefinierte Typen in ein Modul geschrieben werden müsste. Das ist dann schon SEHR aufwändig und unübersichtlich (huch, schon wieder dieses Wort. *wink.gif* ).
(...Aber Wayne Philips machts ja offenbar auch so mit seinen seltsamen NativeCode-Strings...)
Ich hab's nicht komplett weg vom Radar, aber ich fürchte, das wird realistischerweise wieder mal nix werden.

Ciao, Sascha