Nexus-Office Migration CL5.2 nach XBase

[FlashNash]

Nach dem ich mich hier nun bisschen eingelesen habe, hier meine erste Frage als XBase Newbe, was den aktuellen Stand von XBase und dessen Möglichkeiten betrifft. Okay, ich möchte eine recht umfassende CL5.2 Applk. nach XBase umsetzen. Bevor ich aber ´in die Tasche´ greife und mir alle erforderlichen Lizenzen kaufe, möchte ich einmal die XBase Insider bzw. Migrations-Spezialisten um Rat fragen.

Schon klar, man kann keine allumfassende Antwort erwarten und auch theoretisch zu erklären, was man von CL5.2 nach XBase umsetzen möchte würde ein kleines Buchwerk ergeben. Vondaher habe ich hier mal einen Link zu meinem Nexus Office. Dabei handelt es sich natürlich um das ursprüngliche DOS-Programm. Ich hatte es in den 80zigern programmiert und bis mitte/ende der 90ziger noch gepflegt. Dann kam das AUS, da nicht Windowsfähig und Nuntucket bzw. CA mit keinem guten Clippernachfolger aus dem Sulki kam.

Nexus-Office läuft unter Win XP + SP2 einwandfrei !!
Hier mal in Auszug mit den Hinweisen aus dem Readme. Ja, ja, sind teilweise Hinweise für DAUs aber ich habs hier einfach mal reinkopiert. Vielleicht schaut sich einer der Megrierungs-Spzialisten das Programm mal an und kann mir verklickern, ob das überhaupt machbar ist nach XBase umzusetzen. Pi mal Daumen sind das ca. 20MB Sourcen ... und ja mir ist klar, dass es eine Menge ´handwork´ erfordert, trotz recht sauberer Cl5.2 Sourcen/Programmierung.

Ich bin für jden Hnweis und Tip dankbar.


NEXUS-OFFICE SAA Versionen: LITE + MINI + MAXI - Firmencontrolling & Warenwirtschaftssystem

-- Computerkassenlösung
-- Aquisitionsabwicklung
-- Auftragsabwicklung
-- Reparaturabwicklung
-- Offene Posten & Mahnwesen
-- Auftragsachiv & Ablage
-- Einkauf & Bestellwesen
-- Artikelverwaltung
-- Kundenverwaltung
-- Lieferantenverwaltung
-- Personalverwaltung
-- Spesen & KFZ-Kosten
-- Textsystem, Einzel/Kettenbrief
-- E/A Kassenbuch/šberschussrechnung
-- Finanzbuchhaltung (DATEV,Mand.fähig.)
-- Inventurabwicklung
-- Disketten- u. Adresslabel Maker
-- Filemanger u. Fileverwaltung
-- Konfigurierbare DOS-Shell
-- Hotkey für Pocketrechner
-- Hotkey für Notizen
-- Hotkey für Onlinehandbuch
-- Hotkey für PLZ-Verzeichnis
-- Hotkey für Tel.Vorw.Nummern
-- Hotkey für Kalendar



Installation unter Windows XP (Auszug aus dem Readme)
-----------------------------------------------------------------------------------

1. Das Archiv NEXUS.ZIP in das Hauptverzeichnis nach Festplatte C:\ herunterladen


2. Das Archiv NEXUS.ZIP entpacken. Es entpackt sich in ein neues Verzichnis nach C:\Nexus


3. In die Datei C:\Windows\System32\Config.NT mit dem normalen Windows Editor die folgenden Zeilen anfügen, falls diese noch nicht vorhanden sind. Meißt ist dos=high;umb so wie device=%SystemRoot%\system32\himem.sys bereits in der Datei Config.NT schon enthalten. In dem Fall muss lediglich eine Zeile mit files=149 hinzugefügt werden!

dos=high,umb
device=%SystemRoot%\system32\himem.sys
files=149


4. Danach startet man den PC neu


5. Nach dem Neustart aus Verzeichnis C:\Nexus mit folgenden Dateien die Programme Nexus-Office Lite - Mini - Maxi starten:

Nexus-Lite.PIF - startet Nexus Office Lite
Nexus-Mini.PIF - startet Nexus Office Mini
Nexus-Maxi.PIF - startet Nexus Office Maxi


