SLE einfärben: High Noon...

Eigentlich ist mir die Frage peinlich, aber es kann sonst niemand helfen ... :)

Moderator: Moderatoren

Antworten
GrillenHirni
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 116
Registriert: Do, 18. Jul 2013 11:56
Kontaktdaten:

SLE einfärben: High Noon...

Beitrag von GrillenHirni »

So - jetzt reichts dann...!

Ich versuche zur Zeit einen BildschirmGenerator zu basteln, wo ich die Positionen
von DateiFeldern durch rum schieben von entsprechenden PlatzHaltern in einem
Dialog bestimmen kann...

Dabei versuche ich mich an ein Modell von Jimmy anzulehnen - mit der Ausnahme,
dass ich auch die Move-Funktionen nicht mit DLL-Calls sondern in "purem" Xbase
umsetzen möchte, um eine meiner masochistischen Neigungen zu befriedigen...

Dem rum "moven" geht ein AuswahlVerfahren voraus, bei dem ein zu positionierender
PlatzHalter ausgewählt werden soll...

Als erstes hab ich mal zwei Nächte mit den Versuchen verbracht, ein STATIC grün
einzufärben.

Erst hab ich das STATIC gewürgt - es hat mir die Zunge raus gestreckt, ich bin
auf ihm rum getrampelt, es hat sich einfach nicht verfärbt und nachdem ich
ihm ein Ohr abgerissen hatte, hat es mir in Standard geartetem greypale den
StinkeFinger gezeigt.

Ich war schon komplett zerrüttet, als ich hier im Forum den entscheidenden
Hinweis gefunden hab: die type-Eigenschaft sollte vorteilsweise auf
XBPSTATIC_TYPE_TEXT gesetzt sein. Dieser Tipp hat dann tatsächlich funktioniert!

Dann bemerkte ich, dass ich schon vorher hätte auf Jimmy hören sollen und
anstelle von STATICS lieber SLE's verwenden. Bei einem STATIC müsste ich
ja zusätzlich eines für den Rahmen darüber oder darunter legen, da man
anscheinend nicht ein normales STATIC mit Text UND einem Rahmen erzeugen
kann. Ok...

Seither versuche ich nun, das SLE einzufärben... Hier im Forum war das Problem
vielleicht vor zehn Jahren aktuell, aber das sind die zehn Jahre, welche ich zu
spät zur Welt gekommen bin... Interessanterweise hat es anscheinend bei allen
damaligen Diskussionsteilnehmern funktioniert... Nur bei mir funktioniert es
nicht... mimimimi...:

Erst Mal in allen Varianten mit :setColorBG(dieseKonstantefürGrün) -
das SLE macht keinen Wank! Die Eigenschaft :type steht hier nicht zur Verfügung.

Dann mit intensiven Gebeten und schliesslich mit :setPresParam(..):

ein passives SLE:

aPassivPresParameter:={ { XBP_PP_BGCLR , nColPassiv } ,;
{ XBP_PP_COMPOUNDNAME , FONT_HELV_MEDIUM } }

ein ausgewähltes SLE:

aAktivPresParameter:={ { XBP_PP_BGCLR , nColAktiv } ,;
{ XBP_PP_COMPOUNDNAME , FONT_HELV_MEDIUM } }

Das SLE bleibt stoisch. Das Ding ist einfach nicht klein zu kriegen.

Mein Yogalehrer meint, ich würde mich zuwenig auf das Problem konzentrieren.

Der LokalPolitiker, den ich immer wähle, meint es sei ein soziologisches Problem -
es funktioniere nur bei männlichen Probanden, zwischen sechsundzwanzig und
siebenundzwanzig Jahre alt, SternZeichen SteinBock und mit einem MonatsEinkommen
zwischen drei und viertausend Euro monatlich, wenn sie ein blaues Auto fahren... Meine
Meinung: das hätten sie im Handbuch erwähnen können...

Mein Psychiater meint, ich solle es anstatt mit grün mal mit blau versuchen und
eigentlich liege es eh an mir...

Jetzt habe ich Clint Eastwood angerufen, der hat sein Pferd gesattelt... In zwei
bis drei Monaten ist er hier, dann macht er das Teil platt...!
Grilli
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: SLE einfärben: High Noon...

Beitrag von HaPe »

Hallo Grilli !
Jetzt habe ich Clint Eastwood angerufen, der hat sein Pferd gesattelt... In zwei bis drei Monaten ist er hier, dann macht er das Teil platt...!
An deiner Stelle hätte ich ein gebrauchtes VFP9 gekauft, davon den Formulardesigner verwendet (der seine Daten in einer DBF speichert), diese dann ausgelesen und den passenden Xbase-Code daraus erstellt. :blob8:
Dann muß Dirty Harry nicht vorbeikommen ...
--
Hans-Peter
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: SLE einfärben: High Noon...

