DbEdit auf Array

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Antworten
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

DbEdit auf Array

Beitrag von Jan »

Moin,

ein XbpBrowse geht ja auch relativ simpel auf ein Array. Aber wie ist das bei einem DbEdit? Ich hab da die Anforderung das umzusetzen, bin aber nicht sicher ob das überhaupt machbar ist.

Der Punkt ist: Wenn ich in aColumns die Memvars eines DO im Array angebe, dann klappt das ganz sauber. Solange das Array nur einen Satz hat. Aber sobald da ein zweiter Satz ins Spiel kommt scheppert das. Vermutlich weil ich den Recno() nicht angeben kann. Das läuft bei einem XbpBrowse über den nRecno in den einzelnen Instanz-Variablen wie :GoBootmBlock. Aber das gibt es beim DbEdit natürlich nicht. Muß ich mir dann den Code von DbEdit schnappen und das dort bei der Konfiguration des TBrowse einbauen? Oder geht das auch irgend wie direkt auf den DbEdit ohne eigene Modifikationen z. B. über die UDF?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Dieter
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 237
Registriert: Do, 14. Aug 2008 14:59
Wohnort: Straelen
Hat sich bedankt: 2 Mal
Danksagung erhalten: 3 Mal

Re: DbEdit auf Array

Beitrag von Dieter »

Hallo Jan,

selbst Alaska empfiehlt DBEDIT nur noch aus Kompatibilitätsgründen zu nutzen. Das bedeutet, dass vorhandener Code möglichst nicht geändert oder erweitert werden sollte. Ich selbst habe mir DBEDIT vor mehr als einem Jahrzehnt einmal näher angeschaut und bin zu der Erkenntnis gekommen, dass es reine Zeitverschwendung ist damit zu arbeiten. Ich würde jeden Auftag sofort ablehnen, der mich verpflichten würde, mit DBEDIT zu programmieren.
Viele Grüße

Dieter

Was man nicht versteht, besitzt man nicht.
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: DbEdit auf Array

Beitrag von ramses »

Dieter hat geschrieben: Di, 24. Nov 2020 18:33 Ich würde jeden Auftag sofort ablehnen, der mich verpflichten würde, mit DBEDIT zu programmieren.
Hallo Dieter

du könntest die betreffenden gerne an mich verweisen!

Ich wollte vor etwa einem Jahrzehnt einmal alle DBEDIT() aus dem Code entfernen. Ich und mein Kunde sind dann zur Erkenntnis gekommen dass
dies reine Zeit- und Resourcen Verschwendung wäre da der Code ja einwandfrei funktioniert. Inzwischen habe ich viele Stellen überarbeitet und auch erweitert.

Sicher sollte man dbedit() nicht mehr für neue Entwicklungen/Projekte verwenden für die nimmt man heute wohl besser Datatables .........

Aber wenn Textmode Apps gewünscht sind ist DBEDIT() eine alte aber super Funktion.
Valar Morghulis

Gruss Carlo
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: DbEdit auf Array

Beitrag von ramses »

@Jan

Hallo Jan

ich vergass gestern: DBEDIT() kannst du nicht auf Arrays verwenden. Nur auf DBF's weil du keinen Zugriff auf die Skipper hast.
Mich hat das aber nie gestört weil eine frühe, sehr wichtige Pflicht war wiederaufnahme der Arbeit nach z.B. Stromausfall ohne Verlust der bereits eingegebenen Auftragszeilen. Ich arbeite deshalb noch immer bei Eingaben immer mit lokalen DBF's etc. nie mit Array's oder gar ungesichert über mehrere Zeilen.
Valar Morghulis

Gruss Carlo
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: DbEdit auf Array

Beitrag von Jan »

Carlo,

da bin ich mir nicht ganz sicher. Ich habe da den Skipper nachgebaut, und es scheint auch erst einmal zu funktionieren. Jedenfalls solange ich nur einen Satz im Array habe. Bei zwei Sätzen scheppert das in der Event-Schleife, weil der angeblich das Array nicht kennen würde. Bis dahin kannte der das aber überall, z. B. um die TbColumns aufzubauen.

