UAC Steuerungsdialog Win10

[Dalai]

Zitat von EWeiss:

5. Und rendert die Rückgabe des Plugin in einem Window der Anwendung.

Und wie prüfst du, ob die Rückgabe erfolgreich war, d.h. etwas Benutzbares/Sinnvolles enthält?

Die Datei "C:\Program Files (x86)\Windows Media Player\Visualizations\MediaPlayer_10.dll" gibt's übrigens auf keinem meiner Systeme, weder Win10 noch Win7 (auf letzterem gibt's noch nicht einmal das Verzeichnis Visualizations). Aber das mag damit zusammenhängen, dass ich keinen WMP verwende.

Grüße
Dalai

[Delphi.Narium]

Neben dem ProcessMonitor gibt es bei SysInternals auch noch ein Programm FileMon.Exe.

Das kann ausführlich protokollieren, welche Datei von einem Prozess gesucht wird, welche geöffnet wird, Lese- und Schreiboperationen ...
Man kann dort sehen, ob die Suche nach einer Datei erfolgreich war oder eben nicht. Hier müsste man mal schauen, ob irgendwas als nicht erfolgreich protokolliert wird, wo gesucht wurde und wo hätte gesucht werden müssen.
Theoretisch müssten die Protokolle ja beim Aufruf aus der IDE und beim Aufruf ohne IDE identisch sein. Frage ist halt, gibt es Unterschiede und wenn ja, wie lassen sie sich begründen.

Weiß nicht, ob FileMon.exe eventuell mehr Infos liefert, als der ProcessMonitor. Man kann sich das Ergebnis in 'ne Datei schreiben lassen und darin dann gezielt suchen, ob es irgendwelche Unstimmigkeiten gibt.

Mir war nicht klar, dass Du das Arbeitsverzeichnis im Programm explizit setzt. In dem Falle ist / war mein Vorschlag natürlich für die Katz.

Zitat:

Was hat das Arbeitsverzeichnis damit zu tun das sich meine Anwendung in der IDE anders verhält als alleine?

Wenn z. B. das Arbeitsverzeichnis der IDE E:\Delphi\ wäre, wäre das Arbeitsverzeichnis des aus der IDE gestartete Programmes ebenfalls E:\Delphi\.
Startet man das Programm aber nicht aus der IDE und die Exe läge z. B. im Verzeichnis G:\MeineProgramme\, so wäre das Arbeitsverzeichnis in diesem Falle G:\MeineProgramme\.
Gibt es nun Abhängigkeiten zu DLLs, PlugIns oder sonstigen Dateien, so kann es passieren, dass sie, ausgehend vom Arbeitsverzeichnis E:\Delphi\, gefunden würden, aber ausgehend vom Arbeitsverzeichnis G:\MeineProgramme\ nicht.
Es könnte sich bei dem von Dir beobachteten Verhalten um eine derartige Konstellation handeln, muss es aber nicht. Es ist halt nur eine Idee für eine mögliche Fehlerursache, aber keinesfalls eine quasi für alle Umstände gültige Aussage.

Ich gehe nicht davon aus, dass es sich um einen Fehler im Compiler bzw. im generierten Code handelt, sondern um irgendein Konfigurations- und/oder Abhängigkeitsproblem, das sich in dieser Form nur unter Windows 10 Alpha ergibt.

[EWeiss]

Zitat von Dalai:

Zitat von EWeiss:

5. Und rendert die Rückgabe des Plugin in einem Window der Anwendung.

Die Datei "C:\Program Files (x86)\Windows Media Player\Visualizations\MediaPlayer_10.dll" gibt's übrigens auf keinem meiner Systeme, weder Win10 noch Win7 (auf letzterem gibt's noch nicht einmal das Verzeichnis Visualizations). Aber das mag damit zusammenhängen, dass ich keinen WMP verwende.

Grüße
Dalai

Wenn das Plugin nicht registriert bzw. Installiert wird ist es in meinem Player auch nicht vorhanden.
Von daher ist das erst einmal egal, nur wenn dann muss es auch funktionieren und das hat es bisher unter Win7 immer getan.

Zitat:

Und wie prüfst du, ob die Rückgabe erfolgreich war, d.h. etwas Benutzbares/Sinnvolles enthält?

Delphi-Quellcode:

function TWMPHelper.RenderWindowed(var pData: TimedLevel; fRequiredRender: Bool): Bool;

begin
  Result := False;
  try
    EnterCriticalSection(CritSect);

    if Assigned(_IWmpEffects2) then
      try
        if _IWmpEffects2.RenderWindowed(pData, fRequiredRender) = S_OK then
          Result := True;
      except
        Result := False;
      end;
  finally
    LeaveCriticalSection(CritSect);
  end;

end;

Sorry das ist uninteressant denn wie du sehen kannst wird ja innerhalb der IDE korrekt gerendert.
Aber nochmal.. nicht als eigenständige Exe.
Wenn ich also Debugge und hier true zurück geliefert wird ergibt das schon etwas sinnvolles.
Es ist in der Entwicklungsumgebung auch alles korrekt!
Nur ich kann schwerlich einen "Fehler" finden der in der Entwicklungsumgebung nicht existent ist aber ohne schon.