Beitrag von Jan »

Grilli,

jetzt muß ich mal etwas verwundert fragen - was ist denn bitte so schwierig daran, ein Static grün einzufärben? Dafür gibt es doch eine Methode, :setColorBG(nColor).

Wobei ich leider zugeben muß, das die neue Doku von Alaska eine heftige Katastrophe ist. Früher konnte man den Klassenbaum anzeigen lassen, da standen wirklich alle für diese Klasse erlaubten Methoden drin. Heute fehlt das fast komplett. Ich hab Alaska drauf angesprochen. Antwort: Braucht man nicht, die Methoden stehen doch alle in der Doku drin. Was soll man da nur drauf antworten? Da fehlen mir die Worte. Da kann drin stehen was will - wenn ich den Bezug zu einer gerade genutzen Klasse nicht sehe, insbesondere wenn ich mit der Klasse noch nicht so vertraut bin, dann hilft mir alle Doku nichts, in der der Bezug nicht von der Klasse ausgeht.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SLE einfärben: High Noon...

Beitrag von AUGE_OHR »

GrillenHirni hat geschrieben:Dann mit intensiven Gebeten und schliesslich mit :setPresParam(..):

ein passives SLE:
aPassivPresParameter:={ { XBP_PP_BGCLR , nColPassiv } ,;
{ XBP_PP_COMPOUNDNAME , FONT_HELV_MEDIUM } }

ein ausgewähltes SLE:
aAktivPresParameter:={ { XBP_PP_BGCLR , nColAktiv } ,;
{ XBP_PP_COMPOUNDNAME , FONT_HELV_MEDIUM } }
du bist schon nahe dran (denke ich) ...

die Frage ist was du unter "passive" verstehst :?:

ich nehme mal an damit ist die Möglichkeit des "editieren ON/OFF" gemeint.
und da kommt der kleine Harken denn o:Editable steht unter "Konfiguration" :!:
wenn du das von .T. -> .F. oder umgekehrt ändern willst benötigst du ein o:Configure() (für jedes SLE)

nun könntest du, auf die Farbe bezogen, noch etwas anderes meinen : o:Disable()
man kann dann das XbPart nicht mehr anwählen. Dafür gibt es "extra" Farben

Code: Alles auswählen

#define XBP_PP_DISABLED_FGCLR          10
#define XBP_PP_DISABLED_BGCLR          12
wenn auch das nicht meint ist dann vielleicht nur der "aktive" Balken ?

Code: Alles auswählen

#define XBP_PP_HILITE_FGCLR            6
#define XBP_PP_HILITE_BGCLR            8
die Konstanten findest du übrigens unter \INCLUDE\xbp.ch
gruss by OHR
Jimmy
GrillenHirni
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 116
Registriert: Do, 18. Jul 2013 11:56
Kontaktdaten:

Re: SLE einfärben: High Noon...

Beitrag von GrillenHirni »

Guten Morgen Ihr Lieben...

Guten Morgen HaPe -

genau sowas wie dieser VFP9 möchte ich für mich schreiben - die Positionen
möchte ich dann in eine Dbf schreiben und daraus den passenden XBase-Code
erstellen.

Im Moment versuche ich erst mal das Handling in der Maske mit der Tastatur.
Zur Ansicht lade ich hier nochmal meine VIO-Version hoch - die wurde aus-
schliesslich mit der Tastatur bedient - die Auswahl der PlatzHalter erfolgte
mit [CTRL-CRSUP], [CTRL-CRSDOWN], [CTRL-CRSLEFT] und [CTRL-CRSRIGHT].

Diesen VFP9 würde ich unter Umständen gerne mal ansehen - hast Du da eine
BezugsQuelle - welche Firma den verkauft..?


Guten Morgen Jan -

Versuch es mal, mit dem STATIC einfärben...? Wenn ich nicht eine entsprechend
korrekte :type-Eigenschaft zugewiesen hab, tut das STATIC nichts... Es würde
mich aber nicht wundern, wenn es bei Dir reibungslos funktionieren würde - in
meinem Fall könnte es sich um eine intergallaktische Verschwörung handeln...!

Arbeiten tu ich im Moment noch mit 1.9355 - ich glaube, ich hab diesen Klassenbaum
noch - ich benutz ihn nur viel zu wenig - darum ist Dein auch Tipp wertvoll - ich geh
den nachher mal suchen und versuche mir anzugewöhnen, den mehr zu nutzen.

Auf 2.0 steige ich um, wenn ich mal alle Controls die ich brauche, rudimentär
vorliegen hab - das ist dann das dritte Mal, dass ich von Xbase++ eine Lizenz
erwerbe...


Guten Morgen Jimmy...!

