Wiki der Access Code Library

Gemeinsam zu mehr Effizienz in der Anwendungserstellung

Add-In-Host

Aus Access Code Library
Wechseln zu: Navigation, Suche

AccessCodeLib.AddInHost.[...]

Assembly: vollständiger Name inkl. AccessCodeLib.AddInHost.


  • MS.net 4.0
  • MEF ???
  • Host für VBE + Office-App.
    • Add-in-Host für Office 2000 bis 2010 ff
  • PIA - welche Version? - hoffentlich ohne spezielle PIA (late binding im Host)
  • Vorerst keine Shims - getrennte Appdomain


  • Laden von Plug-Ins - Host lädt Plug-In
    • Laden über:
      • zentrales XML
      • Verzeichnis + XML je Plug-In
      • Registry
    • Informationen von Plug-In:
      • Für User: Name, Beschreibung, Versionsnummer, URL, Copyright
      • Für Host: ID (z. B. direkt von Assembly), für welche Office-Anwendung(en) ist Plug-In, Einsatz von Plug-In ab Host-Version
    • Host: Ladeverhalten: wie VBE-Add-Ins
    • Lade-Reihenfolge festlegen? ... NEIN - (Noch nicht)


  • Application-Objekt (VBE + Office-Application) liefern

---


  • Zugriff auf Command bars / Ribbons
    • Weiche zw. Commandbar und Ribbon (nur Host ist dafür zuständig)
      • Kein direktes Reagieren auf CommandBar-Events im Plug-In - Nur Host reagiert auf Commandbar-Events
      • Eventhandler analog MS.net oder Delegates
    • Plug-In stellt nur Daten zur Verfügung vs. Host stellt Zugriff zur Verfügung
    • Funktionsumfang von Ribbon/CommandBar ???
    • Hot-Keys - Wer bestimmt? Plug-In legt fest, Host meldet doppelte?
    • Aufräumen - Command bar, ... STABIL


  • VBE: Tool-Window erzeugen + bestehende verwenden (GUID)


  • Office-Anwendungseigenschaft im Host für Plug-In
    • Dokument/Datenbank ist geladen
    • ...


  • Fehlerbehandlung durch Host (z. B. ein Fehler über Event von CommandBar)
  • Beobachten vom Laufzeitverhalten / Abgestürztes Add-In nicht mehr laden



  • Optionen-Dialog (für Host + Plug-Ins?) - gemeinsame Optionen?
  • Eigenschaften/Informationen vom Host für Plug-Ins (z. B. Username)