UAC Steuerungsdialog Win10

[EWeiss]

Wie kann ich den Dialog unter Windows 10 unterbinden.

Mit meiner neuen Hardware kann ich leider kein Win7 mehr installieren (Danke Intel, MS und Konsorten)
Jetzt muss ich mich mit dem Mist doch beschäftigen.

Wenn ich die UAC nicht ausschalte und BDS.exe nicht als Admin starte kann ich meine Anwendungen nicht kompilieren.
Bei jedem Start kommt jetzt der nervige UAC Dialog (als wenn man nichts anderes zu tun hätte als den immer wieder zu bestätigen)

Ist die UAC aus und ich starte BDS ohne Admin rechte kommen unten im Anhang angehängten Fehler.

Keine meiner Anwendungen funktioniert vernünftig ohne den Eintrag im Manifest.

Code:

  <!-- Windows Vista application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>

Wie machen die anderen Anwendungen dass das sie trotzdem richtig ausgeführt werden mit allen rechten die benötigt werden.

Ein einfaches Beispiel.
Ich starte die ID und mein Projekt, funktioniert alles korrekt so wie es soll.
Beendet ich Delphi und starte die Anwendung mit den besagten Eintrag im Manifest werden mir keine Cover mehr in meinem Player angezeigt.
Das funktioniert aber innerhalb der IDE beim kompilieren bzw. ausführen der Anwendung.

Anders Beispiel.
Ich öffne die IDE mit einem xbeliebigen Projekt *.dproj
Die ID ist offen jetzt starte ich eine neues Projekt damit dieses in die IDE eingefügt wird.
Pustekuchen.. tut sich nix (war unter Win7 nie ein Problem)
Kann also nur immer 1 Projekt zur gleichen zeit öffnen.

Dieses OS macht ärger wo es nur geht.
Kann es sein das ich einfach zu blöd dafür bin oder habt ihr die gleichen Probleme.

PS:
Für alle die kein Win10 verwenden möchten.
Kauft euch kein Board mit Intel Prozessor und informiert euch besser OB das auch mit Win7 kompatible ist.
Tut ihr das nicht dann steht ihr auf dem Schlauch.

gruss

[Delphi.Narium]

Eventuell: https://winaero.com/blog/how-to-turn...in-windows-10/

[EWeiss]

Zitat:

Zitat von Delphi.Narium (Beitrag 1421693)

Eventuell: https://winaero.com/blog/how-to-turn...in-windows-10/

Sorry das ist keine Lösung sondern Unfug. (Wenn ich dich richtig verstanden habe)
Das die Dialoge nicht angezeigt werden wenn ich die UAC deaktiviert ist mir klar.

Aber!
Deaktiviere ich die UAC dann werden keine entsprechenden Rechte für das jeweilige Programm zugewiesen.
Von daher ist das keine Lösung.

Was mich wundert warum wird der Dialog jedes mal wieder angezeigt dem System müsste doch bekannt sein welche Rechte das Programm hat nachdem der Dialog einmalig aufgerufen wurde.
Unter Win7 habe ich die BDS niemals mit Admin rechten starten müssen (Wenn UAC ausgeschaltet wurde) und es hat funktioniert.
Hier geht gar nichts unabhängig davon ob die UAC eingeschaltet ist oder nicht.
Keine Admin rechte Delphi funktioniert nicht.

gruss

[Bernhard Geyer]

Deine Projekte liegen unter "C:\Programme"
Das erklärt praktisch alle deine Probleme.

Bei passender Rechtevergabe hättest du schon mit Windows NT 3.1 nicht arbeiten können und ähnliche Fehler bekommen

[EWeiss]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1421700)

Deine Projekte liegen unter "C:\Programme"
Das erklärt praktisch alle deine Probleme.

Bei passender Rechtevergabe hättest du schon mit Windows NT 3.1 nicht arbeiten können und ähnliche Fehler bekommen

Nein sie liegen unter "C:\Programme (x86)"

