Textfeld wert zuweisen

[Alfred]

Hallo,

ich habe mir mit dem Formdesigner ein Formular erstellt und dieses
beinhaltet ein Textfeld und einen Pushbutton.

Der Funktioncode wird ohne Fehler compiliert und gelinkt(Dank an Hubert
für sein XB.file).

Wenn ich auf den Pushbutton drücke möchte ich dass sich der Text im
Textfeld ändert.

oXbp:activate :={||oStatic1:caption := "Hello World!"}

reicht offensichtlich nicht aus. Wo liegt mein Denkfehler?

Der Formulardisgner sagt sowohl beim Pushbutton als auch bei
dem Staticfeld oXbp := ...... . Wie weist man der Caption des Staticfeldes
dann einen Wert zu?

Gruß

Alfred

[brandelh]

ich habe mir mit dem Formdesigner ein Formular erstellt und dieses beinhaltet ein Textfeld und einen Pushbutton.
...
oXbp:activate :={||oStatic1:caption := "Hello World!"}

Das Zuweisen an die Instanzvariable :caption reicht aus, wenn danach ein :create() oder :configure() folgt, im Programm selbst nimmt man eine spezielle Methode

Code: Alles auswählen

oXbp:activate :={||oStatic1:setCaption("Hello World!")}

bei einem SLE - das man eher für Eingaben nutzt - wäre es :setData() ...

Im Handbuch stehen die Instanzvariablen unterteilt in KONFIGURATION, das ist alles in INIT und :create() wird noch ausgeführt und in Laufzeit oder Callback (Reaktion auf Ereignisse) unterteilt. Nur letztere können Änderungen direkt bewirken.

[Martin Altmann]

Hallo Alfred,
ist es ein XbpStatic? Dann oStatic1:SetCaption("Hello World!" ).
Oder ist es ein XbpSle (weil Du auch "Textfeld" geschrieben hast)? Dann oStatic1:SetData("Hello World!")

Viele Grüße,
Martin

[Tom]

Hallo, Alfred.

Ich bin nicht sicher, was Du mit Textfeld meinst. Ich würde eher ein XbpSLE als Textfeld bezeichnen, wohingegen ein Static TYPE TEXT eine statische Textanzeige ist. Jedenfalls läßt sich bei letzterem der "Inhalt" so setzen:

oXbp:SetCaption('Hallo, Welt')

wohingegen bei einem SLE (also einem Single Line Edit, einem Eingabefeld) mit :SetData() gearbeitet werden muß.

Übrigens auch von mir ein verspätetes "Herzlich willkommen im Forum!"

[brandelh]

Heute läufts aber mit den Antworten

[Tom]

2D1G.

@Alfred: Der Form-Designer und diese Art, sich mit den XbParts zu beschäftigen, ist ein steiniger Weg. Schau Dir doch mal Tools wie eXpress++ oder TopDown an, die erleichtern den Umstieg auf GUI wirklich sehr, und man kann trotzdem nach und nach eine Menge über Objekte und Anzeigeelemente lernen.

[Alfred]

Hallo,

vielen Dank an alle, es läuft wie gewünscht

@tom
Kann ich denn davon ausgehen, dass xbase 1.9 und express++ richtig zu-
sammen arbeiten? Dass die Demo nach 6 Monaten immer noch nicht
korrigiert ist und keine Antwort auf meine e-mail erfolgt, hat mich bislang
vom Kauf abgeschreckt.

Welche von beiden(express++ oder topdown) macht denn in meinem Fall
am meisten Sinn:

Ich programmiere eigentlich meistens folgende Abläufe:

Wert in ein Maskenfeld eingeben, beim Verlassen wird ein kleines
Programm(Foxpro: Valid-Clause; Access: Afterupdate_Ereignis)
aufgerufen, um z.B. den Kundennamen anzuzeigen.

Gruß

Alfred

[Tom]

Hallo, Alfred.

Ich benutze eXpress++ seit 1998 und wir liefern seit fast einem Jahr eine mit Xbase++ 1.9 und eXpress++ erzeugte Version unserer Software an viele hundert Kunden aus. Der Link auf Rogers Site verweist auch auf eine 1.9-Demo. Sollte also funktionieren.

Code: Alles auswählen

#include 'dcdialog.ch'

@ 1,1 DCSAY "Name:" GET cName SAYSIZE ... GET SIZE ... SAYTOOLTIP .. GETTOOLTIP .. WHEN .. EDITPROTECT .. PICT .. VALID .. POPUP ... LOSTFOCUS {||MyCheckValue(cName)}

DCREAD GUI

Feddisch. (Die ganzen Optionen mit den zwei Punkten sind nur ein Abriß dessen, was mit eXpress++ innerhalb einer Zeile möglich ist, ohne sich durch tonnenweise immer gleichen Objektcode quälen zu müssen.)

[brandelh]

Hallo,

wenn du es nur für dich machst und nichts gegen den Clipper Look hast,
würde ich bei den @ say get bleiben. Da brauchst du von Clipper kaum umlernen, und kannst dennoch alle 32 bit Vorteile nutzen (drucken, Dateinamen etc.).

Der Einwand mit den Versionen und der Zukunftssicherheit hält mich
auch vom Einsatz von allzuviel Fremdsoftware ab (habe nur SQL Express).

Ich habe damals mit dem MDI Beispiel angefangen und dieses ausgebaut.
Heute ist man aber ja wieder von MDI abgekommen und SDI ist auch nicht schlecht, solange es einfache Programme bleiben. Der XppFD ist halt recht schwach, besonders beim REDO und auch mit der Maus macht man öffters was was man eigentlich nicht wollte.
Also oft zwischenspeichern.