Mit passive SLE's meinte ich die, welche NICHT zum verschieben ausgewählt
sind. Mit aktive SLE's meinte ich die, welche zum verschieben ausgewählt sind.
Damit der Benutzer sie als ausgewählt erkennt, wollte ich sie grün einfärben.

Heute war wieder eine unruhige Nacht - da hatte ich die Idee, es mal mit
:setEditable(.T.) zu versuchen. Und siehe da: das SLE erstrahlt in einem
hübschen Lindgrün! Da ist der Frühling auch bei mir eingezogen und jetzt
stelle ich auch die Uhr um...

Du hattest recht - es hat wahrscheinlich tatsächlich mit :editable zu
tun... Auf die Idee zu kommen, dass man die Farbe vom SLE nur
verändern kann, wenn (o:editable=.T.) - das hat bei mir natürlich
gedauert...

Leider:

auf :setEditable(.T.) wird das SLE erst mal weiss
auf :setColorBG(dieseKonstantefürGrün) wird das SLE wunderbar grün
auf :setEditable(.F.) wird das SLE wieder standardmässig greypale

Mit o:disable muss ich noch experimentieren - meine erste Befürchtung
ist, dass wenn (o:disable=.T.), dass ich dann auch die Position von dem
Teil nicht mehr verändern kann...

Jetzt überleg ich im ersten Schock, ob ich es doch mit STATICS versuchen
sollte...? Wie geht das...?

Könnte ich ein STATIC für den Rahmen als Parent für das STATIC mit
der Beschriftung nehmen?

Ausserdem - auch nur kurz geschlossen:

Die Maske wird aufgebaut.

Mit [CTRL-CRSUP] müsste ich beispielsweise über einen KeyHandler
den untersten PlatzHalter anwählen können (den ersten PlatzHalter
in der letzten Zeile, welche PlatzHalter enthält).

Beim ersten Mal: wunderbar...

Beim zweiten Mal [CTRL-CRSUP] passiert anscheinend nichts mehr, das
Programm kommt im KeyHandler nicht mehr an...

Herzliche Grüsse und ein schönes WochenEnde...!
Grilli
Dateianhänge
FldMove.zip
(425 KiB) 398-mal heruntergeladen
Benutzeravatar
Muecke
1000 working lines a day
1000 working lines a day
Beiträge: 623
Registriert: Di, 24. Okt 2006 7:19
Wohnort: Samstagern CH
Hat sich bedankt: 3 Mal
Danksagung erhalten: 9 Mal
Kontaktdaten:

Re: SLE einfärben: High Noon...

Beitrag von Muecke »

Hallo Grilli

Ich denke für solche Sachen wäre nicht schlecht
das Forentreffen in Willingen zu besuchen,
oder Frankfurt da wären die Leute von Xbase++ auch da.
Am 1.April fand in Stuttgart ja auch ein Treffen mit Xbase++ Anwender.

Da hätte sicherlich jemand für dich einen Ansatz für dein Problemo.

Gruss
Thomas
GrillenHirni
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 116
Registriert: Do, 18. Jul 2013 11:56
Kontaktdaten:

Re: SLE einfärben: High Noon...

Beitrag von GrillenHirni »

Hallo Thomas...

Ja - hast Du vollkommen recht - die ForenTreffen sind bestimmt
eine super Gelegenheit für den Austausch von Xbase-Problemen und
-Lösungen...

Leider bin ich anfangs Mai wegen anderweitigen Verpflichtungen
verhindert. Ausserdem würd ich mir wahrscheinlich als Anfänger unter
lauter Cracks ziemlich blöd vorkommen - der Austausch von Lösungen
sollte ja keine Einbahnstrasse sein... Ausserdem - wie sieht das aus,
wenn ich mich irgendwo bewerbe, und in meiner Vita steht, ich war
in Frankfurt an einem Kongress um zu lernen, wie man ein kleines
Vierecklein grün einfärbt...?

Inzwischen bin ich mit dem Problem erstaunlich gut voran gekommen -
vielleicht handelt es sich aber dabei auch nur um eine optische Täuschung...

Nachdem ich das oSLE:editable mit .T. bewerte nimmt es tatsächlich
Farbe an. Im Moment ist alles noch Tastatur gesteuert - da brauchen
die PlatzHalter nicht mal Focus. Besonders gestaunt hab ich, wie
einfach sich die Funktionen für die Moves basteln liessen - die
Platzhalter schippern in der Maske rum, dass flutscht voll und ich hab
das halbe WochenEnde damit verbracht, spasseshalber PlatzHalter am
Bildschirm rum zu schieben.

Ein bisschen speziell war dabei noch, den PlatzHaltern zu sagen,
wo sie nicht mehr weiter verschoben werden dürfen, weil sie
sonst über den Rand der BildschirmMaske geschoben werden. Da
die PlatzHalter in der Regel verschiedene Längen haben, ist die
Grenze wo es nicht mehr weiter gehen darf - beispielsweise am rechten
Rand (rechter Rand - Länge PlatzHalter) - für jedes Teil an einem
anderen Punkt...

