Basis MDI Anwendung

Lutz Rübe · Beitrag von **Lutz Rübe** » Sa, 10. Mär 2007 12:23

Hallo alle miteinander,

irgendwie bin ich blöd und/oder begriffs-stutzig.

Kann mir mal jemand einen wirklich simplen Source-Code zeigen, der mir folgende Möglichkeiten bietet:

(1) Menu-Bar mit SubMenüs
(2) AppSys mit automatischer Screen- und Font-Size (für ASCII-Window)
(3) GUI-Anwendung mit AppBrowse, AppEdit, AppDisplay
(4) GUI-Anwendung mit einem mit dem Form-Designer erstellten Window
(5) netzwerkfähig
(6) Crt-Anwendung / Window

Ich habe zwar alle Elemente in meine Anwendung eingebaut, aber sie "harmonieren" nicht miteinander aus den folgenden Gründen:

zu (1): keine Probleme, gelöst mit: oSubMenu:addItem( { "~Einzel", {|| em_11() } } )
zu (2): funktioniert einwandfrei, dank eurer Hilfe zu einem früheren Zeitpunkt
zu (3): rufe ich aus der Menu-Bar auf, nach Beenden wird die komplette Anwendung beendet, Datenbanken können nicht geschlossen werden, Datensätze können nicht gesperrt werden
zu (4) Beenden der GUI Anwendung beendet die komplette Anwendung
zu (5): siehe (3) und (4)
zu (6): eine "MDI" Anwendung, so daß ich weitere Fenster öffnen könnte wäre hilfreich, ist aber ein Randproblem

Ich habe zwar schon eine Menge der Beispiel-Sources ausprobiert, aber die sind mir als "Anfänger" (noch) zu kompliziert und lösen andrerseits auch meine Probleme nicht.

Das Hauptproblem habe ich damit:
Aufruf einer GUI-Unteranwendung mit Öffnen, DB oder Record-Locking, Schließen und Rückkehr auf die "Hauptseite", das "Main-Menu".

Gibt es da nicht eine wirklich einfache Sample-Anwendung ohne viele Methoden, Classen, Objekten ? Die MDI-Demo ist mir mit dem MenuCreate und SubMenuCreate zu kompliziert. Zum Beispiel sollten die Steuerungsfunktionen (Vor, Zurück, Seek) nicht als SubMenu-Anwendungen sondern als Butten im jeweiligen Fenster existieren.

Gerne stelle ich euch auch meinen verhunztes Projekt mal im Source zur Verfügung, damit ihr meine Probleme erkennen könnt.

Verlange ich da jetzt zu viel von euch ?

Danke für eure Unterstützung.

Gruß
Lutz

Beitrag von **Martin Altmann** » Sa, 10. Mär 2007 13:06

Hallo Lutz,
dass ein schließendes Fenster Deine Anwendung beendet, liegt an Deinem Eventhandling!
Du hast sicherlich in Deiner Hauptschleife so ein Konstrukt stehen:

Code: Alles auswählen

nEvent := xbe_None
DO WHILE nEvent <> xbeP_Close
  nEvent := AppEvent( @mp1, @mp2, @oXbp )
  oXbp:handleEvent( nEvent, mp1, mp2 )
ENDDO

Ändere das in das folgende:

Code: Alles auswählen

lExit := .f.
DO WHILE ! lExit
  nEvent := AppEvent( @mp1, @mp2, @oXbp )
  oXbp:handleEvent( nEvent, mp1, mp2 )
ENDDO

Dann musst Du im Prinzip nur noch lExit auf .t. setzen, wenn Dein Hauptfenster beendet werden soll (also der User den entsprechenden Menüeintrag aufruft oder das Fenster über das Systemmenü schließt).

Viele Grüße,
Martin

Lutz Rübe · Beitrag von **Lutz Rübe** » Sa, 10. Mär 2007 13:56

Hallo Martin,

