![]() |
AW: Bestehende Software modernisieren / Umstieg
Wo soll ich anfangen? Beim Styling über Stylebooks statt mal schnell eine CSS-Eigenschaft zu ändern? Oder die vielen fehlenden Komponenten, die man aus tausenden anderen Apps kennt und die in den von mir genannten Frameworks enthalten sind (SideMenu z.B.)? Oder der fehlende Support für Nullables und (noch wichtiger: Async/Await)? Genügt das, oder soll ich noch mehr auflisten?
|
AW: Bestehende Software modernisieren / Umstieg
Nein, reicht schon.
Bei Styling stimme ich Dir zu, ich habe mir da was drumrumgebaut um wenigstens die Basics einfärben zu können. Wenn man aber mit einen CustomStyle arbeitet muss man den i.d.R. einmal für einen Kunden anpassen, und kann den dann lange nutzen. Habe ich auch gemacht, und meine Lösuing ist so 50/50 zwischen den Beiden o.g. Extremen. Nullables : Nice to have, hilft mir aber aktuell auch nicht immer weiter AsyncAwait: Da nutze ich eigene Lösungen, vermisse ich jetzt nicht unbedingt (es gäbe Wichtigeres) Ich baue mir halt viel selbst, und versuche möglichst wenig komplexeres FMX zu nutzen, damit komme ich ganz gut klar. Interessant finde ich das Du nicht mangelnde Stabilität, o.ä. (die üblichen Mängel) aufzählst, das gibt mir Hoffnung :thumb: |
AW: Bestehende Software modernisieren / Umstieg
Zitat:
Sherlock |
AW: Bestehende Software modernisieren / Umstieg
Zitat:
|
AW: Bestehende Software modernisieren / Umstieg
Oooch, das war mal soo schön für 270 Minuten nichts über instabiles FMX zu lesen :lol:
Und jetzt das :cry: |
AW: Bestehende Software modernisieren / Umstieg
FMX wird, genau wie PHP von Delphi und alle anderen längst vergangenen Borland/Codegear/Wasauchimmer-Technologien, schnell wieder von den Bildschirmen verschwinden.
Grund dafür werden die anderen Frameworks sein, die wesentlich angenehmer zu benutzen sind. |
AW: Bestehende Software modernisieren / Umstieg
Ich finde das interessant das jemand im Delphi Forum fragt wie man am besten von Delphi wegkommt und auch noch Tipps bekommt.
|
AW: Bestehende Software modernisieren / Umstieg
Für mich ist es angenehm genug.
Ich nutze RAD für die visuellen Designs, und versuche das Coding mit so wenig wie möglich Drag-und-Click Events zu bauen wie möglich. Sondern schon mehr in die Richtung wo andere Frameworks schon sind. MVVM und DI sind schwerer umzusetzen, aber diese sinngemäß einzubauen geht schon (DI sowieso). Die Funktionalität verteile ich in kleine Units in meinem Framework, die gut wartbar und testbar sind, und bei Bedarf leicht austauschbar oder ergänzbar. Die variablen Features versuche ich auszuklammern, so das neue Apps quasi "konfiguriert" werden können (ala braucht Location, braucht AudioOut, braucht WakeLock, etc.). Die Basiscontrols Edit, Button, ListBox, ListView versuche ich über interposer Klassen zu Erweitern, und damit Bug-frei zu halten. Auch gebe ich den Komponenten die manchmal fehlenden Basisfunktionen, die ich schon immer vermisst habe bei Delphi. Die komplexeren Controls lasse ich links liegen, und baue mir bei Bedarf komplexeres aus TFrame zusammen. Das Ganze wird von Version zu Version besser, und die Instabilitäten kommen zu 90% von den Platformen selbst, die eben auch extrem instabil sind (siehe iOS13 Einführung, schaut mal in die Apple-Foren). Ich denke Flutter oder andere werden das grundsätzliche Problem mit den Platformen auch nicht beheben, aber womöglich schneller fixen. Ich gebe zu das ist nicht ganz der native RAD Ansatz mit FMX, aber mit etwas Umstellung geht das sehr gut um bei FMX sein eigenes Framework herumzubauen. |
AW: Bestehende Software modernisieren / Umstieg
Zitat:
|
AW: Bestehende Software modernisieren / Umstieg
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz