PushButton

[Martin Altmann]

Hallo Manfred,
nein - das erstere ist mir schon klar (mach ich ja auch ab und an).
Mir ging es um die Methode :group - das verstehe ich nicht.

Viele Grüße,
Martin

[Manfred]

also bevor ich hier Unsinn erzähle....

Ich habe es gerade nochmal unter :group gelesen. Ich verstehe es auch nicht, bzw. sehe den Sinn und Zweck beim mir nicht.. Ich baue es wieder aus.

[Manfred]

Bevor ich jetzt den ganzen Krempel wieder umbaue und danach gefrustet bin, hier noch ein Frage:

Man kann ja für jeden Pfurz einen Extraobjektnamen anlegen, man kann aber auch alles in ein XBP reinpacken. Um bei letzterer Aktion alles einzeln gezielt ansprechen zu können, ist da die Methode :setname() zu gebrauchen, oder hat die damit nichts zu tun? Es wäre ja schön, alles in ein Objekt und dann über ID anschalten, abschalten usw.
Habe ich das so richtig verstanden? Doch, oder?

[Martin Altmann]

Hallo Manfred,

Habe ich das so richtig verstanden? Doch, oder?

ich glaube: Nein

Viele Grüße,
Martin

[Manfred]

aha

[Manfred]

Ich weiß ja nicht, ob das noch hierher gehört, aber es ist zumindest aus dem gleichen Fall.

Ich kann jetzt über den PushButton das 1.Eingabefeld aktivieren und auch mit dem Cursor rein, aber da gibt es ein komisches Phänomen. Ich kann nur unterlegten Text überschreiben, bzw. wenn ich einen Buchstaben weglösche, dann einen neuen dafür schreiben.
Also habe ich mal nachgesehen in Beispielen und da wird jedesmal TRIM(feld) gemacht. Das habe ich eingebaut und jetzt kann ich alles machen. Was passiert denn da?

[AUGE_OHR]

hi,

Ich kann nur unterlegten Text überschreiben, bzw. wenn ich einen Buchstaben weglösche, dann einen neuen dafür schreiben.
Also habe ich mal nachgesehen in Beispielen und da wird jedesmal TRIM(feld) gemacht. Das habe ich eingebaut und jetzt kann ich alles machen. Was passiert denn da?

du hast schnell den "Nachteil" eines XbpSLE bemerkt ...
um "weiter" GUI "GET" Problem zu beheben solltest du dir "SLEPic"
von "James Loughner" holen und verwenden.
1.) hat PICTURE
2.) hat besseres VALID
3.) hat Farben ...
4.) mit ENTER in das nächste SLEPic
5.) mit Cursor rauf/runter durch die SLEPic (statt TAB)
.... und noch so paar Sachen dir mir jetzt nicht einfallen

gruss by OHR
Jimmy
p.s. solltest du SLEPic mit Memvar verwenden so funktioniert meine
Function VARBLOCK so nicht mehr da SLEPIc sich selbst um den
Codeblock kümmert. verwende VAR2BLOCK.

Code: Alles auswählen

FUNCTION VAR2BLOCK( uMem )
LOCAL bblock
RETURN { |x| IIf( x==NIL, uMem, uMem := x ) }

[brandelh]

Ich kann nur unterlegten Text überschreiben, bzw. wenn ich einen Buchstaben weglösche, dann einen neuen dafür schreiben.
Also habe ich mal nachgesehen in Beispielen und da wird jedesmal TRIM(feld) gemacht. Das habe ich eingebaut und jetzt kann ich alles machen. Was passiert denn da?

Hallo Manfred,

du kannst beim SLE angeben, wieviele Zeichen in den Editierpuffer passen. Und BLANKS sind auch Zeichen die zählen ! Wenn der Überschreibemodus aus ist (nichts markiert), kannst du nur neue Zeichen einfügen wie die Anzahl der Zeichen kleiner als der eingestellte Wert ist.

Also IMMER mit (all)trim() laden !

[Manfred]

Hi Hubert,

jetzt wo Du es erwähnst, klingelz es langsam bei mir. Tja, die alten Clipperzeiten, sie sind noch fest im Kopf.

[Manfred]

Moin,

Fragen über Fragen..

Ich beende oben angeführtes Beispiel mit

Code: Alles auswählen

::oPbEnde:activate   := {|| lExit := .T.} 
nEvent := 0
do while ! lExit
    nEvent := Appevent( @mp1, @mp2, @::oAkpDlg)
    ::oAkpDlg:HandleEvent( nEvent, mp1, mp2)
enddo
::oAkpDlg:destroy()

Wenn ich den Beenden Button drücke, dann verschwindet nur der und der Rest bleibt stehen. Wird die Sache nicht geschlossen durch ein destroy() des obersten Objektes?
Ich habe auch versucht alle Xbp nacheinander mit :destroy() zu schließen, aber dann bleibt am Schluß nur noch ein leeres Fenster übrig und es kommt die Fehlermeldung: falscher Objekt Status.

[Martin Altmann]

Hallo Manfred,
kein Wunder! Schau Dir mal Deine Eventabhandlung an:

Code: Alles auswählen

do while ! lExit 
  nEvent := Appevent( @mp1, @mp2, @::oAkpDlg) 
  ::oAkpDlg:HandleEvent( nEvent, mp1, mp2) 
enddo 
::oAkpDlg:destroy()

Du nutzt in AppEvent die Variable ::oAkpDlg per Referenz - das bedeutet, dass der Inhalt dieser Variable immer geändert wird Sie enthält also immer das letzte Objekt, das einen Event bekommen hat
Wenn Du also auf den Ende-Knopf drückst, dann wird dieses Objekt in der Variablen stehen und somit am Ende destroyed
Ich vermute mal, dass Du in ::oAkpDlg eigentlich Dein Fenster stehen hast.
Was Du machen musst, ist folgendes:

Code: Alles auswählen

do while ! lExit 
  nEvent := Appevent( @mp1, @mp2, @oXbp) 
  oXbp:HandleEvent( nEvent, mp1, mp2) 
enddo 
::oAkpDlg:destroy()

Wobei oXbp auch gerne eine lokale Variable sein kann.

Viele Grüße,
Martin

[brandelh]

Code: Alles auswählen

::oPbEnde:activate   := {|| lExit := .T.} 
nEvent := 0
do while ! lExit
    nEvent := Appevent( @mp1, @mp2, @::oAkpDlg)
    ::oAkpDlg:HandleEvent( nEvent, mp1, mp2)
enddo
::oAkpDlg:destroy()

Wenn ich den Beenden Button drücke, dann verschwindet nur der und der Rest bleibt stehen.

Logisch !

Schau mal die Anmerkungen zu AppEvent() genauer an.
Der 3. Parameter erhält das Object, das den Event ausgelöst hat !
Nach dem ersten Durchlauf, ist ::oAkpDlg nicht mehr dein Fenster, sondern das Xbp, das den Event verursacht hat. Wenn du auf den Button klickst, ist es der Button. Dieser verarbeitet den Event und closed sich selbst, danach destroyed er sich und das war es, die Referenz auf dein Fenster ist nicht mehr in der Variablen ...

Die Ereignisschleife sollte unbedingt sonst nicht benutzte LOKALE Variabeln nutzen:

Code: Alles auswählen

do while ! lExit
    nEvent := Appevent( @mp1, @mp2, @oXbp)
    oXbp:HandleEvent( nEvent, mp1, mp2)
enddo

Ob Das lExit hier Ärger machen kann weiß ich jetzt nicht, normalerweise steht da ein do while nEvent # Close ... (Genauen Wortlaut weiß ich jetzt nicht). Du solltest im XppFD ein kleines Beispielfenster machen und damit experimentieren, ohne den Ballast einer kompletten Anwendung die in Umstellung ist.

[Manfred]

Hi Hubert,

das war wieder ein Berg von Mißverständnissen. So wie Du es vorgeschlagen hast, hatte ich es von Anfang an, aber da klappte es mit den Pushbuttons nicht. Dann habe ich angefangen zu probieren und dabei eben das oXbp in der Eventschleife ausgetauscht. Nachdem aber der Fehler ganz woanders lag, nämlich in der Initialisierung der Gruppen ganz oben, hatte ich diesen Part natürlich wieder vergessen. Naja, ::oAkpDlg gegen ein Local oXbp ausgetauscht und es klappt. Verflixt, das ist gewöhnungsbedürftig.

Nur Pennerei, so was ärgerliches. Tja, es fehlt die Routine.

Aber, man kann sagen im Moment ist der Lernfaktor und Aha Effekt recht hoch.... naja, hat ja auch was für sich.

[Manfred]

Hi Martin,
huch, Deine Nachricht habe ich erst jetzt gesehen....

[Manfred]

Noch ne Frage hintendran,