Dabei geht es um die Ablösung einer Zwischendatei, die nur für die Bearbeitung benötigt wird. Die haben da seit vielen Jahren ein schwieriges Konstrukt, das etwas unflexibel ist und extrem wartungsaufwändig bei Strukturänderungen. Da das System aber nach meinen ganzen Arbeiten daran in den letzten Jahren inzwischen äußerst stabil läuft, die Daten also nicht mehr zur Rekonstruktion in einer dbf gesichert sein müssen, will ich das auf eine virtuelle Bearbeitung umbauen. Und da das ganze Teil im DOS-Fenster läuft würde ich gerne beim bislang auch verwendeten DbEdit bleiben. Dann sind auch die restlichen Anpassungen minimal. Ich muß es halt nur hinbekommen daß der auch auf eine Tabelle mit mehreren Sätzen geht.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: DbEdit auf Array

Beitrag von ramses »

Hallo Jan

ich bin der Meinung dass DBEDIT() mit Array's nicht funktioniert. ....

Vielleicht ist es einfacher dein "schwieriges Konstrukt" irgendwie so zu lösen so dass es auch bei Strukturänderungen keine Wartung braucht als das ganze auf Array's umzubauen.

Den Sourcecode von DBEDIT() findest du unter ./source/runtime/sys/dbedit.prg damit hättest du zugriff auf die dahinterliegenden Klassenmethoden zum umbauen auf eine eigene Fassung von dbedit() für Array's .
Valar Morghulis

Gruss Carlo
Dieter
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 237
Registriert: Do, 14. Aug 2008 14:59
Wohnort: Straelen
Hat sich bedankt: 2 Mal
Danksagung erhalten: 3 Mal

Re: DbEdit auf Array

Beitrag von Dieter »

Hallo Carlo,

Deiner Ausführung:
Aber wenn Textmode Apps gewünscht sind ist DBEDIT() eine alte aber super Funktion.
muss ich in Hinblick auf die Zukunftsfähigkeit und Wartbarkeit widersprechen.

In Textmode-Programmen kann man wunderbar mit der TBROWSE-Klasse Tabellen programmieren, um gut dokumentierten und wartbaren Code zu schreiben. Die DBEDIT-Funktion setzt zwar auf TBROWSE auf (siehe ALASKA-Quellcode) beschränkt aber die tatsächliche Leistungsfähigkeit, da nicht klassenbasiert programmiert werden kann. Auch Alaska empfiehlt DBEDIT durch TBROWSE zu ersetzen:
The function DbEdit() is purely a compatibility function which makes a database file browser available. The capabilities of a TBrowse object should be used instead of DbEdit().
Den Ausführungen von Jan kann ich entnehmen, dass die Software noch im DOS-Fenster läuft!?
Wenn für ein Unternehmen ein Textmode-Programm so wichtig ist, dass man Programmierer bezahlt, die das Programm erweitern beziehungsweise lauffähig halten, dann bin ich der Meinung, dass der Programmierer als erstes die alte Software in einem CRT-Fenster, welches in einem GUI-Fenster liegt, zum Laufen bringt (GUI=YES). Die Schriftgrößen im CRT-Fenster werden aufgrund der Bildschirmauflösung dynamisch eingestellt, sodass auch auf allen hochauflösenden Bildschirmen (zum Beispiel 4K oder 8K) in Zukunft mit dem Textmode-Programm gearbeitet werden kann.

Um die Wartbarkeit und Zukunftsfähigkeit von altem Code zu gewährleisten, muss man hin und wieder auch ganze Codebereiche neu schreiben. Wem das zu aufwendig ist, darf sich später nicht wundern, wenn irgendwann die gesamte Programmweiterentwicklung eingestellt wird. Guten Textmode-Code könnte man dann auch später problemlos auf GUI umprogrammieren. Zum Beispiel TBROWSE- in XBPBROWSE-Objekte umwandeln.
Klar ist, dass alle Programmänderungen Zeit kosten, die die Programmwartbarkeit sicherstellt. Diese muss vom Auftraggeber aber auch gewünscht und bezahlt werden.
Deine Empfehlung an Jan, die DBEDIT-Funktion zu erweitern, halte ich im Zusammenhang mit meinen vorgenannten Ausführungen für eine nicht so gute Idee. Die Umsetzung direkt mit der TBROWSE-Klasse dürfte zukunftssicherer sein und vor allem zu einem wartbaren Code führen. DBEDIT hat meiner Meinung nach keine Zukunft.
Viele Grüße

Dieter

Was man nicht versteht, besitzt man nicht.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: DbEdit auf Array