Oder aber, man zieht die drei PIF Dateien mit der rechten Maustaste auf das Desktop und wählt danach ´verknüpfen´. Danach kann man vom Desktop aus, durch Mausklick, die drei Nexus-Office Versionen Lite - Mini - Maxi starten.


Hinweis:
-----------
Soll Nexus-Office auf einer anderen Festplatte als Laufwerk C: bzw. in einem anderen Verzeichnis ablaufen, so muss der Laufwerkskenner in den drei PIF Dateien angepasst werden. Dies erledigt man in dem man mit der rechten Maustaste auf die PIF Dateien klickt und danach unter
´Eigenschaften´--> ´Programme´ in dem Feld ´Arbeitsverzeichnis´
den Laufwerkskenner und ev. den Verzeichnisnamen ändert.

Bei Nexus-Office handelt es sich um eine reine DOS Version. Das Programm wird nicht mit der Maus sondern wird mit den vier Richtungstasten (auf/ab/rechts/links) an der Tastatur gesteuert. Hinweise zu der Tastensteuerungen zeigt das Programm nach dem Start am Bildschirm.

[brandelh]

Hi,

sieh dir mal diesen Thread an, da gibt es einen Vortrag von mir zum Thema Migration:

http://www.xbaseforum.de/viewtopic.php?t=2294

dann lade dir von der Alaska Website die Demo-Version von Xbase++ herunter. Wenn du keine Fremdbibliotheken brauchst (außer CAToolsIII, die gibts auch) hast du gute Chancen schnell Ergebnisse zu sehen.

Allerdings musst du natürlich wissen, dass eine schnelle direkte Umsetzung genauso aussieht wie das alte Programm (ohne die vielen Beschränkungen aus DOS). Wenn du GUI willst heist es erstmal viel lernen ...

Prozedurale Programmierung (das Programm steuert wo ich bin und wohin es geht) nach
ereignisgesteuerter Programmierung (ich muss unerwünschte Menüpunkte abschalten und Reaktionscode für alle möglichen schreiben).

GUI Fenster neu entwickeln, wobei es einige gibt, die eXpress nutzen um im alten Quellcode GUI zu bekommen (dafür gibt es auch eine DEMO - meine ich zumindest, ich nutze das nicht) oder mit Xbase++ eigene Fenster zu machen (der Painter könnte besser sein!), das ist schwieriger aber auch flexibler.

[Jan]

Hallo,

erstmal vorneweg: Mir persönlich fällt es leichter wenn ich weiß, wie mein gegenüber heißt. Vermutlich nicht wirklich nashflash, oder

Nächster Punkt: Deine Anwendung habe ich runtergeladen, kann die aber nicht starten. Fehler bei der Speicherauslagerungsdatei.

Aber trotzdem: Du bist genau richtig hier im Forum. Hier laufen viele rum, die genau das hinter sich haben: Applikationen von DOS nach Windows schieben. Es ist auch gut daß Dir klar ist, daß das kein Spaziergang wird.

Prinzipiell gibt es hier 2 Lager. Welchem Du angehören möchtest mußt Du entscheiden. Die einen (und dazu zähle ich) bauen das mit pure Xbase++ um. Das ist die Ochsentour. Denn Du kannst, wenn überhaupt, nur die Logik im Hintergrund weiterverwenden. Alles optische mußt Du neu machen. Und eben auch so manches im Hintergrund. Denn Xbase++ ist natürlich OOP, aber auch Eventgesteuert. Was ganz neues für Clipperaner. Die andere Gruppe nimmt dafür Tools. Sehr beliebt sind dafür eXpress++ und Topdown, wobei mir scheint, das eXpress++ verbreiteter zu sein scheint, zumindest bei den Forenteilnehmern. Das kostet natürlich extra Geld, aber in der Optik kann man sehr viel von der alten Clipper-Logik mit @...Say und Get weiterverwenden.

Mußt Du entscheiden, was Du da machen möchtest. Oder finanziell kannst. Aber egal welchen Weg Du gehst: Du findest hier die Unterstützung, die Du brauchst. Dazu solltest Du auch mal schauen, ob es eine XUG (Xbase++-User-Group) in Deiner Nähe gibt. Da kann man sich mit anderen Xbaselern treffen, Vorträge anhören, und Probleme oder Ideeen diskutieren. Das nächste Treffen der XUG Osnabrück z. B. findet am 23. August um 14:00 Uhr in Herford statt. Könnte für Dich interessant sein, wenn ich dem Link ganz unten in dem Beitrag folge.

