Zugriff auf procedure und funktionen nicht instanziierter Klassen / Objekte

[JamesTKirk]

Zitat von DSCHUCH:

1) was mich jetzt noch mal interessiert ist, wie dann eigentlich proceduren implementiert sind, welche auf (windows-) messages reagieren (zB Painter). da der code ja immer vorhanden ist, unabhängig der klasseninstanz, muß ja irgendwo geregelt werden, welche instanz nun die message erhält, und welche nicht. ist es theoretisch vorstellbar, das eine nil-klasse eine message (zB wm_paint) erhält?

Innerhalb des Constructors eines Formulars wird die WndProc gesetzt, welche von Windows die Nachrichten enthält. Diese Nachrichten werden dann (einfach formuliert) per Form.Dispatch an das jeweilige Form geschickt. 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 DefaultHandler auf.

Rein theoretisch sollte das auch mit einer ungültigen Instanz funktionieren, aber wie jeder Hack ist diese Angabe ohne Gewähr.

Gruß,
Sven

[DSCHUCH]

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.

Zitat:

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.

hier reden wir aneinander vorbei, was es theortisch macht ist mir auch wieder klar, was es praktisch wirklich ändert ist die frage. ich weiß zB nicht, ob man mit diesen/irgendwelchen Tools die Speicher komplett ausnullen kann, wenn ein objekt freigegeben wird, sodas es halt nicht mehr zufällige zugriffe auf zufällig vorhandenen code gibt.

Zitat:

Dir fehlen entscheidende Grundlagen, um hier mitreden bzw. kritisieren zu können.

Richtig. Ich bin Anwendungsentwickler und mein Fokus liegt darauf, mit Unternehmen Prozesse zu entwerfen und diese in eine Softwarestruktur zu bringen. Es interessiert mich grundsätzlich auch nicht, wie der Compiler etwas macht und wie nicht, würde mich das interessieren, wäre ich "richtiger Softwareentwickler" geworden und ich habe auch keine Zeit mehr für diese Dinge.
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.

Zitat:

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

muß ich nachlesen, wie sich die WinControls da registrieren/deregistrieren und ob es möglich ist, das hier noch eine komponente/methodenzeiger in der Nachrichtentabelle steht, welche nicht mehr existiert.

[Furtbichler]

Zitat von DSCHUCH:

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.

Merkste wat? Lass die Finger vom Maschinenraum, Du störst die Leute bei der Arbeit.

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.

[DSCHUCH]

Zitat von Furtbichler:

Merkste wat? Lass die Finger vom Maschinenraum, Du störst die Leute bei der Arbeit.

würde man das als projektleiter machen, wäre der maschinenraum ganz schnell unter wasser, da der kunde nie ein produkt erhält oder die kosten ein loch in den maschinenraum reissen und der ganze laden sinkt.

Zitat von Furtbichler:

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.

geht ja wohl kaum anders, der tag hat nur 28 Stunden ^^.

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.

Zitat von Furtbichler:

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)

das würde ich bestreiten. man muß sehen, das bei einer Anwendung wie unserer, mit ca. 400 Formularen, dynamischen bpl und dll, [alles wird bei bedarf dynmaisch geladen] Datenbank im Hintergrund von 10GB mit 300 tabellen, und seit ca. 2 jahren datasnap, über das permanent massen an daten zwischen client und server ausgetauscht werden. hinzukommen netzwerke im unternehmen, seiteneffekte wie netzwerkabrisse, virenscanner etc.pp

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ß.

Zitat von Furtbichler:

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?

Hier ist aber die notwendigkeit nunmal entscheidend. in unserer anwendung sind nahezu alle komponenten abgeleitet, um bessere kontrolle zu haben, oder auch schon nur wegen kompatibilität und austauschbarkeit. unsere anwendung war früher devexpress version 3, dann portiert, portiert, portiert.... ohne eine ordentliche ableitung der verwendeten standardkomponenten kann man das vergessen bei hunderten von Formularen.
Aber das ist auch nochmal ein ansatz, welchen wir intern disktuieren müssen, evtl kann man hier die fehlerkontrolle verbessern.

Zitat von Furtbichler:

Mein Tipp: Wendet euch an den DevExpress-Support, um die kreative Verwendung der Events auf Korrekteit abzuklopfen.

der devexpress support ist spitze, wir haben schon sehr viel mit denen gearbeitet, bugfixes erhält man idR innerhalb weniger tage.
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. ^^

Zitat von Furtbichler:

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.

hat bei uns diese probleme beseitigt. wir haben alles gekapselt und haben jetzt die möglichkeit alle "zeichenroutinen" der kompletten anwendung zentral und über parameter zu steuern.

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: http://www.delphipraxis.net/173225-f...leife-auf.html

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 sowie try except herausgefunden hast. wir werden sicher bei der nächsten entwicklersitzung erstmal deinen vorschlag disktuieren und die ganzen devexpress events (bzw überschriebene proceduren, ableitungen etc) auf unregelmäßigkeiten überprüfen. ich könnte mir jetzt vorstellen das dort in irgendeinem fall mal ein abort ausgelöst wird, was mir jetzt einiges erklären könnte und auch deinen ansätzen gleich käme. (zB in einer überschriebene methode "focuschange" eines objektes, um zu verhindern das weitere abarbeitungen stattfinden)