6 replies to this topic

[meiru]

Ok, ich geb auf... die Doku ist in keiner Weise verständlich.

 

WAS muss man tun, damit ein EmbeddedUI angezeigt wird? Ich bekomm zwar eines angezeigt, wenn ich jetzt z.B. einfach einen Dialog aufmach im InitializeEmbeddedUI... aber das ist ja nicht die Idee (glaub ich zumindest)... oder ist genau das die Idee? Ich mein, da steht so etwas wie "wenn die Funktion 0 zurückgibt, dann ist alles in Ordnung und es werden weiter Aufrufe an diese Dll gesendet) ... nur was heisst das? Ich bekomm nie eine Nachricht im Sinne von "zeig das GUI jetzt an"... ich bekomm bloss die Info per EmbeddedUIHandler, dass die Action "INSTALL" gestartet wurde... und dann läuft alles komplett ohne GUI ab... also, wo wann und wieso zum Henker muss ich was tun, damit das blöde GUI angezeigt wird und wieso können die MSDN Typen nicht mindestens dieses kleine winzige und so unglaublich unwichtige Detail nicht so erwähnen, dass man es auch findet?

 

In dieser blöden Doku wimmelt es von solchem Blödmist wie z.B. beim MsiRecordGetString -> when the function returns, this value contains the amount or characters copied to the buffer, not including the 0 terminating character... ok... jetzt wissen wir was dieser Count enthält... aber wurde dieses blöde Zeichen trotzdem geschrieben oder nicht? ... tja, da kann man raten... irgendwo steht dann aber der Hinweis, man solle nicht nach dem Zeichen suchen, sondern den ominösen Wert als Länge verwenden... muss man jetzt da draus schliessen, dass es kein NULL am Ende hat? ... egal, ich sag nur -> die Doku ist so unnütz wie irgendwas und das seit es den Windows Installer gibt...

 

Ich hoffe irgend ein Insider kann mich zumindest über das UI-Problem aufklären.

 

danke... Rudolf

[meiru]

Die Zeile

 

    // Setting the internal UI level to none specifies that
    // no authored UI should run.
    *pdwInternalUILevel = INSTALLUILEVEL_NONE;

 

im Beispiel wie man ein embedded UI verwendet (aus dem MSDN) ist doch völliger Sch...!!! Wenn ich das tue bekomme ich gar nichts mehr! Das ist das Problem! Jede Wette das ist nicht so, sondern genau andersrum?

 

Die Doku ist also nicht nur lückenhaft, sondern beschreibt genau wie man es NICHT machen soll!! Das nenne ich fast schon arglistige Täuschung! Verdammt, das hat mich einen ganzen Tag gekostet!

 

Rudolf

 

[meiru]

*hmm* ... vielleicht meinen die das doch anders... evtl. ist doch die Idee, das ganze UI im InitializeEmbeddedUI drin ablaufen zu lassen? Blöd ist dann nur, dass in so einem Fall die ganze InstallUISequence übersprungen würde, bzw. man die... weiss nicht, manuell aufrufen müsste? ... also ich bleib dabei... egal wie es nun gedacht ist, das ganze ist so undurchsichtig... und ein Rätselraten... kaum auszuhalten. Ich dachte zuerst, dass die CryptoAPI blöd ist... aber dann fand ich Sockets... und jetzt den Windows Installer... mal sehen ob's noch 'ne Steigerung gibt... wär zwar schon extrem schwierig.

[meiru]

Also ...   ... ganz ehrlich, ich will wissen was die im MSI Team rauchen. Das muss verdammt guter Stoff sein. Und die Typen, die das in der Qualitätskontrolle und beim Betatest durchwinken... unheimlich. Ich habe jetzt diesen Müll laaaange angesehen und komme zum Schluss, dass es absoluter Blödsinn ist. Das Produkt, so wie es vorliegt und beschrieben wird, ist völlig nutzlos! Weil man damit schlicht das Ziel nicht erreichen kann, welches man damit erreichen will. Wenn ich nämlich während der UI-Phase NICHT auf die Datenbank vom MSI zugreifen kann, dann kann ich z.B. die Feature-Installations-Optionen NICHT setzen und ohne diese Fähigkeit ist das Setup schlicht absolut sinnlos!

[Stefan Krueger]

Also, ich kann leider nicht direkt helfen, weil ich mich auf dieses Abenteuer noch nicht eingelassen habe. Aber ich dachte, das Ganze läuft über Messages.