Und ich frage mich warum das nicht sein darf?
Es sind 32Bit Anwendungen.. wo bitte soll ich sie sonst ablegen.
Ich kenne Hunderte von Programmen die sich dort befinden und die funktionieren alle.

bsp.
Ich erstelle ein Projekt (Portable APP) und veröffentliche es.
Nun kopiert der User die Anwendung unter Programme (x86).
So wie kann ich dann garantieren das die Anwendung bei ihm überhaupt läuft wenn ich als Programmierer nicht feststellen kann wohin er sie kopiert.

Es kann doch nicht sein das die funktionsweise eines Programm davon abhängig ist wohin man sie kopiert.

gruss

[TiGü]

Zitat:

Kann es sein das ich einfach zu blöd dafür bin...

Ja, denn es ist genauso wie es Bernard beschreibt.
Auf die Idee, Delphi-Projekte und Quelltexte unterhalb des VS-Ordners im Programme-Verzeichnis zu speichern...wie kommt man dazu? :shock:

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1421706)

Zitat:

Kann es sein das ich einfach zu blöd dafür bin...

Ja, denn es ist genauso wie es Bernard beschreibt.
Auf die Idee, Delphi-Projekte und Quelltexte unterhalb des VS-Ordners im Programme-Verzeichnis zu speichern...wie kommt man dazu? :shock:

Was für ein VS-Ordner. ? Und wohin sonst?
Nochmal zum besseren Verständnis.

Debugge ich die Anwendung mit Delphi funktioniert alles wenn BDS.exe mit Admin rechten und eingeschalteter UAC gestartet wird.
Ich habe mein Manifest addiert so wie gezeigt.
Aber egal in welchem Ordner sich nachher die Anwendung befindet und mit Admin Rechten gestartet wird funktioniert sie nicht wie sie soll.
Obwohl beim debuggen alles in Ordnung ist.

Das Problem kenne ich aber nur unter Win10.

Zitat:

wie kommt man dazu?

Wer schreibt das vor das ich es nicht darf?
Und selbst wenn wo hin dann bitte sonst?

Du selbst hast doch gar keine Kontrolle darüber abgesehen von einer über ein Setup installiert Anwendung wohin der User die Anwendung kopiert.

Zitat:

Bei passender Rechtevergabe

Was verstehst du unter passender ?

gruss

[hoika]

Hallo,

Zitat:

Nun kopiert der User die Anwendung unter Programme (x86).

Ein User kopiert keine Anwendung, sondern installiert sie.
Dabei werden die erforderlichen Rechte vom Setup-Programm gesetzt.
Schreibrechte im Programme/Verzeichnis sind nicht erlaubt.

Wahrscheinlich hattest Du die Rechte unter Programme unter Win7 mal geaendert,
damit das laeuft.

[EWeiss]

Zitat:

Zitat von hoika (Beitrag 1421708)

Hallo,

Zitat:

Nun kopiert der User die Anwendung unter Programme (x86).

Ein User kopiert keine Anwendung, sondern installiert sie.
Dabei werden die erforderlichen Rechte vom Setup-Programm gesetzt.
Schreibrechte im Programme/Verzeichnis sind nicht erlaubt.

Wahrscheinlich hattest Du die Rechte unter Programme unter Win7 mal geaendert,
damit das laeuft.

Nein ist definitiv nicht so.
Denn meine Anwendungen sind alle Portable.
Die benötigen kein Setup.

Es kann auch niemand einen Developer dazu zwingen ein Setup für jede Datei zu erstellen oder?
Wie verhält sich das dann mit Portable Anwendungen die dürften dann alle nicht laufen.
Unter Win7 habe ich dergleichen nichts getan.

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1421704)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1421700)

Deine Projekte liegen unter "C:\Programme"
Das erklärt praktisch alle deine Probleme.

Bei passender Rechtevergabe hättest du schon mit Windows NT 3.1 nicht arbeiten können und ähnliche Fehler bekommen

Nein sie liegen unter "C:\Programme (x86)"

