|
![]() |
|
Registriert seit: 6. Jun 2007 Ort: Dresden 187 Beiträge Delphi 11 Alexandria |
#1
erstmal danke für die antworten.
im Anhang habe ich mal ein bsp für einen StackTrace eines Fehlers angehangen, welchen ich derzeit provozieren kann, indem ich im start einer anwendung sofort ein Terminate einbringe (mittels timer, ich bin zufällig auf den effekt gestossen). Offensichtlich wird hier die hälfte der anwendung freigegeben, dann eine Message bearbeitet (wm_killfocus). Die Komponenten dürften bekannt sein, sodass vermutungen wie Spagetticode ausgeschlossen werden können. (DevExpress) Wie man sieht: keine einzige Zeile eigener Quellcode. (oder eben schon entladen) Ich habe jetzt mal grob die DevExpress quellen überflogen (eigentlich keine Zeit diese tage für solche Spielereien) und darin enthalten sind mehrere globale VariablenInstanzen, etc pp. da der Stacktrace durchklappert bis zum ersten Zugriff auf ein Klassenfeld, kann ich jetzt rätselraten, ob die vorherigen objekte nun instanziiert sind, oder der code zufällig so aufgebaut ist, das bis zuletzt nicht auf felder zugegriffen wird. ![]() FastMem *zeigt* dir den Fehler (steht auch im Beitrag) und der Optimierer (steht auch da) sorgt eben beim 'wegkürzen' von Code dafür, das der Fehler u.U. in einer anderen Stelle angezeigt wird.
![]() Dir fehlen entscheidende Grundlagen, um hier mitreden bzw. kritisieren zu können.
![]() Da man bei solchen Fehlern wie zB den oben von Entwicklern idR hört "da war irgendwas nicht instanziiiert" und "das ist nicht nachvollziehbar" (ist ja auch so, wir haben das bei paar Hunder Anwendern bei manchen paar mal die Woche (alle 2-3 Tage), bei teilweise 24*7 Betriebsdauer der Software {Verwaltungssoftware Unternehmenssteuerung}), beschäftige ich mich derzeit halt doch mal wieder mit solchen dingen, da ich eher sehe wie Anwender eine Software bedienen und somit teilweise besser Rückschlüsse auf technische Abläufe/Zusammenhänge ziehen kann. Es geht ja zB schon damit los, das es für viele Bediener nur Doppelclick gibt, einfach klick gibt es nicht. (daher haben wir mit vielen manwochen aufwand alle Application.processmessages ersetzt, da liegen ordner auf der tastatur während es rechnet, es werden zufällige tasten gedrückt, zum schluß kilbert es, da die anwendung irgendwelche eingaben verarbeitet hat) Letzendlich ist die Frage, wie man in solchen Fällen von zufälligen Fehlern, welche meist im Stacktrace auf Codezeilen verweisen die nicht mal in den eigenen Bibliotheken liegen ein Debugging/Eingrenzung vornimmt. ![]() Dispatch ist in TObject deklariert und sucht sich an Hand der Nachrichtentabelle des Objekts die passend message Methode raus oder ruft, falls es keine gibt, die virtuelle Methode
Geändert von DSCHUCH (13. Feb 2013 um 22:59 Uhr) |
![]() |
Furtbichler
(Gast)
n/a Beiträge |
#2
im Anhang habe ich mal ...Ich bin Anwendungsentwickler ... Es interessiert mich grundsätzlich auch nicht, wie der Compiler etwas macht ...würde mich das interessieren, wäre ich "richtiger Softwareentwickler" geworden und ich habe auch keine Zeit mehr für diese Dinge.
![]() ![]() Ich bin Abteilungsleiter (IT), war vorher Projektmanager, davor 25 Jahre Softwareentwickler und kenne mich ganz gut im Maschinenraum aus (eine Voraussetzung auch für Anwendungsentwickler, die mitreden wollen, finde ich). Ich habe erstens Zeit für *diese* Dinge, aber was noch wichtiger ist: Ich habe Zeit für die Dinge, die zu meinem Aufgabenbereich gehören, insofern beißt es sich nicht, sich dafür zu interessieren. Es ist trotzdem Ok, das Du dich in deinem Aufgabengebiet abgrenzt (der eine so, der andere so), aber um bei der Diskussion der Probleme der Softwareentwickler mitreden zu können, brauchst Du ein wenig mehr, als ziellos im Code herumzustochern. Das ist so, als ob der Prozessmanager einer Klinik planlos in der Bauchhöhle eines Patienten rumpopelt, weil er bei Operationsfehlern mitreden will, obwohl ihn Anatomie eigentlich gar nicht interessiert. Deinen Entwicklern könnte(!) das Augenmaß für robusten Code fehlen. Wenn 'da irgendwas nicht instantiiert' ist, dann ist das ein Designfehler (wenn es kein Bug in einer Library ist). Und: DevExpress ist bekannt dafür, das es zickig reagiert, wenn man die Klassen nicht so verwendet, wie man sollte. Ganz spaßig ist das Verwenden von Events dort, wo sie nicht verwendet werden sollen (Stichwort: Ordner auf Tastatur) Es ist auch eine ganz schlechte Angewohnheit, die Komponenten 'erst mal auf die eigenen Bedürfnisse umzuprogrammieren' (kein Vorwurf an deine Leute), denn das geht meistens in die Hose. Wer versteht schon zu 100%, wie das bei DevExpress funktionert? Mein Tipp: Wendet euch an den DevExpress-Support, um die kreative Verwendung der Events auf Korrekteit abzuklopfen. Insbesondere wenn sich der Fokus in einer GridView ändert, passiert intern bei DevExpress viel: Da werden Objekte neu instantiiert usw. Da muss man sich dann nicht wundern, wenn einem bei falscher Verwendung der Events die Anwendung um die Ohren fliegt. Das ist aber kein Bug von DevExpress, sondern einfach ein Seiteneffekt wegen Nichteinhaltung der DevExpress-Philosophie. So wie ihr da rangeht (Auswechseln von 'Application.Processmessages' ist nicht zielführend) sieht es auch nicht so aus als ob ihr wisst, was ihr tut. Ich war aber selbst mal in dem Stadium (DevExpress, Anwender, Ordner, Peng) und weiss, wie planlos man da ist. Echt zum Haareraufen. Ich habe angefangen, die Problem einzugrenzen, indem ich Event für Event abgeschaltet habe. Und dann habe ich mich an den Support gewandt und gefragt, wie man dieses Feature denn richtig einsetzt. Geändert von Furtbichler (14. Feb 2013 um 07:29 Uhr) |
![]() |
Registriert seit: 6. Jun 2007 Ort: Dresden 187 Beiträge Delphi 11 Alexandria |
#3
Merkste wat? Lass die Finger vom Maschinenraum, Du störst die Leute bei der Arbeit.
![]() ![]() Es ist trotzdem Ok, das Du dich in deinem Aufgabengebiet abgrenzt (der eine so, der andere so), aber um bei der Diskussion der Probleme der Softwareentwickler mitreden zu können, brauchst Du ein wenig mehr, als ziellos im Code herumzustochern.
letztendlich brauche ich als anwendungsentwickler vernünftige grundlagen, um ein ordentliches design zu entwerfen. wie dies dann technisch umgesetzt wird, ist dann natürlich etwas anders. prinzipiell hat aber jeder, wer informatik beim studium hatte, dinge wie A&D, Betriebssysteme, Threading-Modelle etc gelernt. das dann anwendungen _manchmal_ knallen, sind spezifika und seiteneffekte, die man nicht theoretisch lernt sondern im detail lösen muß. wie tief man in die programmierung einsteigt ist am ende ja immer sehr aufgabenabhängig. ich habe viele jahre vollzeit rad entwicklung betrieben, das nutzt einem aber bei tiefgreifenden problemen nichts, man kennt aber eben die seiteneffekte. Deinen Entwicklern könnte(!) das Augenmaß für robusten Code fehlen. Wenn 'da irgendwas nicht instantiiert' ist, dann ist das ein Designfehler (wenn es kein Bug in einer Library ist). Und: DevExpress ist bekannt dafür, das es zickig reagiert, wenn man die Klassen nicht so verwendet, wie man sollte. Ganz spaßig ist das Verwenden von Events dort, wo sie nicht verwendet werden sollen (Stichwort: Ordner auf Tastatur)
vor kurzem hatten wir zB das problem, das die ExitProc einer dll nicht mehr sauber arbeitet, was unter delphi7 noch sauber lief, ob es nun daran lag, auch wieder kA, wir haben dann eben die dinge in die finalization einer unit umgelegt, mit dem bewußtsein das solche änderungen halt seiteneffekte hervorrufen können. du mußt sehen das unseer code zum teil >10 jahre alt ist, dann hat man nicht mehr überall bilderbuchdesign, insb. auch daher das man viele externbibilotheken mit wieder eigenen "besonderheiten" berücksichtigen muß. Es ist auch eine ganz schlechte Angewohnheit, die Komponenten 'erst mal auf die eigenen Bedürfnisse umzuprogrammieren' (kein Vorwurf an deine Leute), denn das geht meistens in die Hose. Wer versteht schon zu 100%, wie das bei DevExpress funktionert?
Aber das ist auch nochmal ein ansatz, welchen wir intern disktuieren müssen, evtl kann man hier die fehlerkontrolle verbessern. Mein Tipp: Wendet euch an den DevExpress-Support, um die kreative Verwendung der Events auf Korrekteit abzuklopfen.
nutzt aber nichts wenn man keine rekonstruierbaren fälle hat, insb. da - (anfang der diskussion) der fehler ja nichtmal von dort kommen muß, selbst wenn der stacktrace darauf zeit. ^^ So wie ihr da rangeht (Auswechseln von 'Application.Processmessages' ist nicht zielführend) sieht es auch nicht so aus als ob ihr wisst, was ihr tut.
Application.ProcessMessages ist meines erachtens nach eines der dümmlichsten dinge in delphi, insb. da überall steht "verwenden, bei längeren operationen, damit die anwendung nicht hängt, bzw. zeichnen zu lassen." so zB habe ich das erst vor 3 tagen hier gelesen, hatte aber gerade keine zeit: ![]() prinzipiell müßte ja wenigstens die form disabled und enabled werden, damit der nutzer zB die anwendung nicht während der bearbeitung der schleife schliesst. noch interessanter wird es, wenn er die funktion in einem eventhandler einbaut (buttonclick) letztendlich sagst du aber auch, das du die fehler nur durch haare raufen ![]() |
![]() |
Ansicht |
![]() |
![]() |
![]() |
ForumregelnEs ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.
BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus. Trackbacks are an
Pingbacks are an
Refbacks are aus
|
|
Nützliche Links |
Heutige Beiträge |
Sitemap |
Suchen |
Code-Library |
Wer ist online |
Alle Foren als gelesen markieren |
Gehe zu... |
LinkBack |
![]() |
![]() |