destroy() gibt ja nur die Systemresourcen wieder frei, kann ich denn danach wieder ganz normal den Programmteil aufrufen? Die Objekte bleiben ja erhalten. Ist das dann so, als wenn ich eine Speichervariable überschreibe, oder wie ist das zu verstehen, wenn ich "neue" Instanzen bilde. Nur mal so, nicht dass ich mir unbewußt den Speicher zuschaufel, in dem ich nur ein destroy() mache und immer wieder eine neue Instanz bilde.

[brandelh]

Hallo Manfred,

:destroy() hebt :create() auf.
Du kannst - wenn ich mich jetzt nicht irre - die iVars wieder laden und danach erneut ein :create() machen.
Also im Prinzip ist das Object so als ob du es gerade neu erzeugt hast, aber die Variablenwerte können natürlich eventuell geändert worden sein.

Daher ist es wahrscheinlich sinnvoller die Variable nach :destroy() wieder neu mit New() zu erzeugen:

Code: Alles auswählen

oXbp := XbpSLE():New(....) 
oXbp:create()
...
oXbp:destroy()  // wichtig für die Freigabe von Systemresourcen !
// Achtung INIT Werte können geändert worden sein ![
oXbp:iVarXXX := neue werte
oXbp:create()

... oder so, dann sind INIT Werte auf definiertem Grundzustand
oXbp:destroy()  // wichtig für die Freigabe von Systemresourcen !
oXbp := XbpSLE():New(....) 
oXbp:iVarXXX := neue werte
oXbp:create()

Die kannst natürlich NICHT nach einem :destroy() z.B. eine Methode aufrufen:

oXbp:destroy()
oXbp:setData(´...) gibt einen Fehler (falscher Objectstatus ...)

[Manfred]

Hi Hubert,

genau das war meine Frage. Mit :new(). Dann brauche ich nichts zu ändern, sondern kann immer wieder eine "Schleife" durchlaufen....., also :new() :destroy() usw.

[Manfred]

Ich muß noch einen nachsetzen,

ich weiß aber jetzt nicht , wie ich es plausibel machen soll.

Also, ich habe jetzt die Combobox mit eingebunden und sie enthält auch Daten, aber diese Daten werden nicht so angezeigt, wie ich es bei einem Test mit "gleichen" Optionen programmiert habe. Die Listbox klappt nicht nach unten auf, obwohl der Pfeil rechts daneben ist. Wenn ich bekannte Daten in das Eingabefeld eintippe, dann passiert nichts, sobald ich aber mit dem Cursor nach unten gehe, dann erscheinen die Einträge.

Irgendwo mache ich mal wieder was falsch, aber ganz schwer.
Hat jemand diesen Fehler schon mal gehabt und kan so aus der Hüfte geschossen sagen, wo ich zuerst mal nachsehen soll?

[AUGE_OHR]

hi,

Also, ich habe jetzt die Combobox mit eingebunden und sie enthält auch Daten, aber diese Daten werden nicht so angezeigt, wie ich es bei einem Test mit "gleichen" Optionen programmiert habe. Die Listbox klappt nicht nach unten auf, obwohl der Pfeil rechts daneben ist. Wenn ich bekannte Daten in das Eingabefeld eintippe, dann passiert nichts, sobald ich aber mit dem Cursor nach unten gehe, dann erscheinen die Einträge.
...
.. aus der Hüfte geschossen sagen, wo ich zuerst mal nachsehen soll?

ist es das was du suchst ?

Code: Alles auswählen

