![]() |
AW: Seltsamer Fehler beim schließen
Zitat:
|
AW: Seltsamer Fehler beim schließen
Wenn sich Programme nicht via Manifest beim Windows als Kompatibel zu dieser Version outen, dann geht Windows davon auß, daß es sich eventuell um alte schrottige Programme handelt.
Da z.B. viele Programmierer großen mist bauten und ständig versuchen ins Programmverzeichnis "C:\Programme" zu schreiben. Bzw. die genannten "Schlagworte", betreffend noch schorottiger Setupprogramme, welche vergessen die Adminrechte anzufordern. Dann schaltet Windows gewisse Heuristiken an und schaltet dann automatisch die Adminanforderung ein, oder schaltet in die Dateizugriffe verschiedene Umleitungen (z.B. VirtualStore) dazwischen. |
AW: Seltsamer Fehler beim schließen
Wow, das die Sicherheitsrechtlinien mittlerweile so weit greifen wusste ich nicht. Gut zu wissen für die Zukunft.
Mein Programm liegt allerdings recht einsam in einem Ordner auf dem Desktop. Was könnte eigentlich der Grund dafür sein, das es in Delphi problemlos beendet werden kann? |
AW: Seltsamer Fehler beim schließen
Zitat:
|
AW: Seltsamer Fehler beim schließen
Warumn?
Der Debugger schaltet sich dazwischen und da Laufen einige Dinge ein bissl anders. Mittlerweile? Das ist schon seit NT (2000) so strikt, nur war es Keinem aufgefallen, da alle ständig mit vollen Adminrechten rumrannten. Und als Microsoft das bei Vista endlich und zurecht mal abgestellt hat (Standardbenutzter sind nur noch Benutzer), heulten alle rum, weil fast nix mehr lief, was aber nicht die Schuld von MS war. |
AW: Seltsamer Fehler beim schließen
Ich habs nur für den close benutzt. Im Grunde nur zur reinen Übersichtlichkeit, für mich war der Code so strukturierter zu lesen.
Kurz dachte ich das Problem könnte der Wechsel der Systemcursor sein. Ausbauen davon hat aber leider nichts gebracht *grummel*. Schlicht unterdrücken kann man das nicht, oder? Ich weiß, ist dirty. Ich meine auch nur zum testen. Mit TApplicationEvents habe ich ein Abfangen versucht, ohne Erfolg. Wohl weil es ein Fehler ohne konkrete Fehlernummer ist. @humitsu Die NT Schiene habe ich zum programmieren ausgelassen, Vista auch. Ins Programmverzeichnis habe ich aber schon vorher nur sehr ungern geschrieben. Ich hab da einiges verpennt, ja. |
AW: Seltsamer Fehler beim schließen
Durch deine Verwendung von Form1 innerhalb der Klasse TForm1 entstand – zumindest bei mir – die Vermutung, daß dir noch weitere ähnliche Fehler unterlaufen sein könnten. Da es den durchaus hilfsbereiten Usern dieses Forums jedoch bislang verwehrt bleibt, deinen streng geheimen Code auf gewisse Verdächtige zu untersuchen, ist das Problem leider kaum lösbar. Anders ausgedrückt: Der einzige, der den Code durchforsten kann, um zu schauen, ob ihm was auffällt oder wo der Hase im Pfeffer liegen könnte, bist du. Wir können hier eigentlich nur dumm rumraten :twisted:
|
AW: Seltsamer Fehler beim schließen
Du könntest im Projektquelltext nach dem Run einmal eine MessageBox einbauen, dann alle Formulare freigeben und dann wieder eine MessageBox einbauen.
So findest du heraus, ob das Problem bei der Freigabe der Formulare entsteht. |
AW: Seltsamer Fehler beim schließen
@Perlsau
Ihr ratet sicherlich nicht "dumm" herum, sondern wesentlich schlauer als ich es könnte :). Mein Quellcode ist im Grunde nicht geheim. Nur weiß ich nicht welcher Teil für Euch interessant wäre und ob mein Cheff das mag, wenn ich Code herumreiche... @jaenicke Danke für den Tipp, ich versuchs mal! |
AW: Seltsamer Fehler beim schließen
NT ist alles seit NT, also auch bis Windows 8. (man könnte ja denken, daß die Entwickler sich in den letzen 20 Jahren hätten daran gewöhnen können)
Der Metro-Teil ist die neue RT-Schiene (Architektur/API), welchen es auch einzeln gibt (für ARM-CPUs). Davor gab es vorallem die 3.1-Schiene (16 Bit > 1.x bis 3.x) und dann die 9x-Schiene (32 Bit DOS). Mit ME den 9x/NT-Mischmasch und nebenbei gab es noch CE und Mobile/Phone. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:21 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