Programme / Programme(x86) ist völlig egal, weil beide Verzeichnise vom Betriebssystem geschützt werden. Deine Screenshots mit den Fehlermeldungen sind auch keine Meldungen deiner Programme, sondern deiner IDE, die ohne Admin-Rechte keine Schreibrechte hat.
Da könntest du auch gleich in C:\Windows die Quelltexte und die Kompilate ablegen, dass ist dann genauso "clever".

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1421710)

Zitat:

Zitat von EWeiss (Beitrag 1421704)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1421700)

Deine Projekte liegen unter "C:\Programme"
Das erklärt praktisch alle deine Probleme.

Bei passender Rechtevergabe hättest du schon mit Windows NT 3.1 nicht arbeiten können und ähnliche Fehler bekommen

Nein sie liegen unter "C:\Programme (x86)"

Programme / Programme(x86) ist völlig egal, weil beide Verzeichnise vom Betriebssystem geschützt werden. Deine Screenshots mit den Fehlermeldungen sind auch keine Meldungen deiner Programme, sondern deiner IDE, die ohne Admin-Rechte keine Schreibrechte hat.
Da könntest du auch gleich in C:\Windows die Quelltexte und die Kompilate ablegen, dass ist dann genauso "clever".

Ändert nichts daran das die Anwendungen trotz Adminrechte nicht so laufen wie sie sollen mal unabhängig davon wo ich sie Kompiliere\erstelle.


gruss

[TiGü]

Öffne die IDE ganz normal ohne Admin-Rechte. Baue ein Hello World Programm und speichere es explizit in einen Ordner unterhalb des Dokumente-Ordners. Auch den Ausgabepfad lassen wir so wie er ist und damit also unterhalb des Dokumente-Ordners. Lasse das Manifest so wie es die IDE erzeugt ohne Änderung.
Builde das Programm und starte es über den Dateiexplorer deiner Wahl per Doppelklick.

Das Programm wird ohne Murren und Knurren starten und funktionieren.

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1421712)

Öffne die IDE ganz normal ohne Admin-Rechte. Baue ein Hello World Programm und speichere es explizit in einen Ordner unterhalb des Dokumente-Ordners. Auch den Ausgabepfad lassen wir so wie er ist und damit also unterhalb des Dokumente-Ordners. Lasse das Manifest so wie es die IDE erzeugt ohne Änderung.
Builde das Programm und starte es über den Dateiexplorer deiner Wahl per Doppelklick.

1. Ich erstelle kein Manifest über die IDE. (Weil ich zusätzliche Informationen darin ablegen muss) Siehe!
Zudem verwende ich keine Resource die mich dazu veranlasst das Manifest mit der IDE zu erstellen.
Was soll also anders sein es sollte keine rolle spielen wie ich das Manifest erstelle.

Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <description>SoundMachine</description> 

  <!-- Windows Vista application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>

  <!-- Mildrop Visualisation support -->
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" 
        version="9.0.21022.8" 
        processorArchitecture="x86" 
        publicKeyToken="1fc8b3b9a1e18e3b">
      </assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
     <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" 
        version="6.0.0.0" processorArchitecture="X86" 
        publicKeyToken="6595b64144ccf1df" 
        language="*">
      </assemblyIdentity>
     </dependentAssembly>
  </dependency>
  <!-- End of Mildrop Visualisation support -->


  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
    <application> 
      <!--The ID below indicates app support for Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
      <!--The ID below indicates app support for Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
      <!--The ID below indicates app support for Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
      <!--The ID below indicates app support for Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
      <!--The ID below indicates app support for Windows 10 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>         
    </application> 
  </compatibility>
</assembly>

2. Ich habe die Adminrechte von Delphi entfernt.
3. Den Source nach Dokumente kopiert.
4. IDE gestartet und diese Meldung (error.png) bekommen wenn ich mein Manifest mit Adminrechten ausstatte (requireAdministrator).
5. Wenn ich es mit asInvoker in der IDE starte funktioniert es.
6. Starte ich sie alleine geht nichts. egal ob mit asInvoker oder requireAdministrator aus dem Pfad Dokumente heraus.