Jan

[FlashNash]

Zunächst erst einmal THX für die quick response.

@brandelh
Die Demo habe ich mir schon besorgt. Ich muss erst einmal meine Workstation etwas auf die Clipper Umgebung rüsten.
eXpress habe ich mir auch schon besorgt. Beides werde ich schnellstmöglich mal antesten. Mein eigentliches Prob ist
halt ´freie Zeit´. Danke auch für den Link. Auf Deiner Seite war ich schon gesten


@Jan

Mir persönlich fällt es leichter wenn ich weiß, wie mein gegenüber heißt.

Das ist kein Geheimnis, mein real Name ist Rolf. Unter dem Name bin ich auch in meinem Board (Ruhrpottboard.de) unterwegs.Ich wohne in der Nähe von Recklinghausen ... Osnabrück ist also nicht so weit. Nur halt mein Zeitproblem.

Nächster Punkt: Deine Anwendung habe ich runtergeladen, kann die aber nicht starten. Fehler bei der Speicherauslagerungsdatei.

Hmmm... könnte an einem falschen Swap-Path liegen, der in der ersten Version in einer DBF enthalten war. Wie auch immer, ich habe nochmal eine cleane NEXUS-OFFICE Version hochgeladen und zurück gesaugt. Die wiederum, wie m Readme beschrieben auf C:\Nexus gelegt und mit den PIF´s gestartet. Alles löppt hier auf zwei Rechner einwandfrei.

Ansonsten werde ich mir erst einmal XBase + eXpress zu Gemüte führen. Man muss ja nach fast 10 Jahren erst einma wieder bisschen reinkommen in die Clippersourcen/Umgebung. Dass es nicht mal so eben nach XBase umgesetz ist, das ist mir durchaus klar.

Ich bin ja schon mal froh einige Leute im Netz getroffen zu haben die überhaupt wissen was Clipper Compiler ist. Die jungen Hüpfer heutzutage zucke ja meißt nur mit den Schultern.

Eines steht aber etzt schon fest ... sollte ich die 20MB wirklich nach XBase umsetzen, dann als GUI .... die Ochsentour ... Augen zu und durch.
[/quote]

[Manfred]

Hi,

Eines steht aber etzt schon fest ... sollte ich die 20MB wirklich nach XBase umsetzen, dann als GUI .... die Ochsentour ... Augen zu und durch.

den Weg kenne ich

[Jan]

den Weg kenne ich

Und ich dachte, Du wärst noch beim kennen lernen

[Manfred]

Jan,

Du solltest es aber besser wissen. Du bist doch verheiratet. Die Kennenlernphase ist kurz, die Leidensphase ist dann um so länger.

[Jan]

Boahh ey, das hat gesessen. Du Theoretiker, Du.

Aber im Ernst: Sowohl meine Frau als auch Xbase++ bin ich noch am kennen lernen. Xbase++ seit ca. 6 Jahren. Mein Weib seit ziemlich genau 18 Jahren. Beides nimmt einfach kein Ende.

Trotzdem bereue ich beides nicht

Jan

[Rolf Ramacher]

Hi Jan

das war eine tolle Antwort.

Aber nun zu dir Rolf. Ich heisse auch Rolf. Unsere XUG - Treffen sich jeden 2.ten Dienstag im Monat bei der Fa. Tobax in Leverkusen. Wäre toll, wenn du auch mal vorbeikommen würdest.

Ich gehe gerade auch den Weg clipper nach xbase++ zu migrieren. Aber jetzt bei der 2. ten Firma. Ich xbase programmiere ich auch schon seit ca. 6 Jahren. (wie Jan)

Ich setze die Programm direkt in GUI um. (Ereignis gesteuert. - event-Handle). Manfred hat wenn ich das richtig im Kopf habe vorher auf Hybridmodus und ist jetzt dabei auf GUI zu gehen. eXpress habe ich nicht.
Mit dem normalen Xbase + die Tools hiervon komme ich wunderbar zurecht. Und es gibt ja auch noch dieses tolle Forum.
Aber wie Jan schon sagte : es wird ein steiniger Weg.

Hier erfährst du doch immer wieder neue Dinge.