damit ist mein erstes Problemchen in Verbindung mit AppEdit, AppBrowse und AppDisplay gelöst. Warum es mit dem Window nicht funktioniert, welches ich mit dem FormDesigner entwickelt habe, weiß ich noch nicht und werde das noch prüfen und ausprobieren. Muß ich evtl. den EventHandler aus dem Programm-Modul entfernen ?

Wie kann ich die Datenbanken, die ich innerhalb der Programm-Module (AppEdit, Form-Designer) geöffnet habe, bei Verlassen wieder schließen ?

Danke erst mal...

Gestern stand ich noch einen Schritt vor dem Abgrund, jetz bin ich schon einen Riesenschritt weiter....

Gruß
Lutz

Beitrag von **Martin Altmann** » Sa, 10. Mär 2007 14:30

Hallo Lutz,

Lutz Rübe hat geschrieben:Warum es mit dem Window nicht funktioniert, welches ich mit dem FormDesigner entwickelt habe, weiß ich noch nicht und werde das noch prüfen und ausprobieren. Muß ich evtl. den EventHandler aus dem Programm-Modul entfernen ?

das würde ich mal versuchen.

Lutz Rübe hat geschrieben:Wie kann ich die Datenbanken, die ich innerhalb der Programm-Module (AppEdit, Form-Designer) geöffnet habe, bei Verlassen wieder schließen ?

Das machst Du in einer Methode, die Du bei Deiner entsprechenden Fensterklasse aufrufst, wenn das Fenster geschlossen werden soll. Beispiel:

Code: Alles auswählen

....
::xbpDialog:close := { || ::schliessen() }
....
method _aladressenmas:schliessen()
xadresse->( DbGoBottom() )
if empty( xadresse->code )
  xadresse->( dbDelete() )
  xadresse->( dbPack() )
elseif geloescht > 0
  xadresse->( dbPack() )
endif
xadresse->( DbCloseArea() )
::xbpDialog:EndDialog()
::xbpDialog:Destroy()
SetAppFocus(SetAppWindow())
return self

Lutz Rübe hat geschrieben:Gestern stand ich noch einen Schritt vor dem Abgrund, jetz bin ich schon einen Riesenschritt weiter....

Na das will ich doch nicht hoffen

Viele Grüße,
Martin

Beitrag von **brandelh** » Sa, 10. Mär 2007 18:29

Hi,

bei allen mit XppFD erstellten Beispielanwendungen wird eine MAIN geliefert, die beendet wird, wenn das Fenster beendet wird. Im Normalfall (MDI-Anwendung) will man das natürlich nicht. Außerdem haben diese nie eine eigene Close() Methode, im Beispiel gehts so, aber als MDI Fenster mach ich das so (immer Class-Code) :

Code: Alles auswählen

  [color=red]in der Class definition [/color]
  ...
  METHOD CLOSE
  ...
  [color=red]nach der Class definition [/color]
  METHOD _NewForm:close()
      [color=red]
      // hier alle Dateien schließen, die in Create geöffnet wurden !
      // Jedes Fenster verwaltet seine eigenen DBF Arbeitsbereiche ![/color]
      ::destroy()
  return nil
  ...
  [color=red]in der INIT Methode ändern wir den PostAppEvent ab ... [/color]
   ::ButtonOK:activate := {|| Gather( ::editControls ), [color=red]::close()[/color] }
   ...
[color=red]   in der Main, wenn jedes Fenster seinen() Close bedient reicht das...[/color]
   WHILE .t.
      nEvent := AppEvent ( @mp1, @mp2, @oXbp )
      oXbp:HandleEvent ( nEvent, mp1, mp2 )
   ENDDO
[color=red]   // die Endlosschleife kann man über das Flag von Martin beenden, ich habe dazu eine eigene Funktion:[/color]
   *--------------------------------------------------------------------------------