Und ein bisschen kompliziert wurde es dadurch, dass für ein Feld
zwei PlatzHalter (FeldBezeichnung und Wert) zur Verfügung stehen,
die sowohl einzeln als auch zusammen angewählt und verschoben
werden können...

Wenn ich dann eine Mausunterstützung einführen möchte - damit
hab ich noch gar keine Erfahrung - kommen dann die Probleme,
die ich umgangen hab wahrscheinlich doppelt auf mich zu und
dann komm ich hier wieder vorbei und jammere Euch voll...

Im Moment beschäftigt mich in dem Zusammenhang aber folgende
Frage:

Bisher hatte ich im VIO-Modus eine BildschirmMatrix von 25 Zeilen
auf 80 Zeichen. Ich denke, die Pixel-Positionen kann ich nicht
in absoluten Werten abspeichern, da sie sich verhältnismässig
auf die Ausmasse des Dialogs beziehen sollten, welcher als Parent
installiert ist...?

Im Moment habe ich die Idee, dass ich für Zeile und Spalte jeweils
einen PromilleWert der BildschirmMasse abspeichere und hoffe,
dass das Ganze durch die RückRechnungen in die Maske nicht zu
langsam wird...? Glaub ich aber nicht...

Herzliche Grüsse und einen schönen Abend...!
Grilli
Zuletzt geändert von GrillenHirni am Di, 04. Apr 2017 7:49, insgesamt 2-mal geändert.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SLE einfärben: High Noon...

Beitrag von AUGE_OHR »

GrillenHirni hat geschrieben:Ausserdem würd ich mir wahrscheinlich als Anfänger unter
lauter Cracks ziemlich blöd vorkommen
denke daran das wir alle mal bei 0 angefangen haben :roll:

ich bin 2002 in die USA geflogen in der Hoffnung das ich hinter das "Geheimnis" von Xbase++ (v1.3x) komme.
erst im März 2006 habe ich diese Forum entdeckt und seit dem ist mein Xbase++ Wissen gewaltig gewachsen.
Dazu haben auch massgeblich die Usertreffen / Devcons geholfen.

auch ich benötige einige Zeit nach einem Usertreffen um die Eindrücke zu verarbeiten.
manchmal liegt ein Code, den ich auf einem Treffen erhalten habe, schon seit Jahren auf meiner Festplatte und erst jetzt fange ich an zu verstehen was er bedeutet wenn ich mich selbst mit dem Problem beschäftige.
GrillenHirni hat geschrieben: Bisher hatte ich im VIO-Modus eine BildschirmMatrix von 25 Zeilen auf 80 Zeichen
... dass ich für Zeile und Spalte jeweils einen PromilleWert der BildschirmMasse abspeichere
so ähnlich mache ich es auch. aber es kommt noch eine andere Überlegung mit dazu :

wenn eine App auf verschiedenen PCs laufen soll ist ein "Zoom" evtl. notwendig weil sonst alles viel zu klein.
man sollte aber mit der kleinsten Grösse anfangen (Minimum Hardware) also 800x600, 1024x768 etc. um es zu "Zoomen"

mit AppDeskTop():CurrentSize() kannst du dann den "Zoom" Faktor errechnen.

Code: Alles auswählen

// Fieldwide STATIC
STATIC nXfaktor := 1.00
STATIC nYfaktor := 1.00

PROCEDURE CALCZOOM(aSize)
LOCAL aDesk := AppDesktop():currentSize()
DEFAULT aSize TO {800,600}

  nXfaktor := aDesk[1] / aSize[1]
  nYfaktor := aDesk[2] / aSize[2]
RETURN

FUNCTION Faktor_X(nValue)
   IF PCOUNT() > 0
      nXfaktor := nValue
   ENDIF
RETURN nXfaktor

FUNCTION Faktor_Y(nValue)
   IF PCOUNT() > 0
      nYfaktor := nValue
   ENDIF
RETURN nYfaktor
damit hättest du den "relativen" X,Y Faktor für Pos/Size

Code: Alles auswählen

   XbpStatic():new( oDraw, , { Faktor_X()*12,Faktor_Y()*132},;
                              {Faktor_X()*48,Faktor_Y()*24} , aPres)
wenn nun dein Pos/Size aus einer Tabelle kommen "schreibt" man ja keinen Code sondern würde es "on-fly" machen.

nun haben wir zwar die Controls auf die "relative" Grösse gebracht aber uns fehlt noch der "passende" Font.

Code: Alles auswählen

FUNCTION MyFont()
STATIC oFont
   IF EMPTY(oFont)
      oFont  := xbpFont():new()              // Font-Objekt
      oFont:familyName := "Arial"            // Font beschreiben
      oFont:height     := ROUND(11*nYfaktor,0)