[Jan]

Hallo Rolf R.

war das jetzt ein Kompliment? Oder eher nicht?

Manfred hat wenn ich das richtig im Kopf habe vorher auf Hybridmodus und ist jetzt dabei auf GUI zu gehen.

.. und nachdem er monatelang nicht auf uns in der XUG hören wollte und dann doch mit GUI angefangen hat bereut er nun zutiefst, nicht viel eher damit angefangen zu haben. So wie ich es nicht bereue, den Hybrid-Teil sofort übersprungen zu haben. Warum die doppelte Arbeit, wenn ich doch alles anpassen muß?

Jan

[Manfred]

Hier muß ich leider einmal ein Time out einbringen

Ich arbeite immer noch am Hybridmodus herum.......

Wenn auch nicht so ganz, wie ihr evtl. denkt.

[Tom]

Es kommt darauf an, wie viel Zeit man hat - und ob man das Rad wirklich neu erfinden muss und möchte. Wir haben vor fast zehn Jahren unsere monströse Clipper-Applikation mit Hilfe von eXpress++ ziemlich fix nach Xbase++ migriert und nutzen die sehr mächtige Bibliothek immer noch. eXpress++ ist nämlich längst nicht nur ein Migrationstool. Da es Objekte baut und letztlich selbst komplett in Xbase++ geschrieben ist (und mit Quellcode kommt), kann man nebenher ziemlich viel über den Präprozessor, Objekte, Eventhandling usw. lernen, was man auch tunlichst machen sollte, denn Windows-Anwendungen verhalten sich anders als DOS-Anwendungen. Jedenfalls ist die Migration auf diesem Weg geschätzt mindestens zehnmal so schnell möglich wie mit Bordmitteln, und im Ergebnis sieht es genauso aus, wenn nicht sogar schöner. Und die gesparte Zeit kann man z.B. dafür einsetzen, einen State-of-the-Art-Formulargenerator zu integrieren oder mit Active-X-Geschichten herumzuspielen.

[Manfred]

das ist schon so korrekt, wie Du es beschreibst.

Bei mir ist nur die Tatsache hinzugekommen, dass ich die kompletten DB Strukturen ändern mußte. Die Ursprünge liegen in den Anfängen der 90er Jahren und damals habe ich von Normalform und relationalen DB Systemen wenig gewußt. Das hat sich dann heute gerächt.

Nachdem ich ca. 60-70% neu programmiert hatte in GUI, habe ich dann festgestellt, dass der Umstieg nicht so geht. Leider.

Also muß ich doch noch ein Weilchen im Hybridmodus verweilen, was aber aus heutiger Sicht nicht mehr so schlimm ist. Ich habe in den letzten 6 Monaten sehr viel gelernt und alles vorbereitet, dass es bald soweit sein wird komplett auf GUI umzustellen. Die DB sind schrittweise angepaßt worden bisher und die Normalform auf den Rest, wird auch nicht mehr lange auf sich warten lassen.

Fazit: Wenn ich den Unterbau (DB) behalten kann, dann nur noch GUI, ansonsten eben so, wie es das Schicksal verlangt.

[FlashNash]

@ALLE
Ich merke schon, hier bin ich richtig und wie sagte die Feldbusch: ´Da werden sie geholfen´. Bevor ich aber mit del CL5.2 --> XBase (bzw. eXpress) Umsetzung beginne, muss ich mich erst einmal wieder etwas ´einarbeiten´ und mit dem für mich neuen XBase usw. beschäftigen.

Die letzen 10 Jahre habe ich nur in HTML, PHP, mySQL und JAVA gewurschtelt ... und bin momentan aus Clipper ´etwas raus´. Ist aber wie Fahrrad fahren .... verlernt man auch nicht ganz, wenn man es mal recht gut konnte. Na schaun mer amol.....


@Rolf R.

Unsere XUG - Treffen sich jeden 2.ten Dienstag im Monat bei der Fa. Tobax in Leverkusen. Wäre toll, wenn du auch mal vorbeikommen würdest.

Bis Leverkusen ist es von RE aus nicht sehr weit. Mal sehen, ev. klappt das mal bei Zeiten, dass ich vorbei komme.


@Tom
ZEIT ist genau mein Problem. Ich werde mich aber sicher in den nächsten tagen mit eXpress beschäftigen.

[Tom]

Der Migrationsschritt kann natürlich auch als Gelegenheit genutzt werden, sich von bösen Altlasten zu trennen. Weil unter DOS die Anzahl der gleichzeitig geöffneten Dateien Probleme machen konnte, hat man häufig Tabellen geschlossen, die man kurz darauf wieder brauchte. Man hat Daten redundant gehalten, weil Relationen und "normalisierte" Dateiverweise zu viel Performance gekostet haben. Man hat mit Hilfstabellen gearbeitet, weil Arrays begrenzt waren. All diesen Krempel (und noch viel mehr davon) wird man ziemlich elegant los, wenn man von vorne anfängt. Aber, wie gesagt: Das ist eine Frage der verfügbaren Zeit. Dem Anwender ist egal, wie elegant es intern gelöst ist, Hauptsache, es funktioniert, und das mit erträglichen Antwortzeiten. Was ich keinem Anwender zumuten würde, wäre, die Hybridzeit mitzuerleben. Deshalb haben wir auf diese verzichtet. (Obwohl der Name unserer Windows-Anwendung so entstanden ist: Aus CARE (DOS) wurde HyCARE (Windows), wobei das "Hy" auch dafür stehen sollte, dass es zunächst einen Hybrid geben würde. Den gab es aber nie - dank eXpress++. Inzwischen heißt die ganze Firma so.)

Was wir allerdings gleich zuerst gemacht haben, war die Nutzung des Multithreadings. Das ist mit Xbase++ so simpel, sicher und genial, dass man bescheuert wäre, es nicht zu nutzen, wenn es Sinn macht.

[Jan]

Hallo Tom,

auch wenn ich kein eXpress++ nutze:

Der Migrationsschritt kann natürlich auch als Gelegenheit genutzt werden, sich von bösen Altlasten zu trennen. Weil unter DOS die Anzahl der gleichzeitig geöffneten Dateien Probleme machen konnte, hat man häufig Tabellen geschlossen, die man kurz darauf wieder brauchte. Man hat Daten redundant gehalten, weil Relationen und "normalisierte" Dateiverweise zu viel Performance gekostet haben. Man hat mit Hilfstabellen gearbeitet, weil Arrays begrenzt waren. All diesen Krempel (und noch viel mehr davon) wird man ziemlich elegant los, wenn man von vorne anfängt.

JAWOLL!!!

Was ich keinem Anwender zumuten würde, wäre, die Hybridzeit mitzuerleben.

Sehe ich genau so. Es mag aber Sachen geben, wo das so nicht läuft. Siehe Manfred.

Was wir allerdings gleich zuerst gemacht haben, war die Nutzung des Multithreadings. Das ist mit Xbase++ so simpel, sicher und genial, dass man bescheuert wäre, es nicht zu nutzen, wenn es Sinn macht.

Genau! Das habe ich leider viel zu spät gemerkt. Du hast recht: So was von einfach. Und sowas von Produktivitätssteigernd! Alleine das ist schon fast den Umstieg auf Xbase++ wert.

Nette Bewerkung übrigens über die Herleitung Deines (naja, zur Hälfte jedenfalls, denke ich mal) Firmennamens. Ich dachte immer, das "Hy" käme von "hochwertige" (phonetisch = "high") Pflege. Auf den Gedanken mit Hybrid muß man erstmal kommen

Jan

[Tom]

Hallo, Jan.

Es war beides (bezogen auf den Firmennamen). Die Firmenneugründung ging mit der Windows-Migration einher, deshalb bezog sich der Präfix einerseits auf die geplante (und nie in Angriff genommene) Hybridversion (das weiß aber kein Kunde) und sollte andererseits (weil auch "high" ausgesprochen) auf den enormen Fortschritt hinweisen und sich als Marke etablieren (was funktioniert hat). Vermutlich weiß außer mir hier im Haus niemand mehr vom ursprünglichen (Mit-)Grund für diesen Namen.

[AUGE_OHR]

hi,

Prinzipiell gibt es hier 2 Lager.

eigendlich 3, weil Auftrags Programmierer der es nach Wunsch macht.

Wenn man keine 3rd.-Party Libs, ausser CA Tools, verwendet ist die
umsetzung in den 32bit Hybrid Modus sehr schnell auch ohne Zusatz
zu erledigen. Eine Cl*pper Anwendung mit ca. 15000 Zeile hab ich an
einem Wochenende erledigt nur bei den Print Listen brauche ich für
L&L ein wenig länger.

Eine vollständige GUI Umsetzung ist nun wieder was völlig anderes
und man kann praktisch eine Zeile aus seinem alten Code übernehmen
wenn die irgendwas mit Ein/Ausgabe zu tun hat.

Im wesentlichen hat man es ja mit Masken zu tun. Hierfür hat Xbase++
einen Formdesigner der leider nur einige rundimentäre Funktionen hat.
Er kann aber Source Code generieren wobei dringent zu OOP Class
Code geraten wird unter GUI.

Nicht zu unterschätzen ist auch die reine Anzahl von Zeilen. Hat man
unter Cl*pper schon mit paar Zeile eine Maske mit Ein/Ausgabe so
muss man unter GUI erstmal einen Dialog ( FORM ) haben auf dessen
:drawingarea dann die XbParts plaziert werden können ... da kommen
leicht paar hundert Zeilen zusammen.

wenn also Zeit das Problem ist solltest du dir ein Angebot machen lassen
und abschätzen ob sich das für dich lohnt wobei ich als "Hausnummer"
ca. 0,10 Euro pro Zeile der alten Cl*pper Anwendung rechnen würde.

[FlashNash]

wenn also Zeit das Problem ist solltest du dir ein Angebot machen lassen und abschätzen ob sich das für dich lohnt wobei ich als "Hausnummer" ca. 0,10 Euro pro Zeile der alten Cl*pper Anwendung rechnen würde.

Nexus Office ist meine Applikation d.h. die habe ich in den 80zigern geproggt ... und damals auch ganz gut Geld damit verdient. Ich möchte das DING einfach mal umsetzen ... so pö a pö und ganz für mich selber. Das große Geld ist heute damit sicher nicht zu verdienen ... nur als DOS Programm ist es ja ´optisch´ völlig unbrauchbar ... in der heutigen Windowswelt, obwohl es unter XP + SP2 fehlerfrei runnt. Sowas will ja niemand mehr anwenden.

[FlashNash]

Was geht bei mir derzeit so ab ... mit der ollen, alten Nexus-Office Clippersache i.V. mit Xbase Migration?

Status bei mir ist derzeit wie folgt:
1. System: HW recht quick mit Win Prof. XP + SP2
2. Alte Clipper-Umgebung + Clipper (5.2e) + BLinker + Batches von einer CD raus gekramt und auf eine Platte kopiert
3. Eine alte Batch (SetToClp.BAT Insider wissen, was so ein Stapel macht) aufgerufen und danach Clipall.BAT + LinkAll.BAT gestartet.

Donnerwetter .... es hat gekclippt + gelinkt .... pötzlich war ich wieder in der Vergangenheit (80ziger bis 90ziger)

Offensichtlich hatte ich die in den 80zigern+90zigern angewendete BATCH Proggerei halbwegs und irgendwie begriffen .. haleluja ... es compilliert und linkt mit den asbach Batches unter XP Prof + SP2 ... genau wie damals unter DOS ... boahh ey, war ich damals gut *lach*

Nun wurde es aber ernst:

a) XBase Demo installiert
b) eXpress installiert (davon lasse ich erst einmal die Pfoten weg)
c) Alle Make Dateien (auch .CLP genannt) überarbeitet und alles umgebogen von Clipper.EXE auf XPP.EXE
d) ClipAll.BAT (das alte MAKE schlägt zu) aufgerufen ...halleluja .. ES compilliert ... wenn auch mit einigen rummeckern.

Ahhhhhhhhrrrg ... der Freitag ist gerettet, es clipt was mit XBase .. wenn auch fehlerhaft. Montag geht´s dann weiter, ich werde Euch berichten.

Derzeit bekomme ich ein paar Errormeldungen
x) does not end with RETURN (Blödsinn, RETURN ist überall drinn)
y) RETURN statement with no value in function (das muss ich mir genauer ansehen)
z) REQUEST declaration follows executable statement (keine Ahnung, was das bedeutet, werde nachlesen)

So Kollegen ... nun mache ich mal was Weekend ... werde aber weiter berichten und EUCH ALLE sicher noch nerven und zukünftig mit Fragen überschütten.

[Martin Altmann]

Hallo Rolf,
y bedeutet, dass Du eine FUNCTION hast, die nur mit RETURN endet, ohne einen Parameter zurückzugeben.
x und z sind (wahrscheinlich) ein Problem in der Reihenfolge (z.B. Deklaration der Variablen vom Typ local, private, public,...)

Viele Grüße,
Martin

[FlashNash]

Thx für die Hinweise Martin. So ähnlich hatte ich mir das auch schon gedacht. Nur ... nach fast 10 Jahre Clipper Abstinenz und rumpröddelei mit PHP, mySQL und JAVA ... da hat man von Clipper einiges nachzuholen ... bzw. wieder z erlernen ... will heißen, ich muss mich in Clipper erst mal ein paar Tage wieder ´eindenken´... danach sollte es wieder klappen.

Dennoch ... ich werde zukünftig sicher viele Fragen haben und bin, das gildet für die gesamte Zukunft, dankbar für jeden Hinweis und/oder Tipp.

Sicher, man kann im Alleingang alles selber dedizieren, muss aber nicht sein, wenn man sich in einer Gemeinschaft von Gleichgesinnten befindet. Und ... genau deswegen habe ich mich hier angemeldet.

Eventuell kann ich, im Gegenzug, mal was über PHP, mySQL oder JAVA ablassen d.h. irgend jemanden Hilfestellung geben. Genau so sehe ich eine gegenseitige und kostenlose Unsterstützung. Wie heißt es doch ... das Leben besteht aus ´geben und nehmen´.

[FlashNash]

Mal eine Frage zu den beiden folgenden Errormeldungen beim Compilieren mit XBase:

1. does not end with RETURN
2. RETURN statement with no value in function

Zu 1:
In den 2..3 Dateien, wo das angemeckert wird, IST ein RETURN drin. Es gibt bei mir keine Datei OHNE ein RETURN am Ende !!

Zu 2:
Auch hier ist immer ein RETURN(true,false,NIL) drin. Ich habe im Sourcecode (NIL) - (true) und (false) probiert .. keine Veränderung. Selbstverständlich ist true + false (.t.) ... (.f.) als Variable definiert worden.

Im obigen Zusammenhang ruder ich derzeit völlig im Dunklen .. etwas anderes als (NIL) ... (true) ... (false) kenne ich aus dem Gedächnis nicht ...

Ja, ja ... aus Clipper fast 10 Jahre raus, nie weiter drum gekümmert und heute dumme Fagen stellen.... i know. Ich weiß schon, muss mich noch besser in Clipper ´eindenken´... aber ev. bekomme ich hier ein ´Stichwort´ d.h. mir muss man nicht alles in 1..2..3 DIN A4 Seiten erklären .. ein klitzekleiner Hinweis hilft mir sdchon oftmals sehr, sehr weiter, da ich damals mit dem Clipper gepennt habe ... muss halt erst Mal wieder etwas ´rein kommen´.

Bin für jeden Hnweis dankbar.

[Martin Altmann]

Hallo Rolf,
ich denke, Du willst Wochenende machen
Also: Dein erster Fehler kann mehrere Ursachen haben - z.B. einen falsch terminerten String
Bsp.:

Code: Alles auswählen

cText := "Text ohne Tüddelchen am Ende

Und der zweite Fall besagt, dass Du irgendwo eine FUNCTION hast, die am Ende nur ein RETURN stehen hat, ohne einen Wert mit zurückzugeben.
Am Besten zeigst Du mal den Source...

Viele Grüße,
Martin

[FlashNash]

Danke für den erneuten Hinweis Martin. Naja, WE machen ist bei mir so eine Sache, wenn ich mich mal in ´etwas´ festgebissen habe.

Ich werde Deine Hinweise mal überdenken/einfließen lassen ....

Sakkra ... der Clipper war doch nicht so kompliziert. Aber das wird schon noch. ROM ist ja auch nicht an einem Tag erbaut worden..

Ich hatte es ja schon angedroht, EUCH ALLE mit Fragen zu nerven. Klar, man kann fast alles alleine ermitteln, ich persönlich bin aber mit Stichwörtern und kurzen Hinweisen sehr, sehr geholfen.... naja, nicht immer ... aber immer öfter ... und muss dann nochmal nachhaken.