Beitrag von Jan »

Dieter,

Du gibst Dir sehr viel Mühe mich vom Irrsinn DbEdit() zu überzeugen. Das wirst Du aber in diesem Fall nicht schaffen. Auch wenn es in diesem Thread um die Lösung meines Problems geht, und wir hier mehr über den Sinn oder Unsinn von DbEdit sprechen als über meine Frage, möchte ich Dir doch eine Antwort dazu geben.

Dieser spezielle Kunde hat, wie jeder andere Kunde auch, mir gewisse Vorgaben für die Entwicklung gegeben. Hier sind die allerdings umfassender. Speziell sind hier: DOS-Oberfläche, und keine Klassen. Es gibt dafür auch einen guten Grund: Er ist Geschäftsführer eines Unternehmens mit einem Umsatz von mehreren Mio. € im Jahr. Und hat schon immer von Anfang an die Programmierung gemacht. Bis ich da vor knapp 10 Jahren ins Spiel kam, nachdem er Ausflüge auf professionelle ERP-Systeme gemacht hatte, die grandios gescheitert sind. Er suchte also jemanden, der seine alte Software auf ein aktuelles Niveau bringt. Dabei ist er immer noch selber auch Programmierer. Und der Fallback, wenn ich mal nicht greifbar bin. Da er zwar schon seit dBase II unter Apple selber programmiert, ist er aber doch bei Clipper-Niveau stehen geblieben. Klassen und LOCALs sind Fremdworte für ihn. Von LOCALs konnte ich ihn inzwischen überzeugen, Klassen sind aber tabu. Denn er muß Korrekturen auf seinem Wissenstand der Programmierung vonehmen können. Sollte es eines Tages dort den dringend gesuchten fest angestellten zweiten Xbase++-Entwickler geben, der dann mein Fallback sein könnte, haben wir freie Hand, wie wir Programmieren. Aber bis dahin gelten seine Regeln.

Mir ist vollkommen bewußt das DbEdit() auf TBrowse() beruht. Aber da ich die DbEdit.prg in das Projekt eingebunden habe und dort am Code modifiziere, um den auf Array-Nutzung anpassen zu können, kann ich durchaus TBrowse() verwenden. Aber im eigentlichen Code steht doch weiterhin das dem Kunden bekannte DbEdit().

Du kannst sicher sein das ich im Hintergrund alles mache, um die Programme dort im gesetzten engen Rahmen zukunftssicher zu gestalten. Die Programme sind dadurch um Welten stabiler geworden als damals, als ich die in die Hand gedrückt bekommen habe. Einer der Schritte war das von Dir aufgeführte Umstellen auf GUI = Yes. Das ändert grundsätzlich ja erst einmal nichts am Code, der Kunde hat das gar nicht mitbekommen. Es erlaubt mir aber manches, was sonst nicht ginge.

Ich hoffe dieser kleine Ausflug jenseits meiner Fragestellung hilft Dir ein wenig zu verstehen, warum ich das so mache wie ich es mache, und warum ich es nicht anders mache/machen kann. Und jetzt wäre ich dankbar wenn wir zur eigentlichen Frage zurück kehren könnten.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: DbEdit auf Array

Beitrag von ramses »

Hallo Dieter

ich habe einen etwas anderen Blickwinkel. In den Grundzügen gebe ich dir durchaus recht.

Selbst habe ich einige Textmode-Apps die im CRT-Fenster laufen.
Diese Kunden wollen auch gar keine GUI-Apps. Dafür ab und zu noch kleine Erweiterungen. Die sind dann in Textmode-Apps wirklich schnell und einfach gemacht.

Von den Xbase++ GUI-Apps die ich laufe der Jahre geschrieben habe habe ich in den letzten 10 Jahren das meiste nach HTML portiert mit xb2net Bootstrap/JQuery/Datatables und L&L usw. also zu Web-Apps gemacht.

Ich sehe die Zukunft von grafischen Oberflächen mit wenigen Ausnahmen in Browserbasierten Web-Apps die ohne Installation benutzerseitig auf beliebigen Geräten laufen.

Windows-GUI-Apps haben meiner Meinung nach keine Zukunft mehr.

Im weiteren kann ich mich nur voll und ganz den Ausführungen von Jan anschliessen.
Valar Morghulis

Gruss Carlo
Antworten