PROCEDURE AppQuit(lForce)
   LOCAL nButton
   DEFAULT lForce to .f.
   if ! lForce
      nButton := ConfirmBox( , ;
                 "M”chten Sie das Programm beenden ?", ;
                 "Beenden", ;
                  XBPMB_YESNO , ;
                  XBPMB_QUESTION+XBPMB_APPMODAL+XBPMB_MOVEABLE )
   else
      nButton := XBPMB_RET_YES
   endif

   IF nButton == XBPMB_RET_YES
      COMMIT
      CLOSE ALL
      QUIT
   ENDIF

RETURN
[color=red]   // Diese Funktion muss natürlich noch in den Close-Slot des Hauptfenster:
[/color]
   oDlg:close := {|| AppQuit() }

Lutz Rübe · Beitrag von **Lutz Rübe** » Sa, 10. Mär 2007 20:30

Sorry, aber ich muß passen.

Solange ich die Funktionalität und den Einsatz von Methoden und Classen noch nicht begriffen habe, komme ich mit all euren gutgemeinten Lösungsansätze und Hilfen überhaupt nicht weiter...

Hier fehlen mir die grundsätzlichen Kenntnisse.

Danke für eure Bemühungen, aber ich suche zur Zeit noch die ganz einfachen Lösungen.

Wünsche allen ein schönes Wochenende.

Gruß
Lutz

Rudolf · Beitrag von **Rudolf** » Sa, 10. Mär 2007 21:02

Hallo Lutz,
wenn Du z.B. eXPress++ verwendest, hast Du es wesentlich einfacher. Lade Dir das Demo runter und schau mal die Beispiele an. Dinge wofür Du sonst eine Vielzahl an Programmzeilen benötigst, gehen dort mit nur einer Befehlszeile. Und du musst Dich nicht mit den Klassen beschäftigen, alles geht auch rein prozedural. Kann Dir gerne Beispiele schicken.
Grüsse
Rudolf

Lutz Rübe · Beitrag von **Lutz Rübe** » Sa, 10. Mär 2007 22:18

Hallo Rudolf,

danke für den Tip, aber irgendwie habe ich meine Probleme mit xBase++: die Demo von eXpress funktioniert nicht mit dem aktuellen Build von meinem xBase++.

Gruß
Lutz

Lutz Rübe · Beitrag von **Lutz Rübe** » Sa, 10. Mär 2007 23:28

Hallo Jimmy,

wie ich schon ein paar mal schrieb, bin ich Hobby-Programmierer und komme über dBase und Clipper zu xBase. Ich habe mir alles selber beigebracht (keine Schulungen und keine Lehrgänge, also reiner Autodidakt) und versuche mich nun seit Juni letzten Jahres mit xBase.

Unter Clipper habe ich nur ASCII Darstellungen programmiert, grafische Elemente waren dort nicht vertreten (genau so wenig wie Mausunterstützung).

OOP kenne ich nur ein bißchen aus der Theorie, praktische Erfahrung habe ich damit keine. Methoden und Klassen, die es - meines Wissens - auch bereits schon unter Clipper gab, habe ich bisher nie in "Eigenentwicklung" eingesetzt. Wenn, dann nur in der Anwendung bestehender, fertiger Parts

Gruß
Lutz

Lutz Rübe · Beitrag von **Lutz Rübe** » Sa, 10. Mär 2007 23:35

....

was ich noch vergessen habe zu sagen: Ich sehe diverse Methoden und Classen, damit verbundene Objekte, (Variablen). Aber wann und wo ich welchen Variablen-Namen mit welcher Klasse oder welchem Objekt verbinde, ist mir nicht klar.

Man definiert Klassen, man definiert Methoden, alles in Zusammenhang mit Objekten, aber was passiert in welcher Reihenfolge, mit welcher Variablen, was bedeutet der doppelte Doppelpunkt etc etc etc....

Das sind Sachen, die ich bisher nirgendwo richtig verständlich nachlesen konnte.