So nun frage ich mich abgesehen davon das ich BDS.exe nicht mehr mit Adminrechten starte nun anders sein soll.
Denn es funktioniert nicht.
Egal ob ich die Anwendung unter Programm oder Dokumente starte.
Aber wie du siehst geht es innerhalb der IDE beim Debuggen bzw. Ausführung.

Zitat:

Das Programm wird ohne Murren und Knurren starten und funktionieren.

Nein tut es nicht.

Wie gesagt mit dem Manifest dort oben startet das Projekt erst gar nicht. (IDE)
Dazu muss ich das Manifest erst mit asInvoker ausstatten.

gruss

[Fritzew]

Hallo Emil,
Kannst Du mal erklären warum Deine Programme Administrator Rechte benötigen?
Das sollte nur in den seltensten Fällen nötig sein

[EWeiss]

Zitat:

Zitat von Fritzew (Beitrag 1421717)

Hallo Emil,
Kannst Du mal erklären warum Deine Programme Administrator Rechte benötigen?
Das sollte nur in den seltensten Fällen nötig sein

Weil ich annehme das es daran liegt warum die Covers nicht angezeigt werden.

Denn in der IDE funktioniert es ja.

Auch mein Programm OTTB64 funktioniert ohne Admin rechte nicht.
Die Probleme hatte ich vorher alle nicht unter Win7.

gruss

[Fritzew]

Ich behaupte das liegt zu 100% nicht an den Rechten.
Du weist wie Du mich erreichen kannst, ich will hier nicht Öl ins Feuer legen,
aber zuerst einmal, da gebe ich meinen Vorrednern recht, Deine Projekt gehören auf keine Fall in irgend eine Program* Ordner.

Dann: Wenn die IDE als Usr läuft kann Sie keine AdminProcess starten, gewollt und richtig. Das muss schief gehen: IDE User Programm Admin.

Also Du hast meine Adresse.

Gruss Fritz

[EWeiss]

Zitat:

aber zuerst einmal, da gebe ich meinen Vorrednern recht, Deine Projekt gehören auf keine Fall in irgend eine Program* Ordner.

Dem will ich nicht widersprechen wenn es darum geht wo die Dokumente besser aufgehoben sind um damit arbeiten zu können ohne Adminrechte.

Es sollte aber egal sein wo sie am ende ausgeführt werden.
Denn bds.exe als Beispiel liegt auch unter Programme (x86) und wird dort ausgeführt warum darf ich meine Soundmachine oder andere Anwendungen von mir dort nicht ausführen?
Die Einstellungen werden ja alle unter Roaming abgespeichert von daher dürfte es eigentlich egal sein wo und in welchem Pfad diese liegen.

Aber alle x64 Anwendungen laufen ohne Adminrechte nicht.
Und werden auch nicht gestartet wenn sie zum Beispiel in Autostart Ordner liegen. (OTTB64)

Zitat:

Du weist wie Du mich erreichen kannst, ich will hier nicht Öl ins Feuer legen,

Sie liefen ja alle unter Win7 ohne Probleme.
Woran soll es sonst liegen wenn nicht an den Adminrechten.

gruss

[TiGü]

Welchen Teil von "Lasse das Manifest so wie es die IDE erzeugt ohne Änderung.", hast du nicht verstanden?
Einfach nicht daran herumfummeln. Lasse dein Manifest einfach weg.

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1421721)

Welchen Teil von "Lasse das Manifest so wie es die IDE erzeugt ohne Änderung.", hast du nicht verstanden?
Einfach nicht daran herumfummeln. Lasse dein Manifest einfach weg.

Nein lasse ich nicht denn du scheinst es nicht zu verstehen.
Nochmal extra für dich!

Code:

