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