Vielleicht fehlt mir nur ein sehr gut dokumentiertes Beispiel..

Gruß
Lutz

Beitrag von **Martin Altmann** » So, 11. Mär 2007 0:45

Hallo Lutz,
ich wollte Dir gerade vorschlagen, Dich mal den ab und an in Deiner Nähe stattfindenden Treffen (Raum Baden/Pfalz) anzuschließen, da sich die meisten Deiner Fragen am effektivsten gemeinsam vor einem Bildschirm erklären lassen. Habe dann aber gesehen, dass Du bei dem ersten Treffen dabei warst - dies solltet ihr ruhig häufiger machen und dann auch mal die Zeit für solche Grundlagenschulungen nutzen - vielleicht hat auch einer aus dem Forum aus Deiner Gegend ein wenig Muße und Zeit und ihr könnt Euch mal privat einige Wochen mal für ein/zwei Nachmittage zusammensetzen.
Du bist ja leider ein wenig ab vom Schuß (von Berlin aus gesehen

), sonst könnten wir sowas hier mal machen.
Aber ich rate Dir, Dich ggf. bei der DevCon im November anzumelden. Dort wird diesmal der Schwerpunkt gerade für Um- und Einsteiger liegen, die neu in Xbase++ sind.
Ansonsten nur kurz noch der Hinweis: Der doppelte Doppelpunkt bedeutet einfach nur self - also die Methode hinter dem :: aus der aktuellen Klasse aufrufen.

Viele Grüße,
Martin

Beitrag von **AUGE_OHR** » So, 11. Mär 2007 0:52

hi,

Lutz Rübe hat geschrieben: Vielleicht fehlt mir nur ein sehr gut dokumentiertes Beispiel..

tja das findet man "kaum" ... es muss ja auch immer zu "level"
des User "passen" ob die Dokumentation dann "verständlich" ist.

Mir persöhnlich hat "TopDown" sehr geholfen, weil ja alles im Source.

Auch hat mir die "Grundidee" von "TopDown" , eine "Applicationframe",
am besten gefallen und mir den Einstieg zur Window$ "Fenster" geöffnet.

Mit den "TopDown" Functionen wird also erstmal ein Parent "Fenster"
erzeugt der auch mit "Menue" etc. ausgestattet werden kann. In dem
Parent "Fenster" ist nun dein CRT als TDpart (TD=Topdown) und kann
mit weiteren TDparts zur GUI "aufgepeppt" werden.

Wie man nun mit TD/Xbpart´s "umgeht" hat Claton auch sehr schön
in seinen "Artikeln" über "Fenster" und deren Parent/Owner Beziehungen
aufgezeigt.

Auch ist "TopDown" im Prinzip eine "Function" Library die man wie
unter Cl*pper "benutzt" ohne sich um die "Class" kümmern zu müssen.

Man kann aber im Source "nachsehen" welche "Methoden" verwendet
werden und wie die "Parameter" den "Class Variabeln" (export)
zugewiesen werden. Auch kann man anhand des Source deutlich
erkennen warum man von "Function" auf "OOP" code gehen "muss"

Code: Alles auswählen

   FUNCTION TooMuch(a,b,c,d,e,f,g,h,i,j,k,l,m ... z)

tja wenn man richtig viele Parameter hat muss man "sehr" sorgsam
die ","(komma) zählen ... bei OOP könntest du mit

Code: Alles auswählen

   TooMuch:j  := "Treffer"

"direkt" auf die "Class" Variabel (export) zugreifen.

Das hat nun Clayton mit der "TopDown" gemacht und die Xbase++
"Class"en in seiner Library in "Function gekapselt" (Wrapper) und die
aufeinander "abgestimmt" damit die "harmonieren".

Lutz Rübe hat geschrieben: zu (6): eine "MDI" Anwendung, so daß ich weitere Fenster öffnen
könnte wäre hilfreich, ist aber ein Randproblem