Vielleicht hilft dir das Buch "Inside Windows Installer 4.5" von Andreas Kerl ( http://www.installsi....htm#msi45_buch ). Er hat ein Kapitel über External UI und Embedded External UI geschrieben.

[meiru]

Danke, ist ok... ich hab's jetzt gefunden. Das EmbeddedUI darf und kann man nicht nutzen für den Teil, in dem man User-Abfragen macht. Dafür ist es schlicht nicht nutzbar.

 

Begründung:

 

Vor der InstallUISequence wird InitializeEmbeddedUI aufgerufen.

 

Würde ich jetzt hier mein GUI anzeigen, läge ich noch VOR der InstallUISequence, ich hätte also keine Ahnung über Feature-States und all so Zeugs. Das müsste man nun manuell machen (und MsiDoAction hilft nicht, weil sich das mit dem Handle den man bekommt nicht aufrufen lässt). Man müsste praktisch die ganze Funktionalität vom Installer nachbauen.

 

Also, die Idee ist daher, das GUI nicht abzuschalten, sondern zu überschreiben (pdwInternalUILevel belassen wie er ist, dann läuft auch die InstallUISequence normal ab), wenn ein Dialog aufgerufen wird. Gut... tut man das, bekommt man in der aufgerufenen Funktion EmbeddedUIHandler die Chance. Nur... wenn ich da drin bin, habe ich keinen Handle mehr auf den Installer oder die Database. Also wie soll ich zu dieser Zeit jetzt die Features abfragen um sie anzuzeigen? Richtig, es geht nicht... vollkommen aussichtslos.

 

Egal was man tut, mit dem EmbeddedUI geht's nicht... alles was man tun kann ist, die Error-Dialoge und den Progress-Dialog überschreiben und behandeln. Den Rest muss man z.B. über CustomActions lösen, die dann ganz normal im InstallUISequence ablaufen müssen. Da kommt man dann auch an alle nötigen Handles und Zustände vom Installer ran. Das GUI muss also zweigeteilt sein.

 

Wieso man im EmbeddedUIHandler keinen brauchbaren Handle bekommt ist für mich ein Rätsel... dadurch wird die ganze Schnittstelle fast unbrauchbar. Aber es hat ja noch andere komische Sachen im MSI... z.B. kann eine CustomAction, die zur Script-Zeit läuft, nicht lesend auf die MSI Datei zugreifen um Daten rauszuholen... verstehe das wer will... dadurch ist das Setup doch schlicht unnütz. Wir kopieren jetzt den ganzen Mist aus den Tabellen in temporäre Dateien (zur UI-Zeit) und räumen die später dann ab (zur Script-Zeit), wenn wir sie genutzt haben... völlig umständlich, fehleranfällig und nur doof.

 

Aber leider bekomme ich unser Setup-Projekt ohne Custom-UI nicht hin... nur schon die Eingabe des Produkt-Keys ist unmöglich und wenn wir dann noch ein paar andere Wünsche haben wie Aktivierung oder Download von einem Update, dann wird's gleich super umständlich... daher musste ich mich auf dieses Spielchen einlassen.

 

... eine unschöne Sache bleibt allerdings noch. Auf die Art haben wir es mit 3 Prozessen vom Windows Installer zu tun. Und... der Wechsel von Fenster zu Fenster ist eine riesen Flackerei. Kann sein, dass man das irgendwie in den Griff bekommen kann, evtl. aber auch nicht... bei mir gehen jetzt zum Beispiel die Fenster manchmal hinter anderen Anwendungen auf... ist sehr ärgerlich und vielleicht sogar unlösbar... das reisst einem den letzten Nerv aus das blöde Teil.

 

Rudolf

Edited by meiru, 25 September 2013 - 20:15.

[MegDino]

Moin!

 

Ich habe mit dem EmbeddedUI auch meine Probleme gehabt und ja, die Doku ist kacke! Was ich gemacht habe ist folgendes (allgemein gesagt): Wir haben eine eigene Setup.exe gebaut, mit eigenem UI. Dort fragen wir den Anwender, was wir von ihm wissen wollen. Die UI-Sequenz des MSI-Paketes verwenden wir somit nicht! Wir müssen also daruaf achten, dass wird dort keine wichtigen CustomActions unterbringen. Soweit wie möglich wird alles vorab von der Setup.exe erledigt. Wenn diese alles zusammengesammelt hat, erzeuge ich daraus eine schöne Kommandozeile für den Installationsaufruf über die MSI-API (MsiInstallProduct(...) etc.). Wenn man hier nicht über die API geht, sondern msiexec direkt aufruft, erhält man keine einzige Message über den external UI handler. Den UI-Handler benutzen wir nun lediglich, um den Installations-Fortschritt in unserem Setup.exe-UI anzuzeigen, also einen netten Progressbar. Das klappt auch (fast) fehlerfrei. Nur deshalb "fast", weil beim Entfernen von Dateien während eines Uninstalls der Progress nicht immer auf 100% initialisiert wird, wenn der Progress rückwärts laufen soll. Somit "zappelt" während der Entfernens ein 1-2 Pixel breiter Progressbar am linken Rand rum. Das ist somit der Punkt der Doku, den ich bis heute nicht verstanden habe

Wenn du nun Details über die Implementierung brauchst, kann ich gerne weiterhelfen.

 

Gruß

Meg

Edited by MegDino, 08 October 2013 - 10:43.