oCombo := XbpCombobox():new( ...
...
oCombo:create()
...
FOR i = 1 TO LEN(aUser)
   oCombo:addItem( aUser[i] )
NEXT
...
oCombo:ItemSelected := {|mp1, mp2, obj| ;
                                        tumal( obj:XbpListbox:getData(), ...)
...
oCombo:XbpSLE:dataLink := VARBLOCK(@mANUSER)
oCombo:XbpSLE:setData()
AAdd ( aEditControls, oCombo:XbpSLE )

gruss by OHR
Jimmy

[Manfred]

Hi Jimmy,

so ähnlich habe ich es schon, aber ich kann bei Deinem Beispiel mit dem VARBLOCK(@mANUSER) nichts anfangen. Wozu ist das gut?

[AUGE_OHR]

hi,

Hi Jimmy,
so ähnlich habe ich es schon, aber ich kann bei Deinem Beispiel mit dem VARBLOCK(@mANUSER) nichts anfangen. Wozu ist das gut?

naja das ist die MemVar für das SLE Feld der Combobox wo du entweder
was eintippst oder wenn du aus der Combobox auswählst was als
"Ergebniss" dann vorhanden ist. deshalb der oCombo:XbpSLE:dataLink
damit du das "oCombo:ItemSelected" auch in das SLE bekommst.

gruss by OHR
Jimmy

[Manfred]

Ich verstehe überhaupt nichts mehr.
Geht das alles so kompliziert weiter?
Eigentlich wollte ich nur Textmodus programmieren, dann habe ich ein paar kleine GUI Fenster eingebaut und jetzt bin ich dabei die gesamten Erfassungsbildschirme auf GUI umzustellen. Entweder stelle ich mich saublöd an, oder aber es ist wirklich so kompliziert......

Ich stehe hier wie ein Ox vor dem Berg, wenn es um die Verarbeitung von Comboboxen geht. Ich kriege im Moment weniger als die Hälfte gebacken.

[AUGE_OHR]

hi,

Ich verstehe überhaupt nichts mehr.
Geht das alles so kompliziert weiter?

so ging es mir am Anfang auch ... immer nur steil "Bergauf"
aber das wir noch ...

Code: Alles auswählen

::oPbEnde:activate   := {|| lExit := .T.} 
nEvent := 0
do while ! lExit

um dich jetzt ganz zu verwirren : du solltest KEINEN AppEvent in deiner
Class haben es seit den du willst die IMMER modal verwenden.

Vielmehr ist es wohl angesagt nur in der MAIN "ein" AppEvent zu haben
und evtl. Keystoke per oObj:keyboard und PostEvent(P_Aktion,,,oObj)
zu steuern. Das bedeutet auch das du nur "einmal" o:create verwendest
und kein o:destroy sondern o:hide / o:show benutzt was dir die
Möglichkeit gibt deine Class "mehrfach" (MDI) zu benutzen...

alles klar ... viel Spass beim GUI Cl*ppering

gruss by OHR
Jimmy

[Manfred]

Ich möchte hier jetzt eigentlich überhaupt nichts mehr sagen. Ich weiß warum keiner mehr mit mir spielen will......

Alle habe Angst sich anzustecken....



Wenn ich der Combobox natürlich sage, das sie nur eine Höhe von 20 hat, dann KANN sie sich nicht aufklappen, selbst wenn sie wollte.

Ich glaube meine nächste Frage schlucke ich am besten erstmal wieder runter, wer weiß welche Peinlichkeit da wieder hintersteckt.

[Martin Altmann]

Hallo Manfred,
sorry, dass ich nicht vorher reagiert habe - bin gerade wieder zu Hause rein! Und anstecken tue ich mich nicht - mein Scanner ist aktuell
Also: die ComboBox ist so ziemlich das komplizierteste Xbase++-Part, dass es gibt - zumindest von den "einfachen" Eingabecontrols.
Es ist zusammengesetzt aus zwei verschiedenen Controls - aus einer Listbox und einem Sle! Insofern muss man auch beide Einzelcontrols gesondert betrachten!
Wichtig ist auch (bezogen auf Dein Problem mit der Höhe) der folgende Hinweis aus der Hilfe:
Besonderheiten bei der Combobox
Bei der Erzeugung eines XbpCombobox-Objekts ist der Parameter <aSize> zu beachten, der die Größe -speziell die Höhe- einer Combobox definiert. Die Höhe umfaßt sowohl das Eingabefeld als auch die Listbox, selbst wenn die Listbox zu Beginn unsichtbar ist und erst nach einem Mausklick aufgeklappt wird. Wenn die Listbox aufklappbar ist, gehört der Bereich in einem Dialog bzw. XbpCrt-Fenster, den die Listbox bei der Anzeige einnimmt, zur Combobox. Das hat zur Folge, daß dieser Bereich nicht neu gezeichnet wird, bzw. daß keine Bildschirmausgaben darin erfolgen können, wenn die Instanzvariable :clipChildren auf .T. (wahr) gesetzt ist. Bei einem XbpCrt-Fenster ist das die Voreinstellung. Um im Fall der Combobox stets eine korrekte Anzeige zu haben, muß entweder die Instanzvariable :clipChildren auf .F. (falsch) gesetzt werden, oder ein statisches Dialogelement ist zu verwenden (z.B. ein Rahmen), in das die Combobox gezeichnet wird und das als Parent der Combobox dient.

Die Höhe des Eingabefeldes der Combobox wird automatisch der gewählten Fontgröße angepaßt. Sie kann nicht separat eingestellt werden.

Am besten liest Du Dir ausführlich die Hilfe gerade zur ComboBox durch - es lohnt sich!!

Viele Grüße,
Martin