brauchst du wirklich "MDI" ? reicht nicht "SDI" aus d.h. "ein Fenster"
noch aufmachen statt "das eine Fenster" mehrfach ?

Wenn du also nun von "DOS" nach Window$ willst, musst du auch vom
"Function" Code zum OOP Code wechseln genau so wie vom "Procedur"
abhängigen Ereigniss zum Event gesteuertem Ereigniss. Deshalb geht
bei dir unter 3.) und 4.) auch das "Fenster zu", den der Event lautete

Code: Alles auswählen

   xbeP_Close

siehe auch Antwort von Martin.

Wenn du also vorher noch nicht in OOP programmiert hast und mit
den Xbpart´s so nicht zurecht kommst, solltest du dir die "Topdown"
leisten. Hierfür erhälst du einen "sehr gut" dokumentierten Source
der auf jeden Fall sein "Lehrgeld" wert ist.

gruss by OHR
Jimmy

Beitrag von **brandelh** » So, 11. Mär 2007 1:47

Hallo Lutz,

Wenn dir das mit OOP zu viel ist, dann kannst du entweder wie bisher ohne GUI arbeiten, das sind auch echte Xbase++ Programme und wenn es nur für dich ist ... ansonsten kannst du den funktioncode nutzen, aber vieles geht einfach besser mit dem Class-Code ... wenn man es mal verstanden hat.

Ich gebe zu, dass ich Jahre gebraucht habe um mit der Windowsprogrammierung (auch unter VO) zurecht zu kommen. Die Schulungen die ich hatte, waren zwar wirklich nett - 5 Tage München bei bestem Wetter

- aber viel haben Sie nicht wirklich geholfen. Von DOS her gibt es verschiedene Sachen, die man einfach ablegen und anders denken muss. Aber es führt kein Weg daran vorbei, einfache Beispiele ansehen, abändern und schauen was passiert. Wie Jimmy schon sagte, es ist einfacher nur einzelne freie Bildschirme zu bauen als MDI Anwendungen (echte MDI Fenster sind es eh nicht).

Was mir an Grundregeln so einfällt ...

1. DOS 'leitet' den User in einen Ablauf (ZWANG), das geht unter Windows nicht wirklich. Der User kann überall hinklicken und man weiß als Programmierer nie was er als nächstes tut.
2. Versucht man es dennoch, wird der Anwender das Programm voll Abscheu ablehenen.
3. Man kann, ja man MUSS sogar alle Optionen, die nicht erlaubt sein sollen DISABLEn, d.H. sie sind sichtbar aber auf den ersten Blick als nicht wählbar gekennzeichnet.
4. Validierungen nach dem Verlassen des SLE und vor dem Sprung ins nächste SLE sollte man so gut es geht vermeiden, erstens weiß man sowieso nie wo der User hinklickt, und zweitens landet man schnell in einer Endlosschleife.
5. Man muss Ereignisgesteuert (eventdriven) programmieren, d.H.
für alles was passieren soll, muss man entweder eine Methode schreiben oder einen Codeblock in einen eventslot setzen:

oPB:activate := {|| msgbox("Hallo")}

immer wenn man auf den Pushbutton oPB klickt, wird der Codeblock ausgeführt und es erscheint 'Hallo'.

... so jetzt aber ab ins Bett...

Rudolf · Beitrag von **Rudolf** » So, 11. Mär 2007 9:35