Zitat:

Mir war nicht klar, dass Du das Arbeitsverzeichnis im Programm explizit setzt. In dem Falle ist / war mein Vorschlag natürlich für die Katz.

Kein Problem bin ja froh über jeden Tip den ich bekommen kann. Danke nochmal.

Zitat:

Man kann dort sehen, ob die Suche nach einer Datei erfolgreich war oder eben nicht.

Das kann der ProcessMonitor auch er teilt mir auch mit das die Datei AlbumArt_{8888F348-E19F-44C3-B158-27605170DC2F}_Large.jpg nicht gefunden wurde.
Trotzdem rendert in der IDE das Plugin korrekt.

Zitat:

Wenn z. B. das Arbeitsverzeichnis der IDE E:\Delphi\ wäre, wäre das Arbeitsverzeichnis des aus der IDE gestartete Programmes ebenfalls E:\Delphi\.

Nicht wenn es als Release erstellt wurde dann hat das gesetzte Arbeitsverzeichnis keine Auswirkung.
Oder?

Zitat:

Gibt es nun Abhängigkeiten zu DLLs, PlugIns oder sonstigen Dateien, so kann es passieren, dass sie, ausgehend vom Arbeitsverzeichnis E:\Delphi\, gefunden würden, aber ausgehend vom Arbeitsverzeichnis G:\MeineProgramme\ nicht.

Ich muss da nix suchen also wo sich die DLL befindet.
Es ist eine ActiveX.dll und wird Systemweit registriert von daher sollte es egal sein welcher Arbeitspfad gesetzt ist.

Zitat:

sondern um irgendein Konfigurations- und/oder Abhängigkeitsproblem, das sich in dieser Form nur unter Windows 10 Alpha ergibt.

Ja leider, es scheint bald so zu sein Alpha halt.
Werde das wohl überarbeiten müssen erklärt aber immer noch nicht warum es in der IDE funktioniert.
Und wie soll man einen Fehler beheben der eigentlich nicht existiert das fuchst mich gewaltig.

gruss

[Delphi.Narium]

Zitat von EWeiss:

Zitat:

Man kann dort sehen, ob die Suche nach einer Datei erfolgreich war oder eben nicht.

Das kann der ProcessMonitor auch er teilt mir auch mit das die Datei AlbumArt_{8888F348-E19F-44C3-B158-27605170DC2F}_Large.jpg nicht gefunden wurde.
Trotzdem rendert in der IDE das Plugin korrekt.

Da muss ich jetzt mal nachfragen:

Wird sowohl aus der IDE als auch ohne IDE die Datei nicht gefunden, aber aus der IDE heraus trotzdem gerendert?
Gibt der ProcessMonitor auch eine Info zum vollständigen Pfad der Datei AlbumArt_{8888F348-E19F-44C3-B158-27605170DC2F}_Large.jpg aus?
Sind die Dateien immer mit absoluten Pfadangaben versehen oder gibt es eventuell auch relative Pfadangaben?

Wenn auch eventuell weit hergeholt:

Könntest Du mal die Umgebungsvariabeln des Programmes aufgerufen aus der IDE mit denen eines "Solo-Aufrufes" vergleichen. Eventuell gibt es da ja in der Path-Variabel ... oder sonstwo einen Unterscheid, der zu diesem seltsamen Seiteneffekt führt.

Der Processmonitor kann einem ja die von 'nem Prozess geladenen Module anzeigen, gibt es dort eventuell Unterschiede?

[EWeiss]

Zitat:

Wird sowohl aus der IDE als auch ohne IDE die Datei nicht gefunden, aber aus der IDE heraus trotzdem gerendert?

So ist es das ist ja mein Problem.

Zitat:

Sind die Dateien immer mit absoluten Pfadangaben versehen oder gibt es eventuell auch relative Pfadangaben?

Sind absolut und es ist immer der Pfad des Ordners in dem sich die MP3 befindet, also das Album.

Ich habe das log von der IDE und eigenständiger Anwendung abgespeichert und konnte keine Unstimmigkeiten entdecken.
Das einzige was ich dadurch festgestellt habe ist das die PRV also die Privaten Frames unter Win10 gebrochen sind. (werden nicht mehr erstellt und ausgewertet.)
Habe ich bereinigt und bekomme jetzt das Ergebnis siehe Shot.

Aber in der IDE wird das Cover gerendert nicht die leere Hülle.
Danke für deine Unterstützung.

Denke muss erstmal das Problem mit den fehlenden Cover beheben es wäre möglich das es dann korrekt läuft.
Erklärt aber immer noch nicht das aktuelle verhalten auch wenn es dann funktionieren sollte.

Wenn der OpenStatus sich ändert muss ich mir die GUID holen und das Cover abspeichern wenn nicht vorhanden.

Delphi-Quellcode:

var
  x: string;
begin
  x := currentMedia.getItemInfo('WM/WMCollectionID');