<!-- Mildrop Visualisation support -->
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" 
version="9.0.21022.8" 
processorArchitecture="x86" 
publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" 
version="6.0.0.0" processorArchitecture="X86" 
publicKeyToken="6595b64144ccf1df" 
language="*">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<!-- End of Mildrop Visualisation support -->

funktionieren Meine Visualisierungen nicht! Alles klar?
Ich hoffe du hast mich jetzt verstanden warum ich das nicht kann.
Es besteht kein Grund das Manifest über die IDE zu erstellen zumal dieses in D2010 eh nicht viel hergibt.. das ist nicht "DCE"

gruss

[TiGü]

Was auch immer "DCE" bedeuten soll?!
Ist dir schon mal aufgefallen, dass du von uns ganz viel Vorwissen erwartest, was deine Programme können, tun und machen sollen?
Funktioniert das für dich im echten Leben?
Oder schnauzst du die Bäckersfrau auch an, weil sie dir dein Bestellwunsch nicht von den Lippen ab liest?

Wenn du der Meinung bist, dass es nicht ohne geht (ist damit das Milkdrop Musikvisualisierungs-Plugin gemeint? Es fehlt das k im XML-Kommentar), dann kommentiere doch zumindest testweise den gesamten trustInfo-Node aus.

[Dalai]

Relative Pfade oder ähnliches könnten auch für das Problem verantwortlich sein. Solltest du halt debuggen, und zwar ohne Adminrechte.

Grüße
Dalai

[EWeiss]

Zitat:

Was auch immer "DCE" bedeuten soll?!

Delphi Community Edition.

Zitat:

Ist dir schon mal aufgefallen, dass du von uns ganz viel Vorwissen erwartest, was deine Programme können, tun und machen sollen?

Enschuldige..
Ist dir schon aufgefallen das du immer irgendwie versuchst deinen Standpunkt durchzusetzen?
Was ist da nicht zu verstehen das ich das Manifest nicht mit der IDE erstellen will? Es hat einen Grund!

Zitat:

Welchen Teil von "Lasse das Manifest so wie es die IDE erzeugt ohne Änderung.", hast du nicht verstanden?

Sei doch mal ehrlich irgendwie ist deine Antwort nicht höfflich oder?
Sorry bin kein Klein Kind und verstehe schon.

Zitat:

Oder schnauzst du die Bäckersfrau auch an, weil sie dir dein Bestellwunsch nicht von den Lippen ab liest?

Wer hat dich angeschnauzt? (Zeige mir bitte den Beitrag wo das der Fall gewesen sein soll)
Ich zumindest nicht!

Diese Art der ungerechtfertigten Anschuldigen ist das was mich immer auf die Palme bringt.
Lass gut sein habe keine Lust wegen dir wieder gebannt zu werden.
Ich habe meine lehren daraus gezogen und weis das man aufpassen muss was man sagt.. egal wie gerechtfertigt es ist.

Zitat:

Wenn du der Meinung bist, dass es nicht ohne geht (ist damit das Milkdrop Musikvisualisierungs-Plugin gemeint? Es fehlt das k im XML-Kommentar), dann kommentiere doch zumindest testweise den gesamten trustInfo-Node aus.

Ja.. das Milkdrop Musikvisualisierungs-Plugin
Kann ich mal versuchen und werde berichten.

gruss

[Bernhard Geyer]

Ich gebe dir den Tipp:

1, Während der Entwicklung speichere alle Projektdateien (*.pas, *.dfm, *.exe, *.dcu, ...) außerhalb von "c:\programme"

2, Während der Programmausführung speichere keine Dateien in deinem Anwendungsverzeichnis. Nehme hier die seit Jahrzehnten dafür vorgesehenen
Verzeichnisse wie %Appdata% oder C:\ProgramData

3, Nur wenn du spezielle Fehler nachstellen willst kompiliere deine Anwenung nach "c:\Programme".
Wenn Du 2 beherzigst hast du auch keine Problem damit das etwas anders ist je nachdem ob die IDE mit oder ohne Adminrechte gestartet ist.

[EWeiss]

Danke.