Hallo Lutz,
das eXPress++ Demo lässt sich für fast jede Version compilieren. Es gibt dazu die Batchfiles build18.bat, build182.bat, build19.bat und dbuild.bat fürs Demo.
Der Vorteil bei eXPress++ ist, dass Du anfangs kaum objektorientierte Programmierung benötigst. Ich habe damit einen sehr schnellen Umstieg von umfangreichen Clipper geschafft, und mir nebenbei die Kenntnisse für die objektorientierte Programmierung angeeignet. Dabei ist die Programmierung von Grafik Elementen genauso einfach wie der CRT Mode, da ist kaum ein Unterschied. Im GUI Mode sind manche Dinge sogar einfacher als unter Clipper. TopDown wird wahrscheinlich ähnlich sein, nur kenne ich es zu wenig. Ohne eXPress++ wäre ich nicht auf XBase++ umgestiegen, wär mir zu umständlich gewesen.
Welche XBase++ Version benötigst Du ?
Grüsse
Rudolf

Beitrag von **Wolfgang Ciriack** » So, 11. Mär 2007 9:44

Hallo Lutz,
was Rudolf sagt, kann ich nur bestätigen, ohne eXPress++ hätte auch ich die Benutzung von XBase++ schon aufgegeben.

Rudolf · Beitrag von **Rudolf** » So, 11. Mär 2007 10:09

Hallo,
ich würde sogar sagen, dass ich nicht in XBase++ sondern in eXPress++ programmiere

Grüsse
Rudolf

Lutz Rübe · Beitrag von **Lutz Rübe** » So, 11. Mär 2007 11:48

Danke an alle ....

... für eure Bemühungen mir mit Tipps und Tricks weiterzuhelfen.

Auch wenn ich keinen Hinweis gefunden habe, der "alle" meine genannten Probleme löst, hat mir die Diskussion hier sehr geholfen und mir einiges klargemacht:

- ich wollte wahrscheinlich alle Vorteile von xBase++ ( MDI, Netzwerk, GUI, CRT und und und ) gleich auf einmal implementieren.
- aus euren Aussagen kann ich entnehmen, dass auch ihr zumindest am Anfang sehr viele Probleme mit xBase hattet und vielleicht heute noch habt.
- ohne den Support hier im Forum gibt es bei xBase kein weiterkommen.

Nachdem ich mir all das über Nacht habe durch den Kopf gehen lassen, habe ich heute morgen rast- und ruhelos noch einmal die Samples durchgearbeitet und Teil-Lösungen gefunden, die in Verbindung mit euren Tipps mir gewaltig weitergeholfen haben.

Danke.

der Tag ist nun für mich gerettet.

Gruß
Lutz

Rolf Ramacher · Beitrag von **Rolf Ramacher** » So, 11. Mär 2007 15:43

Hallo Lutz,

also wenn du zu GUI-Masken ein paar Beispiele benötigst, kann ich dir meine gerne mal posten.

Beitrag von **brandelh** » So, 11. Mär 2007 16:15

Hi Lutz,

das mit dem Übergangsproblemen hin zu Windows ist nicht nur auf Xbase++ beschränkt. Ich habe auch einen Basic-Compiler mit besserer IDE und habe auch schon mit VB experimentiert.

Bei beiden sind die Oberflächen schneller gemalt, aber damit wars auch schon mit der Unterstützung. Was der User können muss, oder braucht, wie man es ergonomisch anordnet und wie die DB-Zugriffe mit vielen gleichzeitigen Fenstern am Rechner zurecht kommen, da helfen die Guis nicht wirklich. Unter DOS waren die Leute durchaus anspruchsloser bzw. es gab kein Excel oder MS-Word, das einem immer vorgehalten wird ... 'aber das kann xyz doch auch, wiese können Sie das nicht ...'.

Unter Clipper musste man ja auch erst lernen wie man ein schönes Klappmenü mit Pfeiltastensteuerung hinbekommen hat. Ohne die Tips und Tricks damals war man als Anfänger ja auch aufgeschmissen. Die Hilfe jedenfalls fand ich nicht sehr hilfreich. Vieles ist heute sogar leichter zu machen, die XbParts, z.B. regeln vieles was man sonst selbst machen musste. Aber diese Lernphase ist halt schon lange vergessen.

Also Kopf hoch und klein überschaubar angangen und wenn es funktioniert in die größere Einheit einbauen.