*     oFont:width      := 0
      oFont:create()
   ENDIF
RETURN oFont
den Font würde ich so setzten

Code: Alles auswählen

   oDlg:create()
   oDlg:drawingArea:setFont( MyFont() )
also nicht jedes einzelne Control sondern auf den Parent.

---

die "Umrechnung" mit "Zoom" Faktor reicht normalerweise aus.
jedoch könnte der User auch einen anderen "Windows Zoom" Faktor (DPI) eingestellt haben -> "Falsche" AppDeskTop():CurrentSize()

---

die Länge eines SLE wird gewöhnlich über o:bufferLength eingestellt und ist default 32.

Code: Alles auswählen

   nLen     := aStructure[i][DBS_LEN]
   cText    := REPLICATE("X",nLen)
   aPoints  := GraQueryTextBox(oPS,cText)

   nWide    := ABS(aPoints[3][1] - aPoints[1][1])
   nHeight  := ABS(aPoints[4][2] - aPoints[1][2])

   IF cType == "D" // Datum CENTURY ON
      nWide += 4
   ELSEIF cType == "L" // Logisch : wäre nur 1 was zu klein ist
      nWide += 4
   ENDIF

   aSize[1] := nWide
   aSize[2] := nHeight

   oSLE := DragableGet():New(::oForm,,aPos,aSize,,.T.)
   oSLE:bufferLength := nLen
   cText  := aStructure[i][DBS_NAME]
   bblock := DBF2BLOCK("FIELD->"+cText,cType)
   oSLE:Datalink := &(bblock)
   oSLE:Create()
die Font "Berechnung" mittels "Zoom" Faktor ist wahrlich nicht genau ...
wenn man die Grösse des SLE hat kann man mit GraQueryTextBox() genau raus finden welche Font Grösse noch passen würde.
gruss by OHR
Jimmy
GrillenHirni
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 116
Registriert: Do, 18. Jul 2013 11:56
Kontaktdaten:

Re: SLE einfärben: High Noon...

Beitrag von GrillenHirni »

Ui...! Soweit hatte ich noch gar nicht gedacht...

So von weitem kann ich mir vorstellen, worum es geht, aber
ich weiss nicht, ob ich so langsam lesen kann, dass ich es
im einzelnen dann begreife...

Die Code-Beispiele helfen mir aber sehr...!


Jetzt hab ich grad das Problem:

Wenn ein Platzhalter verschoben wird, ändert er unter Umständen
seine Position in der ReihenFolge der PlatzHalter. Also beispielsweise
ist der ehemals unterste PlatzHalter in der BildschirmMaske nach
einer VerschiebeAktion nicht mehr der unterste...

Ich habe pro Feld ein Objekt: oFld.

Die FeldObjekte habe ich in einem Array: aoFld

Um sie zu sortieren pflege ich einen Index, der aufgrund der Position
ermittelt wird: oFld:nPosIndex.

Jetzt hab ich versucht, eine FUNCTION zu basteln, welche das Array
aoFld aufgrund von aoFld[n]:nPosIndex umsortiert.

Es wurde eine Katastrofe..! Es sind so ineinandergeschachtelte DO WHILE-Konstrukte -
einerseits tun sie nicht was sie sollten, und zusätzlich kann ich sie nicht mehr lesen -
viel zu kompliziert und zu langsam...

Gibt es denn einen etwas eleganteren und funktionabeln Algorythmus,
um aoFld nach aoFld[n]:nPosIndex zu sortieren...?

Allen einen schönen Abend...
Grilli
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SLE einfärben: High Noon...

Beitrag von AUGE_OHR »

GrillenHirni hat geschrieben:Jetzt hab ich grad das Problem:
zunächst mal paar Definitionen damit wir über das selbe sprechen:

Xbparts welche o:TabStop := .F. haben spielen keine Rolle für die "Reihenfolge"
Die Reihenfolge erhält man mit o:Childlist ( bei GET ist es die o:Getlist )
die Position in der Reihenfolge ergibt sich aus o:Create() bzw. o:Configure()

---

das mit der Reihenfolge z.b. nach o:Configure, hatte ich auch.
im Formdesigner gibt es die Möglichkeit die Reihenfolge neu zu sortieren ... so etwas in der Art müsste man dann haben.

---

da fast jedes Xbpart die Superklasse XbpPartHandler() hat kann man den o:Cargo Slot nutzen um z.b. die Reihenfolge in der o:Childlist() zu speichern.
wenn man nun ein XbPart verschiebt bleibt die Nummer in o:Cargo was man später abspeichern kann.

beim einlesen sollte alles in ein Array gehen ( ich speichere sowieso ein Array statt 100 Felder / Records)
das Array kann man dann nach den (ex. o:Cargo) Werten sortieren bevor man die XbParts anlegt und o:Create ausführt.