zu 1. Habe ich beherzigt und habe alle Projekte in den Dokumenten Ordner verschoben.
zu 2. Ich verwende %APPDATA\Roaming

Die Delphi IDE läuft nun richtig mit deinem Tip's ohne Adminrechte.

Aber löst immer noch nicht das Problem mit meinem Anwendungen.

Muss mich da noch schlau machen was da falsch läuft.
Die haben unter Win7 alle funktioniert auch ohne Adminrechte.

gruss

[EWeiss]

Habe jetzt alles soweit am laufen unter W10 ohne irgendwelche Adminrechte aber meine Anwendung funktioniert nur richtig wenn ich sie in der IDE mit Delphi ausführe.
Versteh nicht warum das als eigenständige Anwendung dann nicht mehr funktioniert :stupid:

Welche rechte könnten da fehlen?
Die Mp3 Dateien liegen auf einer anderen Platte der zugriff ist also gewährt. (Kein Schreibschutz nichts)
Meine Anwendung starte ich unter Dokumente.

Keine Ahnung was das Problem verursachen könnte.
Habe nochmal 2 Pics angehängt.

Also was macht Delphi anders als meine Anwendung wenn sie alleine läuft? :wall:

gruss

[HolgerX]

Hmm..

In welchem Verzeichnis werden die Cover vor der Anzeige abgelegt?
Ist dort vielleicht ein festes Verzeichnis eingetragen?

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1421791)

Also was macht Delphi anders als meine Anwendung wenn sie alleine läuft? :wall:

Das Arbeitsverzeichnis könnte in Delphi anders gesetzt sein (Start --> Parameter).

Ansonsten benutzen wir für solche Probleme als absolutes Standard-Tool den Process Monitor. Da sieht man in vielen Fällen direkt das Problem und spart sich viel Zeit...
Den sollte jeder Entwickler kennen.

Als Standardfilter bietet es sich an auf "Process Name" zu filtern, "is" auszuwählen und als Filtertext den Namen der Anwendung einzugeben. Meistens reicht das schon. Wenn dann der Fehler passiert ist, einfach eine ggf. angezeigte Fehlermeldung offen lassen und schauen was zuletzt im Process Monitor geloggt wurde.

[EWeiss]

Zitat:

Zitat von jaenicke (Beitrag 1421795)

Zitat:

Zitat von EWeiss (Beitrag 1421791)

Also was macht Delphi anders als meine Anwendung wenn sie alleine läuft? :wall:

Das Arbeitsverzeichnis könnte in Delphi anders gesetzt sein (Start --> Parameter).

Ansonsten benutzen wir für solche Probleme als absolutes Standard-Tool den Process Monitor. Da sieht man in vielen Fällen direkt das Problem und spart sich viel Zeit...
Den sollte jeder Entwickler kennen.

Als Standardfilter bietet es sich an auf "Process Name" zu filtern, "is" auszuwählen und als Filtertext den Namen der Anwendung einzugeben. Meistens reicht das schon. Wenn dann der Fehler passiert ist, einfach eine ggf. angezeigte Fehlermeldung offen lassen und schauen was zuletzt im Process Monitor geloggt wurde.

JO den kenne ich. ;)
Werde mal schauen was der mir ausspuckt.

Zitat:

Das Arbeitsverzeichnis könnte in Delphi anders gesetzt sein (Start --> Parameter).

Nun ja das ist leer.

Ich habe noch mit keiner Programmiersprache gearbeitet wo die Eigenschaften\Funktionsweise einer Anwendung verändert wird wenn sie alleine außerhalb der Entwicklungsumgebung gestartet wird.
Kann ich mir nicht erklären.

Mit dem Arbeitsverzeichnis hat es nichts zu tun wäre das in meiner Anwendung falsch gesetzt dürfte es auch in der Entwicklungsumgebung nicht funktionieren.
Aber das tut es und ich weis nicht warum es so ist.
Meine Anwendung müsste sich eigentlich genauso verhalten wie in der Entwicklungsumgebung, tut sie aber nicht.
Wenn man sich nicht mal mehr darauf verlassen kann das sich eine Anwendung gleich verhält in und außerhalb der Entwicklungsumgebung was soll das dann noch.
Hmmmmm…..

