procedural zu OOP [Erledigt]
Moderator: Moderatoren
-
- Rekursionen-Architekt
- Beiträge: 440
- Registriert: Mo, 30. Mai 2011 15:06
- Danksagung erhalten: 1 Mal
procedural zu OOP [Erledigt]
Hi,
Der FormDesigner von Alaska gibt mir ja immer Class Code aus, wenn ich diesen erzeuge.
1. Gibt es Vorteile von Klassenprogrammierung (heißt das dann OOP= objektorientierte Programmierung) gegenüber der Proceduralen Programmierung?
2. Wie "übersetze" ich meinen eingefleischent Procedural Code in eine Methode einer Klasse oder so was in der Art ?
3. Wie ist dass OOP denn überhaupt aufgebaut Klasse -> Subklasse -> Methode .... und wie erzeuge ich eine Klasse von Hand.
---> Ich hab das procedurale so drin und versteh einfach die Klassenprogrammierung nicht.
Der FormDesigner von Alaska gibt mir ja immer Class Code aus, wenn ich diesen erzeuge.
1. Gibt es Vorteile von Klassenprogrammierung (heißt das dann OOP= objektorientierte Programmierung) gegenüber der Proceduralen Programmierung?
2. Wie "übersetze" ich meinen eingefleischent Procedural Code in eine Methode einer Klasse oder so was in der Art ?
3. Wie ist dass OOP denn überhaupt aufgebaut Klasse -> Subklasse -> Methode .... und wie erzeuge ich eine Klasse von Hand.
---> Ich hab das procedurale so drin und versteh einfach die Klassenprogrammierung nicht.
Zuletzt geändert von Benz am Fr, 05. Aug 2011 11:30, insgesamt 1-mal geändert.
- Jan
- Marvin
- Beiträge: 14653
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: procedural zu OOP
Jens,
mir geht das ähnlich - Klassen und ich, zwei Welten prallen aufeinander. Also warum läßt Du den FD immer Klassencode erzeugen? Nimm doch den prozeduralen.
Jan
mir geht das ähnlich - Klassen und ich, zwei Welten prallen aufeinander. Also warum läßt Du den FD immer Klassencode erzeugen? Nimm doch den prozeduralen.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Manfred
- Foren-Administrator
- Beiträge: 21192
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: procedural zu OOP
Hi benz,
hast Du im Handbuch schon mal "Grundlagen der objektorientierten Programmierung" gelesen?
hast Du im Handbuch schon mal "Grundlagen der objektorientierten Programmierung" gelesen?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
-
- Rekursionen-Architekt
- Beiträge: 440
- Registriert: Mo, 30. Mai 2011 15:06
- Danksagung erhalten: 1 Mal
Re: procedural zu OOP
@Jan:
Ich will eigentlich schon mit ClassCode programmieren, weil das eben auch in anderen Programmiersprache vorzugsweise behandelt und ich denke, dass wenn ichs einmal verstanden habe auch dort verstehe.
Oder seht ihr keinen Vorteil darin mit Class COde zu programmieren?
@Manfred: Nein leider nicht. Wenn das Handbuch in Buchform vorliegt, dann ist es wohl leider unauffindbar
Ich will eigentlich schon mit ClassCode programmieren, weil das eben auch in anderen Programmiersprache vorzugsweise behandelt und ich denke, dass wenn ichs einmal verstanden habe auch dort verstehe.
Oder seht ihr keinen Vorteil darin mit Class COde zu programmieren?
@Manfred: Nein leider nicht. Wenn das Handbuch in Buchform vorliegt, dann ist es wohl leider unauffindbar
- Manfred
- Foren-Administrator
- Beiträge: 21192
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: procedural zu OOP
Hm,
wenn Xbase++ ordnungsgemäß installiert wurde, dann gibt es einen Ordner unter Start/Programme und da ist das Handbuch drin. Aber wenn Du das noch nie gesehen hast, dann wundern mich Deine Fragen hier nicht mehr.
wenn Xbase++ ordnungsgemäß installiert wurde, dann gibt es einen Ordner unter Start/Programme und da ist das Handbuch drin. Aber wenn Du das noch nie gesehen hast, dann wundern mich Deine Fragen hier nicht mehr.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- brandelh
- Foren-Moderator
- Beiträge: 15696
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: procedural zu OOP
Hi,
das "Handbuch" ist die Windowshilfe Datei und dort sollte man tatsächlich mit den ersten Kapiteln anfangen und komplett durchlesen !
CLASS CODE ist in der späteren Manipulation viel einfacher, da jedes Objekt (Control, Fenster, etc.) eine eigene Steuervariable hat,
im Function Code ist das immer ein oXbp für alle und wenn man etwas regeln will (disablen etc.) muss man das Control erst suchen ...
Der CLASS CODE ist beileibe kein objektorientiertes Programmieren wie bei OOP Sprachen, wir können und sollten Objekte nutzen,
aber im Prinzip wird beides nur gemischt. Auch bei Express++ COMANDO Programmierung erzeugt man nichts als Objekte, Windows lebt von Objekten.
das "Handbuch" ist die Windowshilfe Datei und dort sollte man tatsächlich mit den ersten Kapiteln anfangen und komplett durchlesen !
CLASS CODE ist in der späteren Manipulation viel einfacher, da jedes Objekt (Control, Fenster, etc.) eine eigene Steuervariable hat,
im Function Code ist das immer ein oXbp für alle und wenn man etwas regeln will (disablen etc.) muss man das Control erst suchen ...
Der CLASS CODE ist beileibe kein objektorientiertes Programmieren wie bei OOP Sprachen, wir können und sollten Objekte nutzen,
aber im Prinzip wird beides nur gemischt. Auch bei Express++ COMANDO Programmierung erzeugt man nichts als Objekte, Windows lebt von Objekten.
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14653
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: procedural zu OOP
Hubert,
es gibt aber auch die "getting started", die ich auch als gedrucktes Handbuch vorliegen habe (ich weiß nicht, ob es das heute noch gibt). Die ist schon ganz gut für Einsteiger und Clipper-Umsteiger.
Jan
es gibt aber auch die "getting started", die ich auch als gedrucktes Handbuch vorliegen habe (ich weiß nicht, ob es das heute noch gibt). Die ist schon ganz gut für Einsteiger und Clipper-Umsteiger.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9361
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: procedural zu OOP
Es bestehen gravierende paradigmatische Unterschiede zwischen prozeduralem Code und klassenbasierten Code, wobei letztlich beides gemischt wird, man also fallweise entscheidet, welche Variante die bessere ist. Auch Klassen werden etwa auf Funktionen zugreifen. Die Klassenerzeugung und -verwaltung geschieht in der Regel in prozeduralem Code.
Man muss verstehen, wie Klassen funktionieren, wenn man mit ihnen arbeiten will. Wenn dieses Verstehen eingesetzt hat, bieten sie enorme Vorteile. Kleines Beispiel: Ich habe ein ziemlich monströses (im Sinn von: umfangreich) Planungssystem, das Kern meiner Applikation ist. Für dieses Planungssystem wurden diverse Daten in Speichervariablen gehalten, etwa, als simples Beispiel, der Planungsmonat, um den es jeweils ging. Diverse Funktionalitäten haben dann u.a. hierauf zugegriffen. Als sich die Notwendigkeit ergab, mehrere Monate parallel bearbeiten zu können, geriet dies an seine Grenzen. Also habe ich eine Klasse programmiert, die als Instanzvariable u.a. solche Daten mitschleppt. Referenz sind nicht mehr irgendwelche Speichervariablen, sondern das aktuelle Planungsobjekt, das als iVar u.a. das Monatsdatum mit sich führt. Jede Funktion und Methode, die dann irgendwas macht, greift auf die Instanzvariablen des jeweiligen Objekts zu, und nicht mehr auf statische Variablen. Dadurch können beliebig viele Instanzen der Planungsklasse parallel laufen, ohne sich zu beharken. Alle Operationen beziehen sich nur noch auf das jeweilige Klassenobjekt, das per se davor geschützt ist, anderen Parallelobjekten in die Quere zu kommen.
Klassen haben (u.a.) den großen Vorteil, dass über die Vererbung Ergänzungen nur noch an der Klasse selbst nötig sind. Etwas, das der Klasse hinzugefügt wird, können plötzlich auch alle Instanzen der Klasse. Alle meine Browses können Daten mehrzeilig anzeigen, Icons einbinden, bieten Zellenmarkierungen per Strg+LbClick und Shift+LbClick usw. usf. - aber ich nutze diese Systematiken nicht in allen Browses. Aber ich könnte. Wenn ich jetzt z.B. die Gestaltung der Zellenmarkierung ändern will (oder muss), mache ich das nur noch in der Klasse selbst, feddisch.
Aber das ist kein Thema, das man einfach so in einem Thread abhandeln kann. Wie gesagt, man muss OOP wirklich verstehen, damit man erkennt, welchen Benefit es bietet. Der ist dann allerdings enorm groß.
Man muss verstehen, wie Klassen funktionieren, wenn man mit ihnen arbeiten will. Wenn dieses Verstehen eingesetzt hat, bieten sie enorme Vorteile. Kleines Beispiel: Ich habe ein ziemlich monströses (im Sinn von: umfangreich) Planungssystem, das Kern meiner Applikation ist. Für dieses Planungssystem wurden diverse Daten in Speichervariablen gehalten, etwa, als simples Beispiel, der Planungsmonat, um den es jeweils ging. Diverse Funktionalitäten haben dann u.a. hierauf zugegriffen. Als sich die Notwendigkeit ergab, mehrere Monate parallel bearbeiten zu können, geriet dies an seine Grenzen. Also habe ich eine Klasse programmiert, die als Instanzvariable u.a. solche Daten mitschleppt. Referenz sind nicht mehr irgendwelche Speichervariablen, sondern das aktuelle Planungsobjekt, das als iVar u.a. das Monatsdatum mit sich führt. Jede Funktion und Methode, die dann irgendwas macht, greift auf die Instanzvariablen des jeweiligen Objekts zu, und nicht mehr auf statische Variablen. Dadurch können beliebig viele Instanzen der Planungsklasse parallel laufen, ohne sich zu beharken. Alle Operationen beziehen sich nur noch auf das jeweilige Klassenobjekt, das per se davor geschützt ist, anderen Parallelobjekten in die Quere zu kommen.
Klassen haben (u.a.) den großen Vorteil, dass über die Vererbung Ergänzungen nur noch an der Klasse selbst nötig sind. Etwas, das der Klasse hinzugefügt wird, können plötzlich auch alle Instanzen der Klasse. Alle meine Browses können Daten mehrzeilig anzeigen, Icons einbinden, bieten Zellenmarkierungen per Strg+LbClick und Shift+LbClick usw. usf. - aber ich nutze diese Systematiken nicht in allen Browses. Aber ich könnte. Wenn ich jetzt z.B. die Gestaltung der Zellenmarkierung ändern will (oder muss), mache ich das nur noch in der Klasse selbst, feddisch.
Aber das ist kein Thema, das man einfach so in einem Thread abhandeln kann. Wie gesagt, man muss OOP wirklich verstehen, damit man erkennt, welchen Benefit es bietet. Der ist dann allerdings enorm groß.
Herzlich,
Tom
Tom
-
- Rekursionen-Architekt
- Beiträge: 440
- Registriert: Mo, 30. Mai 2011 15:06
- Danksagung erhalten: 1 Mal
Re: procedural zu OOP
Hehe nein ich hab das Handbuch ich dachte nur es wär ein spezielles als Buchdruck, das von Alaska mitgeliefert wurde oder so. Ich habs auch schon benutzt nur bin ich wohl nicht darauf eingegangen, was in den Kapiteln steht. Aber das muss ich jetzt wohl nachholen Danke für die Vorschläge und Antworten.Manfred hat geschrieben:Hm,
wenn Xbase++ ordnungsgemäß installiert wurde, dann gibt es einen Ordner unter Start/Programme und da ist das Handbuch drin. Aber wenn Du das noch nie gesehen hast, dann wundern mich Deine Fragen hier nicht mehr.
In dem Sinn ist das Thema jetzt ja eigentlich erledigt... : Ich muss das Handbuch lesen.
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: procedural zu OOP [Erledigt]
hi,
interessant zum lesen sind auch die Artikel von Clayton ( TopDown ) http://cjcom.net/xbarticles.htm
interessant zum lesen sind auch die Artikel von Clayton ( TopDown ) http://cjcom.net/xbarticles.htm
gruss by OHR
Jimmy
Jimmy
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: procedural zu OOP [Erledigt]
Servus Tom,Alle meine Browses können Daten mehrzeilig anzeigen, Icons einbinden, bieten Zellenmarkierungen per Strg+LbClick und Shift+LbClick usw. usf.
gibts hierfür Beispiel-Code? Oder schon eine Lösung? Müsste bei einem normalem xbpBrowse in einer Zeile zusätzlich ein Memofeld anzeigen, das aus beliebig vielen "Zeilen" bestehen kann.
Danke!
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9361
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: procedural zu OOP [Erledigt]
Hallo, Werner.
Ich habe zum Forentreffen im Frühsommer ein Beispiel gebaut, mit dem man u.a. mehrzeilige Texte in Browses anzeigen kann. Wenn Du mir Deine Mailadresse zukommen lässt, schicke ich sie Dir. Aber: Es sind keine unterschiedlichen Zeilenhöhen in Browses möglich, und das bedeutet, dass man zwar z.B. drei Textzeilen in einer Zelle anzeigen kann, dann aber alle Zellen in allen Zeilen so hoch sein müssen, dass das in (mindestens) einer geht. Anders gesagt: Man kann ein Browse nicht dazu bringen, in einer Zeile Texte einzeilig und in der nächsten (mit dynamischer Zeilenhöhe) z.B. dreizeilig anzuzeigen. Das wiederum geht aber per Ownerdrawing mit der XbpListbox. Die verfügt über die Methode MeasureItem, mit der man je Zeile die Höhe festlegen kann. Auf diese Weise kann man - Markus Walter hat das gemacht, schreib ihn mal per PN an - zum Beispiel Rechnungspositionen als "Tabelle" anzeigen, die unterschiedlich viel Text enthalten. Das funktioniert im Prinzip wie das Ownerdrawing im Browse, mit dem Unterschied, dass beim Erzeugen der Listbox-Inhalte (also bei AddItem) die Methode MeasureItem aufgerufen wird. Wenn man die überlagert bzw. einen Wert für die Zellenhöhe zurückgeben lässt, die sich an der Textlänge orientiert, kann man dynamische Zeilenhöhen erzeugen. Da gibt es aber noch einen Bug:
http://www.alaska-software.com/scripts/ ... PDRID=6374
Ich habe zum Forentreffen im Frühsommer ein Beispiel gebaut, mit dem man u.a. mehrzeilige Texte in Browses anzeigen kann. Wenn Du mir Deine Mailadresse zukommen lässt, schicke ich sie Dir. Aber: Es sind keine unterschiedlichen Zeilenhöhen in Browses möglich, und das bedeutet, dass man zwar z.B. drei Textzeilen in einer Zelle anzeigen kann, dann aber alle Zellen in allen Zeilen so hoch sein müssen, dass das in (mindestens) einer geht. Anders gesagt: Man kann ein Browse nicht dazu bringen, in einer Zeile Texte einzeilig und in der nächsten (mit dynamischer Zeilenhöhe) z.B. dreizeilig anzuzeigen. Das wiederum geht aber per Ownerdrawing mit der XbpListbox. Die verfügt über die Methode MeasureItem, mit der man je Zeile die Höhe festlegen kann. Auf diese Weise kann man - Markus Walter hat das gemacht, schreib ihn mal per PN an - zum Beispiel Rechnungspositionen als "Tabelle" anzeigen, die unterschiedlich viel Text enthalten. Das funktioniert im Prinzip wie das Ownerdrawing im Browse, mit dem Unterschied, dass beim Erzeugen der Listbox-Inhalte (also bei AddItem) die Methode MeasureItem aufgerufen wird. Wenn man die überlagert bzw. einen Wert für die Zellenhöhe zurückgeben lässt, die sich an der Textlänge orientiert, kann man dynamische Zeilenhöhen erzeugen. Da gibt es aber noch einen Bug:
http://www.alaska-software.com/scripts/ ... PDRID=6374
Herzlich,
Tom
Tom
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: procedural zu OOP [Erledigt]
Servus Tom,
danke, genau um die Anzeige von Rechnungspositionen gehts u. a.
Dann hilft mir Deine Lösung nichts, da es von Zeile zu Zeile unterschiedlich ist, je nachdem, wieviel Text pro Datensatz ins Memofeld eingegeben wurde.
Da gehts wohl dann nicht mehr mit einem einfachen Browse und scope.
An alle: Wie macht ihr das? Ist ja eine Standard-Aufgabe...
Danke!
danke, genau um die Anzeige von Rechnungspositionen gehts u. a.
Dann hilft mir Deine Lösung nichts, da es von Zeile zu Zeile unterschiedlich ist, je nachdem, wieviel Text pro Datensatz ins Memofeld eingegeben wurde.
Da gehts wohl dann nicht mehr mit einem einfachen Browse und scope.
An alle: Wie macht ihr das? Ist ja eine Standard-Aufgabe...
Danke!
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9361
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: procedural zu OOP [Erledigt]
Hallo, Werner.
Wie ich schrieb - mit der XbpListBox ist das möglich. Sie verfügt für das Ownerdrawing über eine (zu überlagernde) Methode "MeasureItem", die es erlaubt, je Zeile dynamische Höhen zu wählen. Markus Walter (der auch im Forum so heißt) hat das gemacht; es ist auch keine Zauberei und im Prinzip (wenn man das Ownerdrawing verstanden hat) relativ einfach. MeasureItem bekommt eine Referenz auf das Listbox-Item, das anzuzeigen ist (erster Parameter) und manipuliert dann die Dimensionen (zweiter Parameter), wobei ohnehin nur die Höhe verändert werden kann. Allerdings "zerbröselt" das, sobald man der Listbox neue Items hinzufügt; in diesem Fall muss man die Listbox komplett neu bestücken und rekonfigurieren (siehe Link auf den PDR). Damit ist also das möglich, was Du machen willst - eingeschränkt durch die Fähigkeiten einer XbpListbox.
(ins Blaue getippter "Pseudocode")
Wie ich schrieb - mit der XbpListBox ist das möglich. Sie verfügt für das Ownerdrawing über eine (zu überlagernde) Methode "MeasureItem", die es erlaubt, je Zeile dynamische Höhen zu wählen. Markus Walter (der auch im Forum so heißt) hat das gemacht; es ist auch keine Zauberei und im Prinzip (wenn man das Ownerdrawing verstanden hat) relativ einfach. MeasureItem bekommt eine Referenz auf das Listbox-Item, das anzuzeigen ist (erster Parameter) und manipuliert dann die Dimensionen (zweiter Parameter), wobei ohnehin nur die Höhe verändert werden kann. Allerdings "zerbröselt" das, sobald man der Listbox neue Items hinzufügt; in diesem Fall muss man die Listbox komplett neu bestücken und rekonfigurieren (siehe Link auf den PDR). Damit ist also das möglich, was Du machen willst - eingeschränkt durch die Fähigkeiten einer XbpListbox.
(ins Blaue getippter "Pseudocode")
Code: Alles auswählen
CLASS MyListBox FROM XbpListBox
METHOD DrawItem
METHOD MeasureItem
INLINE METHOD Init(oParent,oOwner,aPos,aSize,aPres,lVisible)
::DrawMode := XBP_DRAW_OWNERADVANCED
* weitere Initialisierungssachen
RETURN self
ENDCLASS
METHOD MyListBox:MeasureItem(nItem,aDims)
* aDims[2] abhängig von der Anzahl Zeilen manipulieren
::XbpListBox:MeasureItem(nItem,aDims)
RETURN self
METHOD MyListBox:DrawItem(oPs,aInfo)
* und jetzt den Text mit GraCaptionStr zeichnen
RETURN self
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15696
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: procedural zu OOP [Erledigt]
Berechnungsergebnisse zeige ich häufig in einem MLE an.
Gruß
Hubert
Hubert
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: procedural zu OOP [Erledigt]
Es geht um die Darstellung von Datensätzen und dann Bearbeitungsmöglichkeit über Button oder Doppelklick.brandelh hat geschrieben:Berechnungsergebnisse zeige ich häufig in einem MLE an.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9361
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: procedural zu OOP [Erledigt]
Hallo, Werner.
Nochmal. In Browses kann man durchaus mehrzeilige Texte anzeigen, aber das Layout des Browses muss das dann für alle Zeilen reflektieren. Deshalb zeige ich in solchen Fällen zwei bis fünf Zeilen an (je nach Gestaltung), etwa bei der Auswahl von Textbausteinen oder in ähnlichen Systematiken. Will man dann den Text jeweils komplett sehen, klickt man auf einen Button oder wählt über ein Kontextmenü irgendeine Anzeige- oder Bearbeitungsfunktion. Oder es wird als eine Art Tooltip gezeigt. Wenn man aber dynamisch längere Texte in einer Art Tabelle anzeigen will, ist die Listbox das Mittel der Wahl. Die kann man tatsächlich dazu bringen, so ähnlich wie ein Browse auszusehen.
Ergänzung: Da bei mir fast alles, was mit Fließtexten zu tun hat, über RTF läuft (TX Text Control), zeige ich bei solchen Browses meistens unterhalb des Browses zusätzlich ein reduziertes Textcontrol an, das zur jeweils aktiven Browsezeile den kompletten Text in formatierter Version enthält. Das Browse selbst zeigt nur den Textinhalt (unformatiert).
Nochmal. In Browses kann man durchaus mehrzeilige Texte anzeigen, aber das Layout des Browses muss das dann für alle Zeilen reflektieren. Deshalb zeige ich in solchen Fällen zwei bis fünf Zeilen an (je nach Gestaltung), etwa bei der Auswahl von Textbausteinen oder in ähnlichen Systematiken. Will man dann den Text jeweils komplett sehen, klickt man auf einen Button oder wählt über ein Kontextmenü irgendeine Anzeige- oder Bearbeitungsfunktion. Oder es wird als eine Art Tooltip gezeigt. Wenn man aber dynamisch längere Texte in einer Art Tabelle anzeigen will, ist die Listbox das Mittel der Wahl. Die kann man tatsächlich dazu bringen, so ähnlich wie ein Browse auszusehen.
Ergänzung: Da bei mir fast alles, was mit Fließtexten zu tun hat, über RTF läuft (TX Text Control), zeige ich bei solchen Browses meistens unterhalb des Browses zusätzlich ein reduziertes Textcontrol an, das zur jeweils aktiven Browsezeile den kompletten Text in formatierter Version enthält. Das Browse selbst zeigt nur den Textinhalt (unformatiert).
Herzlich,
Tom
Tom
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
Re: procedural zu OOP [Erledigt]
Hallo Werner,
wie Tom schon richtig anmerkte, wäre ein XbpListview mit Ownerdrawing das Mittel der Wahl. Das Ding arbeitet aber etwas anders als ein Browse (Stichwort Datenbindung). Man muss auch - wie Tom ebenfalls scon anmerkte - einen Fehler in Xbase umschiffen.
Aber machbar ist damit ein "Browse" wie im Anhang dargestellt...
wie Tom schon richtig anmerkte, wäre ein XbpListview mit Ownerdrawing das Mittel der Wahl. Das Ding arbeitet aber etwas anders als ein Browse (Stichwort Datenbindung). Man muss auch - wie Tom ebenfalls scon anmerkte - einen Fehler in Xbase umschiffen.
Aber machbar ist damit ein "Browse" wie im Anhang dargestellt...
- Dateianhänge
-
- XbpListview.png (18.05 KiB) 10189 mal betrachtet
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: procedural zu OOP [Erledigt]
Will haben!!!
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Jan
- Marvin
- Beiträge: 14653
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: procedural zu OOP [Erledigt]
Schickes Teil!
Jan
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2935
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: procedural zu OOP [Erledigt]
Mach doch mal ein MW_LISTBOX daraus, würde ich auch sofort einsetzen =D>
Viele Grüße
Wolfgang
Wolfgang
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: procedural zu OOP [Erledigt]
meinst du damitWolfgang Ciriack hat geschrieben:Mach doch mal ein MW_LISTBOX daraus, würde ich auch sofort einsetzen
Code: Alles auswählen
o:multiColumn := .T.
grösstes "Problem" bei einer ListBox : es ist nicht OLE DragDrop fähig.
beiAllerdings "zerbröselt" das, sobald man der Listbox neue Items hinzufügt
Code: Alles auswählen
o:drawMode := XBP_DRAW_OWNER
wenn man also etwas "einfügen" oder "löschen" will muss man "jedes-mal" o:measureItem durchführen.
dies kann man per
Code: Alles auswählen
o:drawMode := XBP_DRAW_OWNERADVANCED
p.s. versucht doch mal in einer "laufenden" Listbox den Font zu wechseln.
das bezieht sich auf XbpListBox() weil es "nur" o:additem() kennt und man nicht eine Array Structure per Pointer übergeben kann was bei ListView möglich ist.Stichwort Datenbindung
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: procedural zu OOP [Erledigt]
...Tom hat geschrieben:Es sind keine unterschiedlichen Zeilenhöhen in Browses möglich, und das bedeutet, dass man zwar z.B. drei Textzeilen in einer Zelle anzeigen kann, dann aber alle Zellen in allen Zeilen so hoch sein müssen, dass das in (mindestens) einer geht. Anders gesagt: Man kann ein Browse nicht dazu bringen, in einer Zeile Texte einzeilig und in der nächsten (mit dynamischer Zeilenhöhe) z.B. dreizeilig anzuzeigen.
der Vergleich "hinkt" weil man nur 1 Columne hat ( auch bei o:multiColumn := .T. )Tom hat geschrieben:Das wiederum geht aber per Ownerdrawing mit der XbpListbox.
das selbe kann man auch mit einer XbpColumn() und o:customDrawCell machen.
gruss by OHR
Jimmy
Jimmy