---

wenn du Problem beim "sortieren" eines Array hast müssten wir den Code sehen um zu helfen.
vielleicht liegt es aber auch an deinem "Sortier-Begriff" den du verwendest.

im Helpfile zu ASORT() wird nach 1 Spalte sortiert

Code: Alles auswählen

   ASort( aArray,,, {|c1,c2| c1 > c2 } ) 

   ASort( aArray,,, {|aX,aY| aX[1] < aY[1] } ) 
   ASort( aArray,,, {|aX,aY| aX[2] > aY[2] } )
in diesem Fall müsste "alles" in einer Spalte stehen was sortiert werden soll

bei Index Dateien kann man ja über mehrere Felder einen Index bauen :

Code: Alles auswählen

   FIELD->NACHNAME+FIELD->VORNAME
das selbe geht auch mit Array

Code: Alles auswählen

   ASort( aArray,,, {|c1,c2| c1+C2 > c1+c2 } ) 
wie auch beim Index ist es ein STRING Vergleich der die Sortierung bewirkt.

evtl. musst du mehrer Schritte machen wie z.b. bei Directory()

Code: Alles auswählen

LOCAL nStartAt := 1

   // sort "D"irectory first
   //
   ASORT( aDir,,, { | x, y | "D" $ x[ LV_ATTR ] } )
   AEVAL( aDir, { | x, i | nStartAt := IF( "D" $ x[ LV_ATTR ], i, nStartAt ) } )
   ASORT( aDir, 1, nStartAt, { | x, y | UPPER( x[ LV_NAME ] ) < UPPER( y[ LV_NAME ] ) } )
gruss by OHR
Jimmy
GrillenHirni
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 116
Registriert: Do, 18. Jul 2013 11:56
Kontaktdaten:

Re: SLE einfärben: High Noon...

Beitrag von GrillenHirni »

Hallo Jimmy...

Ja betreffend den grundsätzlichen Ansatz:

Bisher hab ich nur TastaturSteuerung. Auf MausUnterstützung konzentriere ich
mich irgendwann mal auf Wolke sieben...

Um o:TabStop habe ich mich noch nicht gekümmert - die Teile werden mit
den Crs-Tasten angewählt - es ist ein Verfahren, welches möglichst ergonomisch
ermöglichen soll, im Bedarfsfall den PlatzHalter für die FeldBezeichnung UND den
PlatzHalter für den Wert anzusteuern, was mit oTabStop glaube ich nicht ideal
wäre und was ich im KeyHandler übersteuern müsste, dass [TAB] etwa gleich reagiert,
wie die CursorTasten...

Mit ASort habe ich es nicht geschafft. Deine Beispiele muss ich aber noch ausprobieren.
Wenn es damit bei dieser Gelegenheit nicht schaffe, kann ich sie bestimmt an anderer
Stelle verwenden.

Ich hab aber nicht einfach ein mehrdimensionales Array. Die Voraussetzung ist eben so,
dass ich ja ein Array hab, welches die Objekte für die Felder enthält.

L_aoMskFld:={L_oMskFld,L_oMskFld,L_oMskFld,L_oMskFld...}

Im Dialog habe ich einen Zeiger, welcher PlatzHalter für die FeldBezeichnung ausgewählt ist
und welcher PlatzHalter für den Wert ausgewählt ist.

L_oDlg:nFldAktiv
L_oDlg:nValAktiv


Die Objekte für die Felder enthalten je das SLE jeweils für den PlatzHalter für die
FeldBezeichnung sowie das SLE für den PlatzHalter des Wertes:

L_oMskFld:oFldSLE
L_oMskFld:oValSLE

sowie alle anderen notwendigen Informationen, welche ein entsprechendes Feld
betreffen.

Darunter einen Index, der sich aus der Position errechnet:

L_oMskFld:nPosIndex

Wenn ein Feld oder Wert die Position verändert hat, muss das Array nach dem
Index für die Position

L_oMskFld:nPosIndex

umsortiert werden.

Dafür hab ich im Moment zwei DO WHILE-Strukturen:

Die erste DO WHILE-Struktur sortiert die Felder gegebenenfalls nach oben,
Die zweite Do WHILE-Struktur sortiert die Felder gegebenenfalls nach unten.

Code: Alles auswählen

METHOD oMskDlg:SortPosIndex()
//=========================
LOCAL L_nMskFld,L_nAnzMskFld
LOCAL L_nTMskFld
LOCAL L_nPosIndex

LOCAL L_lMskChanged
LOCAL L_lDummy

LOCAL L_aoMskFld,L_oMskFld
LOCAL L_oTMskFld




L_lMskChanged:=self:lMskChanged

L_aoMskFld:=self:aoMskFld
L_nAnzMskFld:=self:nAnzMskFld