gruss

[TiGü]

Starte dein Programm bitte mal per rechter Maustaste -> Kontextmenü -> "Als Administrator ausführen".

Sollte dann die Cover angezeigt werden, dann wird bei dir oder innerhalb dieses Visualisierungs-Plug-In noch Schindluder in Sachen Rechte und Verzeichnisse betrieben.


Ggf. vielleicht auch die Abhängigkeit von den externen DLL lösen und selber das Cover aus der MP3 auslesen und anzeigen.
Da gibt es auch was für Delphi: https://www.delphipraxis.net/71449-mp3fileutils.html

[EWeiss]

Zitat von TiGü:

Starte dein Programm bitte mal per rechter Maustaste -> Kontextmenü -> "Als Administrator ausführen".

Sollte dann die Cover angezeigt werden, dann wird bei dir oder innerhalb dieses Visualisierungs-Plug-In noch Schindluder in Sachen Rechte und Verzeichnisse betrieben.
[/url]

Danke habe ich schon versucht das macht keinen Unterschied.

Zitat:

Ggf. vielleicht auch die Abhängigkeit von den externen DLL lösen und selber das Cover aus der MP3 auslesen und anzeigen.

Ich kann nicht in das Plugin selbst eingreifen das Cover selbst auslesen ist kein Problem aber die DLL macht am ende doch was sie will.

Ich muss es über den Media Player selber lösen wie im Beispiel gezeigt.

gruss

[jaenicke]

Zitat von Delphi.Narium:

Neben dem ProcessMonitor gibt es bei SysInternals auch noch ein Programm FileMon.Exe.

FileMon ist der Vorgänger des ProcessMonitors. Damals gab es den neben RegMon usw. einzeln, das kann nun alles der ProcessMonitor.

Kannst du die Logs vielleicht zeigen?

[EWeiss]

Zitat:

Kannst du die Logs vielleicht zeigen?

Leider nein.. 120MB und aufwärts die letzte ist 364 MB

gruss

[EWeiss]

So habe das Problem jetzt gelöst (Nein nicht das mit Delphi warum auch immer es hier in der IDE funktioniert hat)

Unter Win7 habe ich mit meinem PrivframesWriter die Frames auf diese weise in die Mp3 Dateien geschrieben.

Delphi-Quellcode:

for i := 1 to 16 do
begin
  b := Random(255);
  GUID.Write(b, 1);
end;

v23Tag.SetPrivateFrame('WM/WMCollectionID', GUID);
v23Tag.SetPicture('image/jpeg', 0, '*', PicData);
v23Tag.WriteToFile(mp3file);

Das hatte zur folge das jede Datei mit einer anderen GUID erstellt wurde.
Hier lag der erste Fehler denn für ein Album egal welche Dateien geladen werden muss die GUID immer gleich sein.

Unter Win7 schien das aber egal zu sein es hat immer funktioniert.
Nun habe ich es so abgeändert.

Delphi-Quellcode:

for i := 1 to 16 do
begin
  b := 0
  GUID.Write(b, 1);
end;

v23Tag.SetPrivateFrame('WM/WMCollectionID', GUID);
v23Tag.SetPicture('image/jpeg', 0, '*', PicData);
v23Tag.WriteToFile(mp3file);

jetzt ist es egal welches Album bzw. Datei das Frame enthält.
Die GUID ist jetzt immer AlbumArt_{00000000-0000-0000-0000-000000000000}_Large.jpg

So muss sich niemand damit rumschlagen nach der richtigen zu suchen damit das Picture korrekt angezeigt wird.
Befindet sich kein Frame (GUID) innerhalb der Datei nun dann wird die leere Hülle angezeigt.
Damit kann ich leben.

Wenn nun jemand das Cover der jeweiligen MP3 anzeigen möchte muss die GUID addiert und ein Picture mit der NullGuid im Albumpfad vorhanden sein.

Habe jetzt noch zusätzlich das schreiben der AlbumArt_{00000000-0000-0000-0000-000000000000}_Large.jpg automatisiert.
Bei 100'ten von Alben ist das zu mühselig von Hand zu machen.

Delphi-Quellcode:

        v23Tag.SetPrivateFrame('WM/WMCollectionID', GUID);
        v23Tag.SetPicture('image/jpeg', 0, '*', PicData);
        v23Tag.WriteToFile(mp3file);

        if Path <> OldPath then
        begin
          if FileExists(Path + 'AlbumArtSmall.jpg') and not
            FileExists(Path + 'AlbumArt_' + NullGUID + '_Large.jpg') then
          begin
            try
              JpgIn := TJPEGImage.Create;
              JpgOut := TJPEGImage.Create;
              JpgIn.LoadFromFile(Path + 'AlbumArtSmall.jpg');
            finally
              JpgOut.Assign(JpgIn);
              JpgOut.SaveToFile(Path + 'AlbumArt_' + NullGUID + '_Large.jpg');
              JpgIn.Free;
              JpgOut.Free;
              OldPath := Path;
            end;
          end;
        end;

gruss