Zugriff auf procedure und funktionen nicht instanziierter Klassen / Objekte

[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)