IF (L_lMskChanged=.T.)

  /*

  */
  L_nMskFld:=1

  DO WHILE (L_nMskFld<L_nAnzMskFld)

    IF (L_aoMskFld[L_nMskFld+1]:nPosIndex<L_aoMskFld[L_nMskFld]:nPosIndex)

      L_oTMskFld:=L_aoMskFld[L_nMskFld+1]

      L_aoMskFld[L_nMskFld+1]:=L_aoMskFld[L_nMskFld]

      L_aoMskFld[L_nMskFld]:=L_oTMskFld

    ENDIF    /* IF (L_aoMskFld[L_nMskFld+1]:nPosIndex<L_aoMskFld[L_nMskFld]:nPosIndex) */

    L_nMskFld:=L_nMskFld+1

  ENDDO    /* DO WHILE (L_nMskFld<L_nAnzMskFld) */


  /*

  */
  L_nMskFld:=L_nAnzMskFld

  DO WHILE (L_nMskFld>1)

    IF (L_aoMskFld[L_nMskFld-1]:nPosIndex>L_aoMskFld[L_nMskFld]:nPosIndex)

      L_oTMskFld:=L_aoMskFld[L_nMskFld-1]

      L_aoMskFld[L_nMskFld-1]:=L_aoMskFld[L_nMskFld]

      L_aoMskFld[L_nMskFld]:=L_oTMskFld


    ENDIF    /* IF (L_aoMskFld[L_nMskFld-1]:nPosIndex>L_aoMskFld[L_nMskFld]:nPosIndex) */

    L_nMskFld:=L_nMskFld-1

  ENDDO    /* DO WHILE (L_nMskFld>1) */


ENDIF    /* IF (L_lMskChanged=.T.) */




RETURN(self)


Das ist wahrscheinlich übel handgestrickt...

Es scheint zwar zu funktionieren, aber mein Gefühl sagt mir, dass es das nicht
sein kann. Ich befürchte, dass man das eventuell mit dem CodeBlock-Parameter
in ASORT lösen könnte oder das es jedenfalls mit diesen DO-WHILE-Schlaufen
nicht optimal sein kann...

Uff... Ich hoffe, Du musst nicht weinen, wenn Du meinen Code siehst...

Herzlich...
Grilli
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SLE einfärben: High Noon...

Beitrag von AUGE_OHR »

hi,

ich "denke" du machst es dir zu kompliziert.

1.) wenn du die Daten aus einer DBF bekommst könntest die DBF nach dem "laden" ja schliessen.
das Array dient also "nur" als Vorlage des Layout d.h. nach dem erstellen der XbParts sollte es obsolet werden.

1a.) Layout ... (das ist das was man auf dem Bildschirm "sieht")

2.) alle Informationen die du brauchst sollten in jedem XbPart enthalten sein.
beim abspeichern, aus dem Array von o:Childlist(), holt man sich dann wieder die Information von jedem XbPart.
ob du die Informationen für jedes Control einzeln oder als ein Array mit allem abspeicherst ist im Prinzip. egal

3.) Maske löschen !

4.) nach dem abspeichern lese ich die Informationen wieder ein und aus dem Array -> 1.)

---

1a.) wir haben von jedem Control aPos ... und "das" ist doch unser Layout.

Code: Alles auswählen

   ASORT(aArray,,,{|x,y| x[ID_CLASS]+STR(x[ID_POS,2])+STR(x[ID_POS,1]*-1) > ;
                         y[ID_CLASS]+STR(y[ID_POS,2])+STR(y[ID_POS,1]*-1)  } )

// ID_CLASS -> oObj:className()
ich sortiere hier auch die zu erstellenden Objecte ("SAY" vor "GET") sowie die Position bevor ich die in einer Schleife erzeuge (o:Create() )
die Reihenfolge wäre hier wie Cl*pper also oben links -> rechts -> runter -> links (rechts bei mehreren Spalten)
gruss by OHR
Jimmy
GrillenHirni
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 116
Registriert: Do, 18. Jul 2013 11:56
Kontaktdaten:

Re: SLE einfärben: High Noon...

Beitrag von GrillenHirni »

Hallo Jimmy...
AUGE_OHR hat geschrieben:1.) wenn du die Daten aus einer DBF bekommst könntest die DBF nach dem "laden" ja schliessen.das Array dient also "nur" als Vorlage des Layout d.h. nach dem erstellen der XbParts sollte es obsolet werden.
Da bin ich nicht ganz sicher, ob wir vom gleichen Ansatz sprechen:

Ich lese die Daten aus einer ParameterDatei....

Also aus der Datei DbfFeld.Dbf, welche die Parameter für die
Felder enthält - beispielsweise für eine DateiStruktur "Kunden.Dbf".

Die Datei "Kunden.Dbf" selber muss im BildschirmGenerator nicht zur
Verfügung stehen.

