![]() |
AW: UAC Steuerungsdialog Win10
Zitat:
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 |
AW: UAC Steuerungsdialog Win10
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:
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. |
AW: UAC Steuerungsdialog Win10
Zitat:
Von daher ist das erst einmal egal, nur wenn dann muss es auch funktionieren und das hat es bisher unter Win7 immer getan. Zitat:
Delphi-Quellcode:
Sorry das ist uninteressant denn wie du sehen kannst wird ja innerhalb der IDE korrekt gerendert.
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; 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:
Zitat:
Trotzdem rendert in der IDE das Plugin korrekt. Zitat:
Oder? Zitat:
Es ist eine ActiveX.dll und wird Systemweit registriert von daher sollte es egal sein welcher Arbeitspfad gesetzt ist. Zitat:
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 |
AW: UAC Steuerungsdialog Win10
Zitat:
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? |
AW: UAC Steuerungsdialog Win10
Zitat:
Zitat:
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 |
AW: UAC Steuerungsdialog Win10
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: ![]() |
AW: UAC Steuerungsdialog Win10
Zitat:
Zitat:
Ich muss es über den Media Player selber lösen wie im Beispiel gezeigt. gruss |
AW: UAC Steuerungsdialog Win10
Zitat:
Kannst du die Logs vielleicht zeigen? |
AW: UAC Steuerungsdialog Win10
Zitat:
gruss |
AW: UAC Steuerungsdialog Win10
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:
Das hatte zur folge das jede Datei mit einer anderen GUID erstellt wurde.
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); 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:
jetzt ist es egal welches Album bzw. Datei das Frame enthält.
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); 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:
gruss
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; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:57 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz