Musterprgramm zu GUI möglich??[ERLEDIGT]

[Rudolf]

Hallo,
einem Anfänger von eXpress++ abzuraten finden ich auch höchst eigenartig. Und wer die paar Euro dafür nicht investieren will ist selber schuld, dem ist die eigene Zeit nicht viel wert, soll es ja auch geben
Grüße
Rudolf

[Hans Zethofer]

vollkommen richtig die Aussage - unterschreibe ich 100% =D>

[Tom]

Leider muß ich sagen, für deine Zwecke war die Aussage express++ nicht zu nehmen vollkommen an der Realität vorbei.

Da kann ich Manfred nur beipflichten. Der Hybridmodus ist für den ... Rosettenhalter, weil's erstens ziemlich (unnötig) kompliziert ist, und zweitens einen völlig verzichtbaren Lernaufwand mit sich bringt. Edit: Und es sieht auch noch fürchterlich aus.

[Jan]

Dem kann ich nicht ganz zustimmen. Unbestritten ist natürlich, das eine Hybrid-Anwendung unnötig kompliziert wird, die Optik nicht gerade berauschend ist (hält sich aber in Grenzen, das geht eigentlich noch, manche GUI-Anwendug sieht grauenhafter aus), und man ansich lieber gleich komplett auf GUI umsteigen sollte.

Aber ich habe z. B, gerade einen Kunden, der auf textbasierter Oberfläche besteht. Warum ist jetzt erstmal egal, er hat so seine Gründe. Aber ich benötige für manche Konstrukte einfach GUI-Elemente, ohne das geht es nicht. Also habe ich das auf Hybrid gewandelt.

Ich bin natürlich selber nicht glücklich damit, und hoffe den Kunden irgendwann einmal auf komplett GUI überreden zu können. Aber im Moment ist es so. und es ist die beste Lösung unter den momentanen Bedingungen.

Jan

[AUGE_OHR]

hi,

was den ursprünglichen Titel angeht hörte sich das am Anfang ja noch ganz anders an.
die Frage ist doch wie weit Bernie ein > 300T Zeilen Programm noch "pflegen" will ?

ihr hab alle Recht das "wir" wohl inzwischen anders vorgehen ( und weitergehen ) würden
aber Bernie hat mit Cl*pper Code ja nicht unbedingt mit OOP und Class zu tun gehabt.

Bernie möchte doch "nur" seinen Cl*pper Code in einem CRT Fenster in die GUI (32/64bit) Welt bringen und mit /PM:PM dann AppEvent() verwenden.
ohne Änderungen an der AppSys.PRG würde man ja nur ein default 640x480 Fenster mit 25x80 bekommen.

so und nun laufen die 5min für "uns" ... Vorschläge :
eine Lösung + nächster Schritt "Menu"

ein XbpDialog, mit Menu, als "Shell" für "ein" CRT "inside" auf der o:Dialog:drawingArea.
der original Cl*pper Code läuft ja "ohne Probleme***" im CRT und die Focus Probleme
bekommt man durchaus in Griff bei "1 x Fenster" !
***alle NICHT Cl*pper Einstellungen NICHT verwenden !

ich denke für weiter Tips sollte Bernie dann einen neuen Thread eröffnen wo wir bei den Problemen eines Newbie explizit auf das Thema eingehen können.

[Tom]

Hallo, Jan.

Ich habe seinerzeit eine sehr, sehr komplexe Anwendung mit einem damals noch ziemlich unzuverlässigen Xbase++ und eXpress++ innerhalb einer Woche komplett auf GUI (mit Multithreading) umgestellt, und ich hatte auch danach noch immer keine Ahnung von Objekten, Eventschleifen und diesem Zeug - musste ich auch nicht. Es ist einfach unverantwortlich, jemandem, der vor allem ein schnelles, verlässliches Ergebnis benötigt, zum Hybridmodus zu raten. Klar, es gibt wohl immer noch Anwendungen, die textbasiert von bestimmten Leuten bevorzugt werden, aber darüber sprechen wir doch hier nicht, oder? Bei eXpress++ bindet man ein paar Include-Files und eine LIB ein, schraubt sich - klar, im Idealfall - durch die marginalen Änderungen des Codes und hat kurz danach ein richtiges, ansprechendes GUI-Programm, das man nur noch mit einer Manifestdatei versehen muss. Beim Hybridmodus ... ach, völlig sinnlos eigentlich, darüber zu reden. Das ist schlicht Quatsch.

[Koverhage]

Jan,

es gibt zwei Gründe, wobei diese auch zusammen gehören.
Speed und das Gedöns mit der Maus.

[UliTs]

... Beim Hybridmodus ... ach, völlig sinnlos eigentlich, darüber zu reden. Das ist schlicht Quatsch.

Also ich finde den Hybridmodus super und viel besser als den Textmodus! Mir hilft er auch in GUI-Fenstern, wenn schnelle Texteingaben erfolgen sollen. Dann öffne ich ein kleines XbpCrt-Fenster mit z.B. 5 Zeilen und 20 Spalten und darin hat man dann eine extrem schnelle Texteingabe.
--
Das Beispiel von Rudolf über den Express-Code zeigt auch gut, was mit daran so abschreckt: es wird die Kommandostruktur mit Hilfe des Präprozessors von xBase++ stark verändert bzw. erweitert.
Aber -soweit ich weiß- kann man Express auch ohne die CH-Includedateien mit Präprozessorbefehlen sehr gut verwenden, oder?

Uli

[brandelh]

Auch ich habe noch einige Anwendungen mit XbpCRT am Laufen. TOM meinte aber vermutlich das Mischen von @ SAY und neuen XbParts ...

[Rudolf]

Hallo,
verstehe ich nicht wo das Problem liegt dass eXpress++ viel über den Preprozessor macht, genau hier liegen ja die ganzen Vorteile. Mit lediglich ein paar Zeilen Code hat man sofort ein anständiges Ergebnis. Wo liegt der Sinn am Mehraufwand ohne dem prozeduralen Code ? Und es steht für jedes Getlistelement ein Objekt zur Verfügung wenn man es braucht.
Und wegen Geschwindigkeit hatte ich auch immer Bedenken, aber in der Zwischenzeit sind meine grafischen Dialoge mit eXpress++ nicht viel langesamer. Ich lege Buttons, Menüs etc. auch auf Shortcuts und definiere Hotkeys für bestimmte Funktionen, kann damit den Ablauf perfekt steuern und es geht blitzschnell. Es kommt also darauf an wie benutzerfreundlich man Dialoge unter Windows ausprogrammiert
Kann mir nicht vorstellen dass so ein Programm zu langsam ist für die Eingaben von Usern, bei mir hat sich zumindest noch keiner beschwert
Habe auch noch einige Clipper Programm in Firmen laufen die teilweise sehr komplexe Dinge machen, diese Kunden werden nie umsteigen, aber nur weil sie die Bedienung schon so gewohnt sind. Die bekommen Zusatzprogramme unter Windows wie z.B. für den Druck, Mailversand etc. Ich habe sogar eine Firma in der die Eltern mit der alten Clipper Version arbeiten und der Sohn mit der Windows Version.
Meine größte Fehlentscheidung war auch riesiege Programme vorschnell im Hybrindmodus umzustellen damit ich schnell ein Ergebnis sehe, habe es nach kurzer Zeit wieder aufgegeben und alles in echte Windwos Dialoge umgearbeitet. Der Mehraufwand hat sich gelohnt da ich sowieso irgendwann auf GUI umgestellt hätte. Der Zwischenschritt ist auch meiner Meinung nach total sinnlos.
Grüße
Rudolf

[AUGE_OHR]

TOM meinte aber vermutlich das Mischen von @ SAY und neuen XbParts ...

na ja ... wenn man den "richtigen" Parent hat geht das schon aber mit dem Focus Problemen kommt ein Newbie schnell an die Grenzen.

als ich mit Xbase++ angefangen haben war ich froh als ich DBU als 32bit Programm zu laufen bekam.
es existieren immer noch viele Cl*pper Applikationen die aber auf 64bit nicht laufen ( virtuelle etc. ausgenommen )
es "reicht" also erst mal den Cl*pper Source im CRT Fenster zu betreiben den "drucken" kann man damit auch über die Windows Drucker.

das Problem bei GUI sind doch die Masken die man erst "malen" muss d.h. man muss an den Source "ran".
das ist nun auch der Ansatz den ich mit Hybrid sehe. nicht nur "vereinzelte" XbParts sondern ganze Masken.

Masken von Stammdaten ist das erste was man sich mit dem Formdesigner XppFD.EXE vornehmen sollte.
diese können sehr umfangreich sein aber enthalten meisten keine grosse "Business Logik"
( extra Code ) den man in den generierten Class Code schreiben müsste.

Class Code und OOP sind für GUI ein "muss" aber es dauert für einen Cl*pper Programmierer einige Zeit
bis man seinen prozeduralen Style mit dem OOP Style zusammenbekommt.
wenn man erst mal diesen Hürde genommen hat und die Masken schon stehen kommt einem der Rest des Weges nach GUI relative kurz vor.

[Rudolf]

Hallo Jimmy,
kennst Du eXpress++ eigentlich ? wozu OOP wenn es ohne viel einfacher, schneller und mit viel mehr Möglichkeiten gibt. Würde gerne sehen wie einer meiner ziemlich komplexen Dialoge unter reinem XBase++ ausschauen würde und vor allem wie viel Zeit dazu benötigt wird. Das könnte außerdem nur ein echter XBase++ Profi, der ich aber nicht bin. Den Formdesigner von Xbase++ hab ich mir angeschaut, aber der taugt doch nur für sehr simple Masken. Und dann muss man noch alles manuell mühsam dazuprogrammieren um zu einer Lösung zu kommen. Ich kenne auch Formdesigner z.B. von Xailer oder XHarbour etc., hier kann man von einer echten Erleichterung beim Erstellen von Masken sprechen, bis dahin dauert es bei XBase++ sicher noch lange. Ich verstehe auch nicht wieso OOP und ClassCode bei Dialogen ein "muss" sein soll. Würde mich interessieren wo hier der Vorteile liegen sollen, vielleicht übersehe ich da etwas.
Es geht mir auch darum, dass neue XBase++ User aus der Clipper Umgebung nicht durch OOP und aufwändige Codeumstellungen verschreckt werden. Habe auch vor kurzem ein Projekt in US erfolgreich für die Umstellung von Clipper auf eXpress++ vorbereitet, ich glaube der Kunde ist sehr froh über diese Entscheidung da er innerhalb kürzester Zeit jetzt selbst alle Dialoge auf vernünftiges GUI umsetzen kann. Er hatte vorher nur niemanden gefunden der ihm Beispiele und den richtigen Einstieg gezeigt hat. Rogers Beispiele sind da nicht sehr übersichtlich und von der Optik nicht ansprechend.
Grüße
Rudolf
p.s. ich bekomme keine Provisionen von Roger

[Bernie]

Hallo an Alle,

ich denke jetzt reichen die Ratschläge mal aus. Wenn ich weitere Fragen habe, werde ich mich wieder melden.
Auch unter Spezialisten, die ihr sicher alle seit, gehen die Meinungen ja auseinander und jeder hat sein guten Gründe für seinen Weg.

Ich denke nun sind hier mal keine Antworten mehr notwendig.
Nochmals Danke an Alle. die sich so rege an dieser Diskussion beteiligt haben

Grüße aus Stuttgart
Bernie

[Manfred]

Hallo Bernie,

Du bist zwar schon lange hier angemeldet, aber warst noch nicht oft hier unterwegs? Das ist normal, wenn es sich irgendwann verselbständigt. Grins Dir einen und nimm es einfach so hin. Davon lebt das Forum. Und wie ich finde das tut es recht gut.

[Martin Altmann]

Moin Rudolf,

Würde gerne sehen wie einer meiner ziemlich komplexen Dialoge unter reinem XBase++ ausschauen würde...

nichts leichter als das: Einfach mit der Option für die ppo-Dateierstellung kompilieren, dann siehst Du es.

Viele Grüße,
Martin

[Rudolf]

Hallo Martin,
schau manchmal rein, aber ist nur die Zusammenstellung der Getlist, in purem XBase++ wären es sicher eine Vielzahl von Programmzeilen pro Xbase part. Möchte gar nicht wissen was mir da entgeht
Grüße
Rudolf

[UliTs]

...Den Formdesigner von Xbase++ hab ich mir angeschaut, aber der taugt doch nur für sehr simple Masken...
...Möchte gar nicht wissen was mir da entgeht ...

Da sprichst Du eines der Hauptprobleme von xBase++ an! aber wenn man einen guten Formdesigner hat und nutzt, dann wird es aber mit objektorientierter Programmierweise viel einfacher. Und der Umstieg von mit Hilfe von Express programmierte Dialoge auf mit Formdesigner erstellte Dialoge ist sicher noch schwerer als der Umstieg direkt von Clipper-Code ... Das ist, was Friedhelm nicht an Express gefällt.

Andererseits muss man sagen: wie viele Jahre sind vergangen ohne das Alaska einen brauchbaren Formdesigner zur Verfügung gestellt hat...

Uli

[brandelh]

TOM meinte aber vermutlich das Mischen von @ SAY und neuen XbParts ...

na ja ... wenn man den "richtigen" Parent hat geht das schon aber mit dem Focus Problemen kommt ein Newbie schnell an die Grenzen.

Ich wollte nicht sagen, dass es nicht geht, ich meine nur, dass das Ergebnis (vom Aussehen) die Arbeit nicht wert ist.

[AUGE_OHR]

kennst Du eXpress++ eigentlich ?

obwohl ich kein Express++ User bin "denke" ich kenne ich den "Source" von Express++ sehr gut
ich habe wie Ulli oder Friedhelm das Problem mit der Command "Sprache" und habe damals Topdown gewählt was mit Parameter arbeitet.

was den Formdesigner / Class Code / OOP angeht : alle XbParts sind doch Objecte aber ein Cl*pper Programmierer kennt gerade mal das TBrowse Object ( evtl Error Object )
deshalb ist der Class Code vom Formdesigner schon eine ganze Menge "Wert" und bringt einem OOP ein Stück näher.