Inoffizielles deutsches Xbase-Forum

Jan,
was hindert DIch daran, die Funktionen oder Prozeduren mit Parametern zu versehen?

Martin,

nichts. Mach ich ja auch. Hab ich doch geschrieben.

Jan

Dann ist ja gut - hatte das anders verstanden.

Viele Grüße,
Martin

Jan hat geschrieben:Ich arbeite z. B. gerade an einem alten Kunden-Projekt, das seine Wurzeln noch in DBASE 2 hat, und über Clipper dann nach Xbase++ gekommen ist. Da ist traditionell jede Variable PUBLIC, wenn die überhaupt deklariert wurde. Es gibt tausende davon! Ich habe schon mehrere Hundert korrigiert/umgeschrieben, und alles, was ich neu schreibe oder umschreibe, wird natürlich sofort korrekt benamt, soweit möglich. Aber die Korrekturen der Altlasten nehmen unglaublich viel Zeit in Anspruch. Ich habe dadurch auch schon teilweise schon Fehler eingebaut.

In solchen Fällen wäre ein Neuschreiben der Sache klar von Vorteil gewesen. So kann sauber in GUI programmiert werden und die ganze Sache wird zugleich attraktiv mit vielen neuen Möglichkeiten versehen - und, ganz wichtig, ausbaufähig für die Zukunft. Und hättest keinen Variablensalat.

Hallo herbert,

*grins* sooo einfach ist das aber nicht. Der Kunde ist gegen GUI, weil GUI langsamer zu programmieren ist und die Bedienung nicht so schnell geht. Sagt er. Und Klassen sind verboten, weil er die nicht versteht. Schon mehrdimensionale Arrays sind ansich zu kompliziert und eher unerwünscht (ich bau die aber trotzdem ein!).

Von daher: Den alten Code lassen. Ich erweitere da massiv die Funktionalität, merze Fehler aus, räume auf, aber die Optik muß halbwegs bleiben wie sie ist, also Clipper-Style. Und eben nicht zu viele moderne Programmiersprachen-Elemente. Scopes sind übrigens OK, weil er die halbwegs versteht, und er den gewaltigen Geschwindigkeitsvorteil gegenüber den bisher verwendeten Filtern sieht.

Jan

Was für eine eigenartige, unwirtschaftliche Ansicht der Sache... na dann

Herbert,

der Kunde ist immer König. Ich nur Ratgeber und Stabsstelle.

Jan

Jan hat geschrieben:Herbert,
der Kunde ist immer König. Ich nur Ratgeber und Stabsstelle.
Jan

=D>

aber ehrlich, scheiß Job ...

genau,
man sollte nicht alles aus der Sicht des Programmierers sehen,
sondern sich auch in die Lage des Anwenders versetzen.

GUI ist nicht das Maß der Dinge und der Programmierer nicht der King.
Warum sollte man etwas das gut läuft (.z.B. überwiegend Zahlen oder Stammdaten erfassen)
mit aller Gewalt auf GUI umstellen ? Das ist eigenartig und unwirtschaftlich (für den Programmierer).

Interessant wäre mal eine Studie, die die Anzahl der Tennisarme seit Windows XP darlegt

Koverhage hat geschrieben:man sollte nicht alles aus der Sicht des Programmierers sehen,
sondern sich auch in die Lage des Anwenders versetzen.
GUI ist nicht das Maß der Dinge und der Programmierer nicht der King.
Warum sollte man etwas das gut läuft (.z.B. überwiegend Zahlen oder Stammdaten erfassen)
mit aller Gewalt auf GUI umstellen ? Das ist eigenartig und unwirtschaftlich (für den Programmierer).

Habe da auch nicht widersprochen. Klar, dass der Kunde entscheidet und der Programmierer, wenn er nicht selber etwas entwickelt, nimmt einen Auftrag mit den gegebenen Bedinungen an.
Sonst bin ich gar nicht deiner Meinung.
Ausgangslage war das Zitat von Jan, dass das Programm aus Dbase2, zu Clipper, zu Xbase "portiert" wurde, also uralt-Code mit steinalten Mechanismen, die eigenartigerweise in Xbase noch unterstützt werden. Jan schreibt selber dass dies alles zeitaufwändig sei. Alleine die Aussage, dass "tausende von Variablen" vorhanden sind, lässt erschaudern.

Aber wie geschrieben, wenn der Kunde dies will und Jan dies so als Auftrag entgegengenommen hatte, klar. Diese Voraussetzunge kannte ich zum Zeitpunkt meines Postings ja nicht.
Aber sonst ist da sicher nichts von Gewalt und so, sondern reine Effizienz in die Zukunft für Entwickler, Anwender und Auftraggeber.

Werner_Bayern hat geschrieben:

AUGE_OHR hat geschrieben:deshalb nehme ich jetzt für Variablen, welche ich in der 1st Errorsys die vor MAIN geladen wird, verwenden will den Type PUBLIC wenn ich mit Threads arbeite.

Um was zu erreichen, was mit locals nicht geht?

hab ich doch geschrieben : wenn ich Informationen in die 1st Errorsys übernehmen will wie User_ID, Version, Workstation Name, Path etc.

Jan hat geschrieben:Da ist traditionell jede Variable PUBLIC, wenn die überhaupt deklariert wurde.

Einspruch : die sind PRIVATE (siehe Beispiel oben)

bei Cl*pper war das Problem die DGroup wo die PUBLIC und PRIVATE rein gehen die 64kb(!) gross ist.
durch die LOCAL / STATIC von Cl*pper v5.x war es erstmals möglich die DGroup zu reduzieren damit man mehr Code schreiben konnte.

AUGE_OHR hat geschrieben:wenn ich Informationen in die 1st Errorsys übernehmen will wie User_ID, Version, Workstation Name, Path etc.

Ok.
Dazu würde ich mir eine Funktion schreiben, die Static-Var(s) enthält.

ich habe das gesamte Thema nicht sauber durchgelesen, sondern überflogen und hoffe, dass ich das nicht schon erwähnt hatte. Bei einem Treffen in Leverkusen, an dem auch Till von Alaska teilnahm, sagte dieser einmal folgendes: Man kann auch alle Public Variablen in eine Public Klasse als iVar packen und dann nur das Objekt mitschleppen. Hat den Vorteil, man sieht im Debugger im Objekt Inspector alles direkt auf einmal. Das mache ich auch so, wenn es denn um etliche Vars geht. Ich finde die Lösung recht gut.

manfred,

etwas ähnliches mache ich (in meinen eigenen Projekten): Ich pack das einfach in ein DataObject. Einfach, schnell, übersichtlich.

Geht nur leider bei dem betreffenden Kunden nicht, da der sich Klassen verweigert. Selbst so einfachen.

Jan

Ist ja ein DataObject und keine Klasse .