ich habe heute die neue Version installiert und einige neue Probleme damit.
Der Code läuft eine einem Dienst und dies die letzten Jahre ohne jede Probleme.
Nun führt:
Die ersten Aufrufe funktioneren Problemlos.
Der Fehler tritt erst auf wenn mehrere Threads aktiv sind, dann aber aber zuverlässig mit allen Programmen nicht nur in Diensten.
Beim laden eines Files ab Netzwerkshare tritt der Fehler in :loadfile() beinahe sofort auf auf beim laden eines lokalen Files einige Programmzeilen später wobei auch viel mehr einwandfreie Durchgänge möglich sind.
Ich habe dieses Problem mit einem Codemuster mal an Alaska gemeldet.
brandelh hat geschrieben: ↑Di, 18. Dez 2018 10:09
In der Änderungshistorie steht zu images und XbpBitmap was drin, ich verstehe das zwar als "Optimierung", aber dabei kann ja auch was schief gehen
Nein, das wurde komplett umgestellt, siehe Update-Beschreibung und letzte Alaska-Mail dazu.
Implement WIC encoder and decoder based image processing to be used by the Xbase++ resource manager as well as the XbpBitmap class. (xppui1.dll) (W18FAJ)
Adapt the XbpBitmap() class to use the new imaging core based on WIC (xppui1.dll) (W18FAK)
Rework the runtime internal resource manager to use the new imaging core to acccess image data. Refactor accordingly. (xppui1.dll) (W18FAL)
Add a LRU-based access cache in front of the resource manager to reduce payload of the WIC encoder/decoders to increase performance, specifically if it comes to painting of images in the UI. (xppui1.dll) (W18FAN)
bedeutet ärgerlicherweise auch dass sobald "man" von dem Problem betroffen ist der Build 2.00.1064 und folgende unbenutzbar sind solange Alaska das Problem nicht beseitigt. Ich habe heute den ganzen Tage versucht Teile des Programms umzustellen habe aber keine funktionierende Lösung gefunden, einziger Ausweg ist der die vorgehende Version zu verwenden.
OK, bin auch gerade wieder am Update deinstallieren. Da hat die Alaska-Qualitätskontrolle aber so richtig gepennt. Das braucht ja nicht mal irgendwelche exotischen Voraussetzungen für den Crash. Ob die vor Weihnachten noch eine Korrektur raus bringen? Wär schon gut.
??!!!!@???
Ich dachte immer dass es für Umfassende änderungen Beta-Test's und dann RC gibt die durch einen kleinen Kreis "bevorzugter" User getestet werden.
Vermutest du dass wir jetzt die Beta-Tester sind?
Ob die vor Weihnachten noch eine Korrektur raus bringen?
ramses hat geschrieben: ↑Di, 18. Dez 2018 7:41Der Fehler tritt erst auf wenn mehrere Threads aktiv sind
hm ... WIC ist IMHO nicht Threadsafe
---
es ist eine Frechheit von Alaska eine bestehende CLASS durch so was zu ersetzten statt eine neue CLASS zu präsentieren. damit werden Anwendungen auf einmal unbrauchbar und das wohl ohne Vorwarnung ... oder hat Alaska vorher kommuniziert
als v2.x User würde ich Alaska einen bösen Brief schreiben das so was überhaupt nicht geht
auch wenn "continues Delivery" nichts anderes bedeutet als "ständige beta" Version bricht ein solches Verhalten alle Regeln der Kompatibilität
AUGE_OHR hat geschrieben: ↑Mi, 19. Dez 2018 0:56auch wenn "continues Delivery" nichts anderes bedeutet als "ständige beta" Version
Jimmy,
jetzt übertreib mal nicht. Continuous Delivery ist nicht ständige Beta. Sondern permanente Weiterentwicklung. Sollen wir wie früher Jahre lang auf irgend was neues warten (ich erinnere nur an die 1.9/1.9SL1/2.0-Orgien)? Nein Danke, so ist das schon vollkommen in Ordnung. Aber leider scheint an irgend einer Stelle bei Alaska die Kontrolle nicht mehr so tief zu greifen wie das früher war. Es gab da ja leider schon drei (?) Bugs - in all den Jahren seit es die 2.0 gibt. Also nix ständige Beta, sondern stellenweises Versagen.
der Begriff "Continuous Delivery" stammt ja noch nicht mal von Alaska sondern von Windows 10.
gemeinsam haben die beiden das die "zu oft" und mit Fehlern kommen.
---
das ganze wäre auch kein Problem wenn Alaska eine neue CLASS präsentiert hätte.
nun hat Alaska das ganze in eine vorhandene CLASS eingebaut ... und damit die Kompatibilität zerstört.
solche Veränderungen kommen aber in gewöhnlich nur beta Version vor.
p.s. hätte ja nichts gegen WIC und GDIplus ... wenn es funktioniert.
Wie ein "Versuchsobjekt" komme ich mir aber schon ein wenig vor.
Die erste App die ich neu kompiliert hatte lief nicht mal 10 Sekunden bis zum Crash.
Klar bei der Software Entwicklung gibt es Fehler, überall.
Wichtig ist dann wie damit umgegangen und kommuniziert wird.
Xbase ist aber weder Freeware noch für ein Trinkgeld erhältlich.
Die Sub. bringt ja ab und zu was neues, das ist z.T aber gar nicht nutzbar da Codebeispiele und Dok. fehlen.
Dafür werden wichtige Parts wie IPv6 komplett verschlafen.
Ich beginne mich wirklich zu fragen welchen Nutzen eine Sub überhapt noch hat ob es nicht besser
ist eine Weile(Jahre) auf einem bestehenden Stand zu bleiben bei einer Version deren Verhalten man kennt.
Innerhalb 2.5 Jahre ist dies der zweite Fehler in Xbase der mir APPs komplett unbenutzbar machte.
Dieser tratt wenigstes schon bei den eigenen Tests auf und zerstörte keine Kundendaten.
Auch dass auf Fehlermeldung nur ungern, spärlich, spät geantwortet wird scheint ein übel der heutigen Zeit zu sein.
Eine Antwort von Alaska habe ich jedenfalls noch nicht erhalten.
Das alles zusammen empfinde ich als nicht korrekt.
Es würde mich interessieren ob die 1064 noch ausgeliefert wird um noch mehr Entwickler zu "beglücken"
Aber nur durch die gleiche Class kann man bestehenden Code so lassen wie er ist.
Evtl. hätte man einen Schalter für den Präprozessor einbauen sollen, nimm den neuen oder den alten code ...
Ich denke die werden das mit dem Internal Error schon hinbekommen und eine Klasse so zu schreiben, dass die selbst Threadsafe auf die DLLs zugreift ist ja auch möglich.
Irgendwie kann ich aber kaum glauben, dass eine Windows API für Grafikoperationen nicht threadsafe sein soll, denn die nutzt doch jedes Programm und das OS selbst grundsätzlich konkurierend.
Schalter verwirren nur. Wenn man damit beginnt werden es immer mehr und unübersichtlicher.
NEIN. Man hätte die CLASS Testen sollen oder an einen kleinen Kreis zum Test ausliefern sollen.
Oder eine BETA-Gruppe schaffen die die Sub nicht mit Geld sondern gegen Test Arbeit erhalten .....
Ich denke auch das es richtig war, die gleiche Klasse weiter zu benutzen. Für uns als Entwickler ist es ja vollkommen egal, wie Alaska die Daten ran schafft. Und wenn die das beamen würden. Hauptsache die bisherigen Methoden etc. funktionieren syntaktisch gleich wie früher. Wenn dann noch schneller und besser - alles OK.
Alaska hat ja schon mehrfach massive Umbauten an Klassen vorgenommen, ohne die Klassennamen zu ändern. Ich erinnere nur an die Arbeiten an den XbParts. Da ist ja teilweise kein Stein auf dem anderen geblieben. Trotzdem hat Alaska (vollkommen korrekt) da keine neue Klasse für kreiert.
Und Continuous Delivery ist weder eine Erfindung von Alaska von von MS. Das gab es schon viel früher, mindestens seit 2010 auch unter dieser Begrifflichkeit. Ich selber nutze das z. B. schon seit knapp 10 Jahren für meine Projekte - wenn auch damals noch nicht unter dem Namen.
vielleicht sollte Alaska Dich als Beta-Tester nehmen? Alle dieser fundamentalen Bugs bisher hattest doch Du gefunden, oder?
Ich hatte nur damals das Problem mit den Auflösungen/Skalieurngen gefunden und an Alaska gemailt - die das zuerst nicht ernst genommen hatten. Bis dann wohl doch weitere entsprechende Meldungen bei denen eintrudelten. Und die gemerkt haben, das MS da mit einem Update etwas grundlegendes verbockt hatte. Also nicht direkt ein Bug von Alaska, hatte nur dort Auswirkungen.
die interne und externe Art und Weise wie eine App nach Anpassungen getestet wird sollte doch im Rahmen des Qualitäts-Mangements festgelegt sein.
Mittlerweile hat mir Alaska bestätigt dass der Fehler da ist:
Originaltext:
Ich kann bestätigen, dass es unter den genannten Umständen zu einem Fehler kommt. Wir werden uns das sofort ansehen und das Problem schnellstmöglich beheben.
Entweder ist es wirklich kniffliges Problem oder das QM ist wirklich lückenhaft. Wir werden es wohl nie wirklich erfahren......
Ich mache mir so meine Gedanken zum ganzen, möchte aber in der öffentlichkeit momentan nicht weiter darüber schreiben ..... sorry ...
Ich glaube, dass typische Xbase++-Anwendungen u.U. ziemlich umfangreich, aber inhaltlich unspektakulär sind. Eben (migrierte) Datenbankanwendungen. Die Standard-Controls werden standardgemäß verwendet. Wenn man das tut, kracht es selten, auch mit einem Fehler in irgendeiner UI-DLL. Und wir alle wissen, dass aussagekräftige Testszenarien schwer zu konstruieren sind. Wer behauptet, seine Kunden nicht (auch) als Beta-Tester einzusetzen, sagt wahrscheinlich nicht die Wahrheit.
Wer behauptet, seine Kunden nicht (auch) als Beta-Tester einzusetzen, sagt wahrscheinlich nicht die Wahrheit.
Ja, das stimmt. Ich spreche mich mit den betroffenen aber immer im voraus entsprechend ab. Ohne das könnte Firmenspezifische Software gar nicht entwickelt werden..... und den Kunden als Beta-Tester zu benutzten *OHNE* dass er es weiss geht schon gleich gar nicht ....
stimmt. Manchmal sitz ich einfach nur staunend da wenn ich sehe, auf was für Ideen die Anwender mit meiner Software kommen können. Viel Zeit verbringe ich damit, solche seltsamen Sachen zu verhindern, zu korrigieren, anzupassen.
Ich hab das auch gerade mitbekommen. Und gleich mal installiert. Was soll ich sagen? Da wo das vorher gescheppert hatte läuft das jetzt.
So ärgerlich der Fehler auch war muß man doch anerkennen, das Alaska wie auch schon beim Skalieurngsproblem sofort geschaltet hat und extrem zeitnah eine Korrektur nachgeschoben hat. Dafür muß ich einfach nur Anerkennung zollen.
So, und jetzt geht die Testerei und Witerentwicklung mit der neuen Version weiter. Die Weihnachtstage sind gerettet, ich kann programmieren