Nach dem Anpassen des Layouts schreib ich die Parameter mit den
neuen BildschirmPositionen in die ParameterDatei zurück.

AUGE_OHR hat geschrieben:1a.) Layout ... (das ist das was man auf dem Bildschirm "sieht")
Ja.

AUGE_OHR hat geschrieben:ich sortiere hier auch die zu erstellenden Objecte ("SAY" vor "GET") sowie die Position bevor ich die in einer Schleife erzeuge (o:Create() )die Reihenfolge wäre hier wie Cl*pper also oben links -> rechts -> runter -> links (rechts bei mehreren Spalten)
Ich glaube, dieser Algorythmus ist wahrscheinlich die Lösung für meine SortierRoutine.

Vielleicht ungefähr:

Code: Alles auswählen

ASORT(L_aoMsk,,,{|x,y| x:nPosIndex > y:nPosIndex  } )

Das wäre ja ziemlich einfach...? Probiere ich gleich morgen aus...!

Herzliche Grüsse und eine gute Nacht...
Grilli
GrillenHirni
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 116
Registriert: Do, 18. Jul 2013 11:56
Kontaktdaten:

Re: SLE einfärben: High Noon...

Beitrag von GrillenHirni »

Na also... Geht doch...:

BildschirmGenerator im GUI-Modus...


Herzliche Grüsse
Grilli
Dateianhänge
FldMove.zip
(148.71 KiB) 376-mal heruntergeladen
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SLE einfärben: High Noon...

Beitrag von AUGE_OHR »

GrillenHirni hat geschrieben:Na also... Geht doch...:
BildschirmGenerator im GUI-Modus...
das sieht doch schon gut aus =D>
gruss by OHR
Jimmy
GrillenHirni
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 116
Registriert: Do, 18. Jul 2013 11:56
Kontaktdaten:

Re: SLE einfärben: High Noon...

Beitrag von GrillenHirni »

Hallo Ihr Lieben, hallo Jimmy!

Ja ich find auch - es sieht nicht schlecht aus... Jetzt wird es richtig knifflig, weil
ich in der uneingeschränkten Version zusätzlich jeweils PlatzHalter für Labels und
zugehörige Values unterstützen möchte.

Beispiel: der Anwender gibt eine KontoNummer ein - es wird eine KontoBezeichnung
und der KontenSaldo eingeblendet... Der ausgebaute BildschirmGenerator soll diese
Features unterstützen...

Mit dieser Nachricht möchte aber im Sinne eines Beitrages von Tom:

http://www.xbaseforum.de/viewtopic.php?f=12&t=2682

danke sagen... Und zwar allen, die mir geholfen haben im allgemeinen, und Dir,
Jimmy im speziellen.

Der Dank gehört eher ins Forum Community - "rund ums Forum". Darum ist er
auch dort zu finden. Die Beiträge sind anscheinend dort nicht so hunderprozentig
chronologisch geordnet - das Betreff ist: "Once upon a time in Alaska".

Grilli


P.S: Clint Eastwood ist angekommen - wohin soll ich ihn nun schicken?
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SLE einfärben: High Noon...

Beitrag von AUGE_OHR »

GrillenHirni hat geschrieben:Beispiel: der Anwender gibt eine KontoNummer ein - es wird eine KontoBezeichnung und der KontenSaldo eingeblendet... Der ausgebaute BildschirmGenerator soll diese
Features unterstützen...
hm ... in deinem Demo gibt es ja nur eine DBF die für das Layout zuständig ist.
in der Layout DBF hast du nun den Namen der DBF und die Feld Namen,Type,Len

gegenüber GET benötigt man für ein SLE den o:Datalink Slot welchen man mit einem Codeblock bestücken muss.
"wie" das aussieht erfährst du am besten mit dem Formdesigner XppFD.EXE

mache dir eine DBF wo du alle Typen (C,N,D,L) drin hast
XppFD.EXE -> Assistenten -> Felder -> links DBF wählen -> rechts Felder wählen -> OK
es erscheint ein Rahmen den du auf der Form platzierst. Die Koordinaten interessieren uns nicht, nur die o:datalink.
danach dann CLASS Code generieren und dir die o:Datalink ansehen. je nach Daten Type sehen die unterschiedlich aus.

zu Anzeigen (SAY) verwendet man oSLE:SetData() und oSLE:GetData() entspäche dem GET.
da man es für jedes SLE Object machen muss sollte man die SLE Objecte in ein Array aufnehmen wie der Formdesigner.

Code: Alles auswählen

alle SAY 	AEVAL(aEditControls, {|o|o:SetData()} )
alle GET	AEVAL(aEditControls, {|o|o:GetData()} )
! Note : im Netzwerk ist ein LOCK notwendig VOR dem o:GetData()
gruss by OHR
Jimmy
Antworten