Hier ist z.B. eine Vorlage für eigenen Programme:

C:\ALASKA\XPPW32\SOURCE\samples\apps\SdiDemo

[Alfred]

Hallo,

wenn mein Programm sich öffnet, habe ich 2 Fenster offen

1) hello_world_2b.exe
2) Mein erstes Alaskaformular.

Kann mich erinnern, dass ich bei einem VFP-Artikel gelesen habe, dass dies
für eine Windowsprogrammierung notwendig ist und man aber das 1.
Formular unsichtbar machen kann.

Gruß

Alfred

[brandelh]

Hallo Alfred,

was ist 'mein erstes Alaska Formular' ?

Meinst du das schware Fenster, das wie eine CMD-Box aussieht in dem die @say get Clipper Programme erscheinen ?

Dieses braucht man NUR wenn man Clipperstyle programmieren will.

Wenn nicht wird es abgeschaltet, indem man einen AppSys() Prozedur einfügt und somit die standard Prozedur ersetzt. So zum Beispiel:

Code: Alles auswählen

procedure AppSys()
return

Aber jetzt muss man sich natürlich auch um alles kümmern.
Eventuell ist es sinnvoller eine AppSys.PRG anzupassen. Näheres steht in der Hilfe wenn man nach AppSys() sucht. In dem SDI Beispiel steht z.B. eine angepaßte, die kein schwarzes Fenster mehr liefert.

Kann mich erinnern, dass ich bei einem VFP-Artikel gelesen habe, dass dies für eine Windowsprogrammierung notwendig ist und man aber das 1. Formular unsichtbar machen kann.

Ich kenne mich zwar mit VFP nicht aus, aber ich entwickle z.b. auch CGI-Webanwendungen. Diese haben überhaupt kein Fenster, obwohl sie teilweise mit PM Schalter gelinkt sind weil sie grafische Elemente nutzen (Drucken, XbpBitmap). Nur macht das in einem 'normalen' Programm wenig Sinn, da man ja nichts sieht.
Ein weiteres Beispiel für 'echte' Windowsprogramme ohne Oberfläche sind die ganzen Systemdienste, man sieht sie nicht aber sie arbeiten doch

[Alfred]

Hallo Hubert,

Code: Alles auswählen

procdure AppSys()
return

ist die Lösung für mein kleines Programm.

Das SDI-Beispiel werde ich mir in den nächsten Tagen mal in Ruhe ansehen.

Gruß

Alfred

[Daniel]

Heute ist man aber ja wieder von MDI abgekommen und SDI ist auch nicht schlecht, solange es einfache Programme bleiben.
Der XppFD ist halt recht schwach, besonders beim REDO ...

Hallo Hubert

darf ich dazu auch was fragen?
Wieso ist man von MDI wieder abgekommen (was hiess nochmal MDI / SDI?)
Was sind denn da Vor- und Nachteile?

Meine Erfahrung: mit dem XppFD kann man leben, so lange es nichts besseres gibt ...

[Martin Altmann]

Hallo Daniel,
MDI heißt Multi Document Interface (z.B. Word: Du hast in dem Fenster von Word beliebig viele Dokumente in einzelnen (Unter-)Fenstern offen).
SDI heißt Single Document Interface (z.B. der alte Internet Explorer: In Deinem Browser hast Du immer nur eine Webseite angezeigt).

Viele Grüße,
Martin

[brandelh]

MDI ... z.B. Word

die neueren Word Versionen verwenen wieder ein SDI Konzept.

Ein älteres Word (bzw. MDI Program) ist unten in der Taskleiste einmal zu sehen und schaltet intern von Child-Fenster zu Child-Fenster (Brief...). Das hat den Vorteil, dass man mit einem Klick alles vom Bildschirm weg bekommt um z.B. mit einem anderen Programm Zwischenergebnisse zu berechnen. Allerdings wird der Platz für die Child Fenster immer kleiner, da diese ja in dem MDI Container gebunden sind. Das MDI Child Fenster kann den Rahmen der Anwendung nicht verlassen.
Nun wurden die Rahmen außen bei XP größer, die Anzahl der Hilfsleisten in den Programmen wurde stark erhöht (ich meine Word ist schon bei 4 ...) und somit der Platz für den Text immer kleiner.

Heute wird dies als getrennte Fenster angezeigt, da kann man leichter von einem zum Text über die Taskleiste schalten, allerdings wird diese auch immer voller. Ich selbst verwende MDI für komplexere Programme. Z.B. Programm zur Rentenberechnung darin kann man dann unzählige Childfenster öffnen um die Renten für verschiedene Personen zu berechnen. Das macht natürlich so keiner, aber wenn z.B. gerade die Daten in einem Fall eingegeben werden ruft jemand an und will Auskunft zu seinen Daten. Dann wird einfach ein neues Child aufgemacht und das alte geht in den Hintergrund.
Im MDI Beispiel von Xbase++ kann man auch verschiedene Fensterarten (Artikel, Rechnung etc.) sehen.

Einfachere Programme wie z.B. ein Taschenrechner ... macht man SDI.

Ist natürlich auch eine Frage des persönlichen Geschmacks.

[Rolf Ramacher]

Hallo Alfred,

anfangs habe ich auch den Formdesigner verwendet. Da ich mit
static, sle, pushbutton im xbpdialog eigentlich nur arbeite kopiere ich die entsprechenden Fenster in meine PRG und passe die Größe und Inhalte an.