Im Fehlverhaltensfall wäre es interessant, mal den ProcMon von Sysinternals mitlaufen zu lassen, eingegrenzt auf die App. Dann sähe man, was passiert, wenn die EXE zu schreiben versucht - und warum es verhindert wird.
was ist Deine Bildschirmauflösung? Bis einschließlich FullHD (und wohl auch ein klein wenig da drüber) hat Xbase++ auch vor der Build 807 keine Probleme mit dem 1703. Soweit ich weiß. Und zumindest nicht bei mir.
"ein Programm startet nicht" ist dann in diesem Fall eine zu grobe Aussage.
Ich behaupte, dass jedes EXE erst einmal "startet", es ist nur fraglich wie weit der Code ausgeführt wird.
Man (der User) sagt leicht "das Programm startet nicht", meint aber, dass das Programm nicht das erwartete tut (kein Fenster, mit oder ohne Fehlermeldung, keine geschriebenen Dateien, usw.).
Dann also
- XPPFATAL.LOG auf der gesamten Platte suchen,
- im Windows Erreignis-Log nachschauen,
- im Virenscanner-Log nachschauen oder diesen und alle andere Viren-Tools auschalten,
- natürlich den Code optimieren damit man genau weiß wo das EXE ausgeführt wird und die Dateien geschrieben werden sollen (siehe vorherige Beiträge).
- und weitere Punkte...
Jan hat geschrieben: ↑Mi, 02. Aug 2017 15:08...Bildschirmauflösung?
und Bildschirmskalierung
Wenn Mike das Problem mit der Bildschirmskalierung (oder angegliederte Fehler) hat bekommt er eine XPPFATAL.LOG. Es sei denn er hat die Errorbehandlung ausgeschaltet - dann würden aber die Anfangs genannten Test-Zeilen nur den rudimentären Teil seines Programms darstellen. Es erübrigt sich dann jede weitere Diskusion...
die Skalierung würde ich nach meinen eigenen Erfahrungen erstmal ausschließen. Die war vollkommen egal, die Auflösung war das Problem.
Und ja, natürlich "startet" das Programm. Ohne jemals auch nur bildschirmtechnisch aufzuzucken. Sondern sofort und direkt eine xppfatal zu schreiben.
Kann man die Feherroutinen soweit abschalten, das sogar die xppfatal nicht erstellt wird? ich dachte immer, die steckt so tief im System drin, da kann man nichts gegen machen.
Jan hat geschrieben: ↑Mi, 02. Aug 2017 16:03Kann man die Feherroutinen soweit abschalten, das sogar die xppfatal nicht erstellt wird?
Habe es selbst noch nicht getestet
Ich gehe aber davon aus, dass wenn die EXE soweit startet dass die ersten PRG-Zeilen ausgeführt werden und der Errorblock geich am Anfang gesetzt wird sicherlich möglich. Dann reicht schon ein Fehler im Errorblock und es sieht so aus als passiert nichts mehr...
Wenn allerdings das Bildschirmauflösungsproblem die Ursache ist kommt die EXE erst gar nicht so weit eine PRG-Zeile auszuführen. Dann XPPFATAL.LOG
mein Tablet hat eine ähnlich hohe Auflösung. Und da lief nach dem 1703 gar nichts mehr. Egal welche Skalierung. Auf allen anderen Rechner mit "nur" FullHD kein Problem.
Ich habe (vielleicht noch) keine Probleme.
Ich verwende auch noch die 1.9 produktiv. (2.0 habe ich eine ausgelaufene Subskription.)
Ihr habt die Fehler schon erlebt. Deswegen mein Testprogramm. Natürlich muss das Ding in einem Verzeichnis laufen, wo es Schreibrechte hat. Wenn das Programm da läuft, wo andere sterben, dann kann man mit der Differenzsuche beginnen.
Meine Frage an die Natur (=Experiment): Stirbt das Progrämmchen bevor es so richtig los geht, wie es die anderen 1.9-Applikationen tun?
Bisher habe ich immer ein "Nein" bekommen. Gibt es da draußen auch ein "Ja?".
Jan hat geschrieben: ↑Mi, 02. Aug 2017 16:03
Hallo Hubert,
die Skalierung würde ich nach meinen eigenen Erfahrungen erstmal ausschließen. Die war vollkommen egal, die Auflösung war das Problem.
JAN,
ich habe hier nur auf die Datei Erstellung reagiert, du musst jemand anderes meinen
PS: auf Rechnern mit Schreibschutz im EXE Verzeichnis (z.B. auch einem WEB Server in CGI-BIN), wird keine XPPFATAL.LOG erstellt, denn dazu müsste man Schreibrechte haben
--- snip ---
Erwartest Du dass ich Fehler welche mit Deinem Programm in Zukunft vorkommen könnten vorhersehen kann?
--- snap ---
Nein. Aber wenn Du mein Progrämmchen auf dem Rechner laufen läßt, wo das Deine stirbt, und meines überlebt, dann bin ich schon mal sorgenfrei und kann Dir vielleicht mit Deinen Problemen helfen.
mikehoffmann hat geschrieben: ↑Fr, 04. Aug 2017 11:54...und kann Dir vielleicht mit Deinen Problemen helfen.
Hallo Mike
mit Xbase++ Version 2.0 Buld 807 sind meine Startprobleme unter Win 10 Creators Update (1703) seit einigen Wochen behoben. Das Thema ist also für mich erledigt.
Wenn mit anderen, alten Xbase-Versionen Probleme auftreten hilft eben nur Updaten auf die neue Xbase++-Version. Das kostet zwar was, spart aber viel Zeit und vor allen Dingen Ärger beim Kunden.
DelUser01 hat geschrieben: ↑Fr, 04. Aug 2017 15:17
mikehoffmann hat geschrieben: ↑Fr, 04. Aug 2017 11:54...und kann Dir vielleicht mit Deinen Problemen helfen.
mit Xbase++ Version 2.0 Buld 807 sind meine Startprobleme unter Win 10 Creators Update (1703) seit einigen Wochen behoben. Das Thema ist also für mich erledigt.
schön wenn Alaska einen Patch geliefert hat der bei dir funktioniert aber geht es darum im Forum ?
Mike und ich haben beide nicht das Problem aber wir möchten raus bekommen "warum" Xbase++ "versagt" und da wäre es nett wenn man die Frage auch jetzt noch beantwortet die wir nicht testen können (weil es ja bei uns funktioniert).
Frage :
1.) triff das Problem auch unter 32bit und Windows 1703 auf ?
2.) hat das schon jemand mit der lates Windows Insider 10.16251 probiert ?
DelUser01 hat geschrieben: ↑Sa, 05. Aug 2017 13:11
Mach' Dir's doch einfach - frage Alsaka - die wissen doch was die Ursache war, die haben das doch behoben.
nicht das ich schon längst gefragt hätte ...
Frank++ erzählt was von Resourcemanager aber sagt nicht "wie" man es simulieren kann.
vielmehr sagt er "sometimes" also längst nicht "immer".
in der PDR 6904 steht :
Try to change the custom scaling factor. What scaling factor to use can not be predicted.
was sich IMHO nun gar nicht mit der Aussage von Frank++ passt.
auch die Frage ob es unter 32bit Windows 1703 passiert wurde bislang nicht beantwortet.
und ob der Fehler wirklich behoben ist wird man nächsten Monat sehen wenn die RS3 Windows 1709 raus kommt.
Ich dringe irgendwie nicht so richtig durch. Schnief, heul, schluchz, jammer und ein fränkisches grein.
Ich probier's aber nochmal: Gibt es jemanden, dessen Programm in der 1.9-Version das "ich will nicht starten"-Problem auf einem Rechner hat, auf dem mein Testprogramm aber ohne Probleme durchläuft?
Ich gehe übrigens davon aus, dass die API-Funktion LoadImage das polare Sorgenkind ist.
Danke, Jimmy. Damit liegt der problematische Code im Runtime-Startup für Xbase-GUI Applikationen, also bevor Xbase-Code tickt. Sehr unschön und nicht ganz leicht selber zu reparieren.
mikehoffmann hat geschrieben: ↑Di, 08. Aug 2017 18:39Damit liegt der problematische Code im Runtime-Startup für Xbase-GUI Applikationen, also bevor Xbase-Code tickt.
Genau darum ging es bisher in diesem gesamten Forenthema. Das hatten wir schon vor einigen Wochen mit viel Beteiligung herausgefunden. Dazu gibt es die neuen Builds von Alaska v2.
Kann sein, dass ich das wieder mal altersbedingt nicht mitbekommen habe, aber ich kann mich an keinen expliziten Test erinnern, ob das Programm vor oder nach ErrorSys stirbt. Dank Jimmy weiss ich das nun sicher und ich weiss auch, dass meine 1.9-Progrämmchen laufen werden, wenn ich sie als Konsolenapplikation kompiliere.