gruss

[Delphi.Narium]

Eine aus der IDE gestartete Anwendung nutzt das von der IDE genutzte Arbeitsverzeichnis sofern bei Start / Parameter kein Arbeitsverzeichnis gesetzt ist.

Dieses Arbeitsverzeichnis muss nicht mit dem Arbeitsverzeichnis übereinstimmen, dass eine Anwendung nutzt, wenn sie außerhalb der IDE gestartet wird. Das kann zuweilen sehr verwirrend sein.

Eventuell hilft es der "Informationsfindung", wenn Du beim Programmstart mal ein

Delphi-Quellcode:

ShowMessage(GetCurrentDir);

einbaust und die Ausgabe beim Start aus der IDE mit der Ausgabe beim Start ohne IDE vergleichst.

Statt ShowMessage kannst Du das natürlich auch auf andere Weise protokollieren, ist halt nur eine Info, die eventuell bei der Fehlersuche hilfreich sein könnte.

[EWeiss]

Zitat:

Eine aus der IDE gestartete Anwendung nutzt das von der IDE genutzte Arbeitsverzeichnis sofern bei Start / Parameter kein Arbeitsverzeichnis gesetzt ist.

Danke..

Wenn ich in der Anwendung das Arbeitsverzeichnis selber setze wird auch in der IDE beim kompilieren\debuggen dieses verwendet.
Was hat das Arbeitsverzeichnis damit zu tun das sich meine Anwendung in der IDE anders verhält als alleine?
Ich benötige auch kein Showmessage um zu wissen welches das ist ;) denn ich setze es ja vorher selbst.

Mal zum Ablauf!
Die Bilder werden nicht von meiner Anwendung sondern von einem Externen Plugin geladen der Pfad dafür ist
"C:\Program Files (x86)\Windows Media Player\Visualizations\MediaPlayer_10.dll"

1. Sie wird gestartet
2. Läd eine Mp3 Datei aus irgendeinen Pfad
3. Übergibt das verwendete Plugin an meinen Visualisierungs Wrapper
4. Dieser Kommuniziert nun mit diversen DLL's vom Windows Media Player
5. Und rendert die Rückgabe des Plugin in einem Window der Anwendung.

PS:
Habe nochmal zwei shots gemacht und dein Message eingebaut obwohl ich mir klar darüber bin das in beiden fällen Der Arbeitspfad der gleiche ist.
IDE funktioniert außerhalb nicht.

Der Process Monitor bringt gar nichts er zeigt mir nur an das verschiedene Bilder vom Plugin nicht gefunden werden.
Aber das ist mir bekannt.
Wenn das also ein Problem wäre.. dürfte das Resultat in dem Fall auch in der IDE nicht True sein. Ist es aber, wie man sieht werden dort die Bilder gerendert.

EDIT:
Fakt ist doch dieser!
Welchen Sinn macht es eine Anwendung zu debuggen wenn das verhalten dieser in der Entwicklungsumgebung anders ist als allein gestartet.
Welcher murks wird da vom Compiler generiert? Das es hier unterschiede gibt.
Eine einfache Berechnung 1+1 muss in der IDE sowie außerhalb das gleiche Ergebnis liefern und nicht wie hier = 3

Wohlbemerkt das Problem tritt nur unter "Windows 10 Alpha" auf.

gruss

[Dalai]

Zitat:

Zitat von EWeiss (Beitrag 1421824)

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:

Zitat von Dalai (Beitrag 1421825)

Zitat:

Zitat von EWeiss (Beitrag 1421824)

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:

Zitat von EWeiss (Beitrag 1421827)

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:

Zitat von TiGü (Beitrag 1421839)

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:

Zitat von Delphi.Narium (Beitrag 1421826)

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