Laden...
M
Benutzerbeschreibung

Forenbeiträge von Miro610 Ingesamt 8 Beiträge

14.07.2017 - 07:09 Uhr

Also, bevor ich mit HTML/JavaScript Add-ins starte 🙂

ich habe zwischen durch geforscht, vielleicht wird das für jemanden nützlich(obwohl VSTO veraltet ist).
Laut Doku:
"When a VSTO Add-in is installed, it can be registered in two ways:
For the current user only (that is, it is available only to the user that is logged onto the computer when the VSTO Add-in is installed). In this case, the registry entries are created under the HKEY_CURRENT_USER.
For all users (that is, any user that logs onto the computer can use the VSTO Add-in). In this case, the registry entries are created under HKEY_LOCAL_MACHINE.
All VSTO Add-ins that you create by using Visual Studio can be registered for the current user. However, VSTO Add-ins can be registered for all users only in certain scenarios. These scenarios depend on the version of Microsoft Office on the computer and how the VSTO Add-in was deployed. "
Für Fall per machine:
Die im InstallShield definierte Registry Einträge im HKLM Software(32-Bit) werden in 64-Bit System theoretisch korrekt im ..\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\Outlook angelegt.
Nun dann Outlook zwar starte und das AddIn funktioniert, aber im (Outlook)Debug Modus die Applikation schmeißt vorher genannten Fehler.
Es hat mich gewundert, also habe ich manuell aus WOW6432Node Eintrag für FormRegions\Nachrichtenklasse gelöscht und im HKCU angelegt. O Wunder! keine Fehler ?(
Na ja, vielleicht hat Outlook (2013/2016) kleine Probleme mit dem veralteten VSTO\COM Add-in.

Nun wollte ich per User Installation checken. Registry nach der Deinstallation geprüft, eventuelle Reste gelöscht.
Tja, falls ich die Keys direkt in HKCU erzeuge - Outlook lädt das Add-in, lässt es aber nicht aktivieren. Als hätte teilweise Info bekommen, neu Add-in mit keinen Einstellungen. 🤔
Was auch noch toll ist, falls der User im Outlook das Add-in entfernt (braucht keine Rechte, war für ihm installiert) - entfernt das Outlook HKCU Key für ausgewähltes Add-in, lässt aber "FormRegions\NachrichtenKlasse"-Key bestehen. Was zu Folgefehler
führt. Beim jeden Start Outlook meckert fehlenden Manifest für den Formularbereich... Addin ist aber gar nicht geladen 😁
Wenn man jetzt noch Add-in mit dem Installer noch mal installiert und erzeugt Keys in HKLM - kriegt man den Fehler ("Ein Formularbereich blabla...") und das beste ist, dass das Add-in startet mit zwei gleicher Formularbereichen.😁
Was man noch auf Entwicklungsrechner noch beachten muss, ist das Visual Studio beim jeden Buid von VSTO Project- auch Release - erzeugt direkt keys für addin in HKCU, mit Projektpfaden.
Wenn man das vergisst und das Add-in direkt mit dem setup/msi installiert, wundert man sich erst über verschiedene Verhaltensweise auf Entwicklungs- und Klient-Rechner.
Das alles habe ich vorher nicht gemerkt, weil ich nicht bei jeder Aktion build, install, uninstall usw. die Registry auf beiden Rechner genau untersucht habe. Also nicht jedes Mal alles.
Was ich nicht rausgefunden habe, ist why wenn ich mit dem Installer Key für Add-in in HKLM\WOW6432Node anlege und für FormFegions\Nachrichtenklasse
in HKCU Add-in startet aber Fehler besteht. Beim manuellen Eingriff funktioniert es ohne Fehler. Ich habe in Registry dafür keinen Grund gefunden bzw. diesen übersehen.

So, vielleicht wird das oben jemanden ein bisschen Zeit sparen. Beim ähnlichen Aktionen direkt alles Mögliche in Registry überwachen :evil:

12.07.2017 - 14:27 Uhr

Na ja🙂 jetzt weiss ich schon🙂 Trotzdem ich möchte das Problem mit der Installation lösen.
Das Abenteuer geht weiter🙂 Nach bereinigen von Registry und erneuten install das Add In startet... Fast richtig 8o weil schreit immer noch: "Ein Formularbereich kann nicht geöffnet werden....". Allerdings es startet und öffnet sich und funktioniert. Ich frage mich zwar ständig: WTF?? 😁 aber suche weiter.
Irgendeine Leiche ist nach dem debuggen und immer wieder builden (oder installieren) geblieben.

12.07.2017 - 11:37 Uhr

Moin Abt,

ja, das ist VSTO\COm. Das die veraltet sind, wüsste ich nicht:( Ich dachte, dass weil ich grundsätzlich in WPF programmiert habe, dass mit C# wird es in meinem Fall schneler:| Na ja...
nun, was ich noch gefunden habe - wenn man von VS startet, Studio addiert noch Registry Einträge in HKCU\Software\Microsoft\VSTO. Keys Inclusion und Solution Metadata.
Ich habe dort gar nicht geschaut, weil na ja.. ich dachte da es normal ist. das es nur Projekte betrifft, die ich selber im Visual Studio gestartet/entwickelt/was auch immer habe.
Nun sehe ich, dass dort auch zwei Einträge (einen pro Key) sind für von der Firma gekauftes AddIn. Diesen habe ich bestimmt nicht gemacht;) Code nicht mal gesehen.
Sollte man sowas auch erzeugen mit dem Installer? Im MSDN habe ich nichts ähnliches gefunden.
Aber gekauftes AddIn hat diesen Eintrag. Ist das irgendein "Trick 17"? 😃
Vorschläge? Erklärung?

12.07.2017 - 10:05 Uhr

Hallo community,
ich habe Probleme mit der Installation von Outlook Add-In. Ich soll ein kleines AddIn schreiben.
Mein erstes - mit Office Programmierung habe ich bis dato nichts zu tun.
Add-in sollte auf Rechner in der Firma installiert werden (Win 10 / Outlook 2013 32 bit). Ich erstelle .msi Installer mithilfe von InstallShieldLE.
Im Projekt definiere ich ein paar Registry Keys - nichts besonderes, nur das was in der MSDN Dokumentation steht. Im Project_Setup\Configure Target System\ Registry trage ich:
HKLM Software(32)-> Microsoft\Office\Outlook\Addins\MeetingExtendAddIn\ befinden sich Werte für (Default), Description, FriendlyName, LoadBehavior(3) und Manifest (f:///[INSTALLDIR]MeetingExtendAddIn.vsto|vstolocal). Installationsfolder wird auch später richtig gelesen und Dateien in den Zielordner kopiert.
Im Add-In habe ich eine zusätliche Form. Für diesen Formularbereich erstelle ich ein Registry Key
HKLM Software(32)-> Microsoft\Office\Outlook\FormRegions\IPM.Appointment mit zwei Werten: (Default) und MeettingExtendAddin.MeetingFormRegion (Data: =MeetingExtendAddIn).

Installer erstellt registry Keys in HKLM -> WOW6432Node ...weiter so wie beschrieben(Microsoft usw.).
Die .dll's und dll.manifest und MeetingExtendAddIn.vsto sind kopiert.
Leider nach dem Start Outlook deaktiviert Addin, addiert neu Registry Eintrag in HKCU unter Microsoft\Office\Outlook\AddIn: Key MeetingExtendAddIn - Value Loadbahavior(2) und schmeißt Fehler - "Ein Formularbereich kann nicht geöffnet werden. Das Formularbereichmanifest kann nicht gelesen werden. Überprüfen Sie, ob die datei vorhanden ist, und versuchen Sie es nochmal". Man kann sagen: Fehler ist eindeutig. Ok. Aber ich weiis es wirklich nicht was fehlt 😦 Die Form braucht auch ein manifest?
Form habe ich einfach in Visual Studio erstellt (Project add\New Windows Form\Outlook Form Region). Habe ich falschen Namen oder Wert für FormRegions Eintrag in Registry ausgewählt? Sollte ich noch etwas extra codieren oder einstellen?
Vielleicht hat es auch mit Form region nichts zu tun.
Ich habe wirklich viel gesucht und gelesen. Ich habe versucht den Installer für one User/all User einstellen, Registry Keys für 32 und 64 bit setzen, auch nur für 64 (was eigentlich falsch wäre). Nichts. Mit Code Signing und ohne....
Hilfe!!

PS. Wenn ich starte von Visual Studio läuft naturlich. Add In zeigt sich und funktioniert.

15.11.2013 - 08:21 Uhr

Moin,

stimmt, dass das Studio immer weiter mehr RAM frisst. Bedienen kann ich aber trotzdem immer....
Nach ne Woche hat ca. dreifacher "Anfangsverbrauch" 😃
Unsere Rechner laufen auch 24/7 - allerdings gibt es eine Regelung: Wenn Du deine Maschine länger als 10 Tage nicht neugestartet hast - wird automatisch am Wochenende rebootet.
Also wir starten dann unsere Entwicklungsrechner meinstens selber - irgendwann in der Woche, wenn es gerade passt: Update, patch, etwas anderes oder einfach so...

Grüß
Miro

06.11.2013 - 10:56 Uhr

Morgen,

Datum in int zu umwandeln ist eigentlich keine Besonderheit der Programmierssprache. Sehr oft benutzt, weil bei großen Datenmengen ist eine Suche in DB nach einem bestimmten Datum viel viel langsamer wie nach einer int-Zahl.
In meiner Arbeit speichern wir solche Infos sogar als Tagesnummer und Tagesminute getrennt in versch. Spalten. Und Auswertung findet direkt SQL serverseitig mit eigenen SQL Funktionen statt.
Weil auch verschiedene Zeitzonen beachtet sein müssen - in Db ist alles als UTC gespeichert.

In deinem Fall wird wahrscheinlich new Datetime ( wie herbivore vorgeschlagen hat) und z.B.

 Int64 n = Int64.Parse(date.ToString("yyyymmddhhMMss")); 

einzusetzen.

Grüß
Miro

04.11.2013 - 07:43 Uhr

Hmm,

for Schleife nicht unbedingt. Schau Mal auch unten:
Die Performance von C#-Programmen
Foreach solte ja schneller sein.

Grüß
Miro

04.11.2013 - 07:33 Uhr

Moin,

TabControl erst mit eine Property verbinden - die mit Deine Methode (oder eine Enum).
Kurzes Beispiel

  <TabControl Name="ArbeitsgangListeCtrl"
                        SelectedIndex="{Binding SelektierterArbeitsgangTabIndex, Mode=TwoWay}"> 

Im Code-Behind:
Property:


 private ArbeitsgangTabIndex selektierterArbeitsgangTabIndex;
      /// <summary>
      /// Selektierter Tab im Bereich Arbeitsgang
      /// </summary>
      public int SelektierterArbeitsgangTabIndex
      {
         get { return (int)selektierterArbeitsgangTabIndex; }
         set
         {
            selektierterArbeitsgangTabIndex = (ArbeitsgangTabIndex)value;
            RaisePropertyChanged( () => SelektierterArbeitsgangTabIndex );
         }
      }

Enum


 public enum ArbeitsgangTabIndex
      {
        Liste,
         /// <summary>
         /// Register Allgemein
         /// </summary>
         Allgemein,
         /// <summary>
         /// Register Details
         /// </summary>
         Details,
}

Methode


private void tabwechselArbeitsgang()
      {
         if( SelektierterArbeitsgangTabIndex != Enum.GetValues( typeof( ArbeitsgangTabIndex ) ).GetLength( 0 ) - 1 )
            SelektierterArbeitsgangTabIndex++;
         else
            SelektierterArbeitsgangTabIndex = 0;
      }

grüß
Miro

PS: RaisePropertyChanged kommt bei mir vom Prism, ersetze mit Deiner OnPropertyChanged.