Edit.Text ohne DB oder INI Speichern

[Amenovis]

Ein Editfeld behält den Wert der vor der Compilierung angegeben wurde. Wenn ich nun den Text ändere und das Programm neustarte übernimmt das Editfeld ja wieder den Wert zur Zeit der Compilierung..

Natürlich könnte ich den Wert in eine DB schreiben oder in eine INI und bei neustart beides auslesen und den Wert dann dem Editfeld wieder zu weisen... bei Änderung wird dann der neue Wert in die DB oder INI übernommen....USW.

Wie das geht weis ich die Frage ist ob es nicht eine einfachere Möglichkeit gibt, den text im editfeld vor beenden des Programms zu speichern und bei neustart wieder im besagten editfeld erscheinen zu lassen ?

LG

Timo

[DieDolly]

Einfacher als in eine Ini-Datei geht wohl nicht.

Vielleicht ist es aber einfacher die hier zu verwenden

Delphi-Quellcode:

Edit1.Text := TFile.ReadAllText(Datei);

TFile.WriteAllText(Datei, Edit1.Text);

[Amenovis]

Ok dank dir

Es geht dabei nicht um schwer auch wenn ich einfacher geschrieben habe :) Es geht dabei um eine Extra Datei für einen blöden Wert oder eine Extra Spalte in einer Tabelle bzw eine Tabelle für einen sich ändernden Wert

Aber ok dann mach ich mir eine extra Tabelle... Die DB ist ehh vorhanden und ich hab keine Extra Datei..

gruß
Timo

[mkinzler]

Eine Alternative könntre auch eine Speicherung in der Registry sein.

[Amenovis]

Oha ok auf die Idee wäre ich jetzt nicht gekommen obwohl ich weiss das es möglich ist...Aber davon hab ich 0 Ahnung und vor Registry hab ich auch echt Respekt was kaput zu machen. Da lass ich lieber die Finger von :)

Aber trotzdem Danke :)

LG

Timo

[dummzeuch]

Irgendwo muss der Wert ja gespeichert werden. Früher, unter DOS konnte man noch das Executable patchen, aber unter Windows geht das nicht mehr, weil ein Schreibzugriff auf die Datei nicht möglich ist, wenn das Programm läuft. Virenscanner reagieren auf sowas aber auch allergisch.

Also bleibt nur:
* Eine zusätzliche Datei
* Ein Dienst, der die Daten für Dich speichert (Datenbank, "Cloud"-Server)
* Die Registry (die im Grunde auch nur eine zusätzliche Datei ist)

Oder halt der User, der sich die Wert merkt und immer wieder eintippt. ;-)

[KodeZwerg]

Wenns nur flüchtige Werte sein brauchen, eventuell über ClipBoard was zaubern?

[Luckie]

Zitat:

Zitat von KodeZwerg (Beitrag 1419812)

Wenns nur flüchtige Werte sein brauchen, eventuell über ClipBoard was zaubern?

Und damit den Inhalt des Benutzers unerwartet zerschießen? :roll:

[KodeZwerg]

Zitat:

Zitat von Luckie (Beitrag 1419826)

Zitat:

Zitat von KodeZwerg (Beitrag 1419812)

Wenns nur flüchtige Werte sein brauchen, eventuell über ClipBoard was zaubern?

Und damit den Inhalt des Benutzers unerwartet zerschießen? :roll:

Ich hatte da eher sowas im Sinne.

Hier copy/paste von da falls der Link tot geht.

Delphi-Quellcode:

// The TClipboard provides easy clipboard access. But what if you
// want to add (several) custom defined items to the clipboard?

// For all actions is the unit Clipboard required.
uses Clipboard;

// First you have to register your own ClipBoard format
// Zuerst registrieren wir unser eigenes ClipBoard Format
const
  MyClipboardFormatStr = 'MyData';

var
  MyClpFormat: integer;

  MyClpFormat := RegisterClipboardFormat(MyClipboardFormatStr);

{ The variable SLMClpFormat will contain a unique format handle for
  your own clipboard format.

  Die Variable SLMClpFormat enthält ein einzigartiges Format Handle
  für unser ClipBoard Format.
}

procedure IncPointer(var p: Pointer; increment: Integer);
begin
  p := PChar(p) + Increment;
end;

// Say you have a data record defined as:
// Definiere zuerst etwa einen solchen Daten Record:
type
  PMyDataRec = ^TMyDataRec;
  TMyDataRec = record
    Name: string[50];
    Value: Integer;
  end;

{ Furthermore let's say the data records are stored in a Listbox
  and shall be copied to a list box.

  Angenommen, die Daten Records sind in einer ListBox gespeichert und
  sollen in eine ListBox kopiert werden.
}

  // Copy like this:
procedure TForm1.CopyItems;
var
  i: integer;
  dh: THandle;
  ic: integer;
  p: Pointer;
  pi: pInteger;
begin
  // get number of items to be copied
  // Die Anzahl zu kopierenden Items
  ic := List1.SelCount;
  dh := GlobalAlloc(GMEM_FIXED or GMEM_ZEROINIT,
    (SizeOf(TMyDataRec) * ic) + SizeOf(Integer));
  { allocate memory for all items plus for a integer variable giving you the number of
    copied items }
  p   := GlobalLock(dh);    { Lock the allocated memory }
  pi  := pInteger(p);
  pi^ := ic;              { write number of items to allocated memory }
  IncPointer(p, SizeOf(Integer)); { increment the pointer behind the written data }
  // You don't have to create an instance of clipboard, this is done automatically

  for i := 1 to List1.Items.Count do { check all items if they are selected }
  begin
    if List1.Items[i - 1].Selected then
    begin
      { This one is selected -> copy it o the clipboard }
      PMyDataRec(p)^ := PMyDataRec(List1.Items[i - 1].Data)^;
      { of course data must point to a TMyDataRec }
      IncPointer(p, SizeOf(TMyDataRec));
      { increment the pointer behind the written data }
    end;
  end;

  // You have now filled the allocated memory with all items that shall be copied.
  // Now you can put them to the clipboard
  Clipboard.Open;  { Open the clipboard will prevent overwriting of so far copied items }
  Clipboard.Clear; { Clear the clipboard first }
  Clipboard.SetAsHandle(MyClpFormat, Dh);  { Copy to clipboard }
  Clipboard.Close;  { finally close the clipboard }
  GlobalUnlock(dh);
  { and unlock the allocate memory. But don't free it, it will be used by the clipboard }

  if ic = 0 then
    GlobalFree(dh);    { You can free it if you haven't copied anything }
end;

// Check first if your items are still available before pasting them from the clipbard

if Clipboard.HasFormat(MyClpFormat) then
begin
  Form1.Paste1.Enabled := True;   { Yes, they are still available }
end;

// And this is, how you paste them after Paste1 is clicked
procedure TMDIForm.Paste1Click(Sender: TObject);
var
  dh: THandle;
  pdr: PSLMDataRec;
  i, ic: integer;
  p: Pointer;
  pi: pInteger;
  li: TListItem;
begin
  if Clipboard.HasFormat(MyClpFormat) then
  // We have already checked, but maybe another application has overwritten the
  // clipboard in between....
  begin
    ClipBoard.Open;       { First open the clipboard again }
    dh := Clipboard.GetAsHandle(MyClpFormat); { Catch the handle to the stored items }
    p  := GlobalLock(dh);  { and lock it }
    pi := pInteger(p);    { The first item is an integer giving the number of items }
    ic := pi^;            { so get the number of items }
    IncPointer(p, SizeOf(Integer)); { increment the pointer behind the read data }
    for i := 1 to ic do   { get all copied items one after another }
    begin
      li   := List1.Items.Add;  { first create a new listbox item }
      pdr  := New(PMyDataRec); { Then create a new pointer to a TMyDataRec }
      pdr^ := PMyDataRec(p)^; { and fill it with data from the clipboard }
      IncPointer(p, SizeOf(TSLMDataRec));
      { increment the pointer behind the written data }

      li.Data    := pdr;  { Set the data pointer of the list item to the new record }
      LI.Caption := pdr^.Name;  { Let the item display the record field "Name" }

      // You can of course add more record fields if the item has subitems:
      LI.SubItems.Add(IntToStr(Value));
    end;    { All data retrieved from clipboard }
    Clipboard.Close;  { Close it }
    GlobalUnlock(dh);
   { and unlock the pointer, but don't free it. This will be done by the clipboard itself,
     if necessary }
  end;
end;

[DieDolly]

So ein Aufwand, obwohl es auch 2 Zeilen absolut tun? :D

[KodeZwerg]

Ja es tut mir leid, ich selbst würde auch eine ini im AppData ablegen und gut ist, aber ein eigenes Clipboard Objekt kann auch ne schöne Spielerei sein, nicht das langeweile aufkommt mal was neues auszuprobieren hehe

[Amenovis]

Lach KodeZwerg du hattest echt super lieb Geduld mit mir beim einkleckern der listview aber das ich das raffe soviel Geduld haben wir beide sicher nicht hahahahaha

[Luckie]

Aus deinem Quelltext:

Delphi-Quellcode:

Clipboard.Clear;

Und damit ist mein Inhalt der Zwischenablage im Nirvana. :roll:

[KodeZwerg]

Zitat:

Zitat von Luckie (Beitrag 1419843)

Aus deinem Quelltext:

Delphi-Quellcode:

Clipboard.Clear;

Und damit ist mein Inhalt der Zwischenablage im Nirvana. :roll:

Ich bin untröstlich das der Quelltext von der Schweizer Garde nicht auf Anhieb alle Probleme löst.

[Luckie]

Es ist einfach die falsche Lösung für das Problem.

[DieDolly]

Zitat:

Zitat von DieDolly (Beitrag 1419798)

Einfacher als in eine Ini-Datei geht wohl nicht.

Vielleicht ist es aber einfacher die hier zu verwenden

Delphi-Quellcode:

Edit1.Text := TFile.ReadAllText(Datei);

TFile.WriteAllText(Datei, Edit1.Text);

:stupid:

[hoika]

Hallo,

Zitat:

Wenn ich nun den Text ändere und das Programm neustarte übernimmt das Editfeld ja wieder den Wert zur Zeit der Compilierung..

Warum wird der Wert überhaupt geändert?
Das ist doch das Grundübel.
Setze das Edit-Feld zur Designzeit auf "" (leer) und gut ist.

[p80286]

Zitat:

Zitat von hoika (Beitrag 1419847)

Hallo,

Zitat:

Wenn ich nun den Text ändere und das Programm neustarte übernimmt das Editfeld ja wieder den Wert zur Zeit der Compilierung..

Warum wird der Wert überhaupt geändert?
Das ist doch das Grundübel.
Setze das Edit-Feld zur Designzeit auf "" (leer) und gut ist.

???
Meiner Meinung nach geht es dem TE darum, daß irgendwann einmal ein Wert geändert wird, und er diesen Wert beim nächsten Programmaufruf wieder erhält, ohne den Wert irgendwo zu speichern.

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1419861)

daß irgendwann einmal ein Wert geändert wird, und er diesen Wert beim nächsten Programmaufruf wieder erhält, ohne den Wert irgendwo zu speichern.

Irgendwo muss er ja gespeichert sein. Wenn nicht in einer DB oder INI-Datei, dann eben in der DFM.
In dem Fall kann ja das Programm entsprechend im Form-Designer geändert und neu compiliert werden. :wink:

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1419862)

Irgendwo muss er ja gespeichert sein. Wenn nicht in einer DB oder INI-Datei, dann eben in der DFM.

Was Du nicht sagst, und da gibt es keine andere Möglichkeit?:shock:


K-H

[KodeZwerg]

Über %Environment% eventuell? Mehr fällt mir nicht ein in Bezug auf "soll nicht in Datei" gespeichert werden.

[DieDolly]

Das ist mal wieder so ein typisches Problem, was eigentlich kein Problem ist.
Aus einer Mücke wird ein Elefant gemacht.

[HolgerX]

Hmm..

Mal eine Zusammenfassung:

Editfeld wird geändert und diese Änderung soll beim nächsten Programmstart wieder mit der Änderung gesetzt werden..


Wenn es sich nur um ein kurzzeitiges schließen mit direktem Neustart handelt, dann geht Clipboard oder Environment Variable.
Diese werden jedoch durch weiteres kopieren oder Neustart des Rechners gelöscht..

Dan gibt es nur die Möglichkeit den Wert auf einem Massenspeichergerät zu speichern und bei Programmstart wieder zu laden.
Ob dieser Massenspeicher nun ein Stick/eine Festplate (lokal)/ oder Cloud (extern) ist, würde hierbei egal sein.
Ob nun in einer DB/INI/Registry/separate Datei würde auch egal sein.

Welches Ziel und welcher Ort hängt davon ab, wie wo und wie das Programm wieder neu gestartet werden würde, bzw. von wem...

[p80286]

Zitat:

Zitat von DieDolly (Beitrag 1419866)

Das ist mal wieder so ein typisches Problem, was eigentlich kein Problem ist.
Aus einer Mücke wird ein Elefant gemacht.

Nö, für den TE ist das ein Problem. Nur hat bisher nur einer klipp und klar geschrieben "ohne Speichern geht das nicht".

Gruß
K-H

[DieDolly]

Zitat:

Aus einer Mücke wird ein Elefant gemacht.

Damit meine ich solche Sachen wie Registry, Clipboard, über Envirement-Variablen und sowas.
Das geht viel einfacher in einem simplen Einzeiler. Ich kann mir kaum vorstellen, dass dieses Programm auf einem hoch-gesichertem System läuft wo sämtliche Schreibrechte verwehrt werden.
Deswegen mein Satz mit der Mücke und dem Elefant.

Diese ganzen Profitipps versperren euch die Sicht auf die einfachen Dinge.

[p80286]

[nearly off Topic]
Nun ja, interessant fände ich ganz pers. das Speichern in der Registry. Wobei es mir nicht um das eigentliche Speichern geht, sondern um das "was ist der korrekte Pfad zu meinen Daten". Zumindest habe ich bisher keine umfassende Erläuterung zur Registry gefunden, die ich dann als "How to" verwenden könnte.
Und darüber Hinaus, was wäre die Alternative unter Android/Linux.

Gruß
K-H

[mkinzler]

Unter HKCU\<Firma>\<Programmname><Sektion>

[Luckie]

Fast: HKCU\Software\<Firma>\<Programmname><Sektion>

[p80286]

:thumb:
Danke!

K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1419881)

Und darüber Hinaus, was wäre die Alternative unter Android/Linux.

In dem Fall würde sich vielleicht TCustomIniFile als Basis anbieten. Für Windows kann man dann eine TRegistryIniFile oder TIniFile Instanz erzeugen (je nachdem, ob man Registry oder Ini-Datei will), während für die anderen Plattformen immer eine TIniFile Instanz zum Einsatz kommt, da denen ja das Konzept einer Registry eher fremd ist.

[Schokohase]

Joar, und zwar so

Delphi-Quellcode:

uses
  System.Win.Registry,
  System.SysUtils;

procedure Test();
var
  ini: TRegIniFile;
begin
  ini := TRegIniFile.Create('Software\Schokohase');
  try
    ini.WriteString('TestApp', '', 'This is the TestApp');
    ini.WriteBool('TestApp\Form1', 'Visible', true);
    ini.WriteInteger('TestApp\Form1', 'Height', 600);
    ini.WriteInteger('TestApp\Form1', 'Width', 800);
  finally
    ini.Free();
  end;
end;

Schreibt in HKCU\Software\Schokohase\TestApp

[KodeZwerg]

Zitat:

Zitat von Schokohase (Beitrag 1419887)

Schreibt in HKCU\Software\TestApp

Wohl eher HKCU\Software\Schokohase, oder?

[Luckie]

Ich gehe mal davon aus das TRegIniFile automatisch in HKCU schreibt.

[KodeZwerg]

Ich meinte, er legt sub-keys in "Software\Schokohase" an, nicht in "Software\TestApp" wie es gesagt wurde.

[Delphi.Narium]

Ja, aber der Wert wurde nicht gesetzt, von daher wird erstmal "irgendwohin" geschrieben, nämlich in den Zweig, der "irgendwo im Inneren von TRegIniFile oder der WinAPI" als Default genommen wird.

Ein setzen von

Delphi-Quellcode:

Ini.RootKey := HKEY_CURRENT_USER;

könnte da Sicherheit schaffen ;-)

[Schokohase]

Zitat:

Zitat von KodeZwerg (Beitrag 1419888)

Zitat:

Zitat von Schokohase (Beitrag 1419887)

Schreibt in HKCU\Software\TestApp

Wohl eher HKCU\Software\Schokohase, oder?

Sag ich doch ... (gut aufgepasst)

[TigerLilly]

Hmmm.

*) Das Programm könnte beim Beenden eine Mail abschicken mit dem Text als Mailbody + beim Starten die Mail abholen + den Mailbody auswerten.

*) Das Programm könnte den Text binär kodieren und in einem Ton kodiert abspielen. Das nimmt man mit dem Handy auf und spielt es beim Programmstart dem Programm vor.

*) Das Programm könnte den Text in einem auf Amazon/eBay zu verkaufenden Artikel verstecken.

*) Das Programm könnte einen Windows-Event erzeugen, den protokollieren lassen + abfragen.

*) Man könnte einen Feed aufsetzen und über den den Text austauschen.

*) Das Programm könnte die DFM Datei manipulieren und vor dem nächsten Start muss das Programm neu kompiliert werden. (Aber das gilt eigentlich nicht.)

*) Man könnte den Text als Zahl kodieren + eine Überweisung mit diesem Betrag tätigen + beim Programmstart auswerten + rückgängig machen.

[KodeZwerg]

Ich krieg mich nicht mehr ein, so viel lustige Kreativität sieht man selten, danke für den Brüller :thumb::thumb::thumb:

[Uwe Raabe]

Zitat:

Zitat von TigerLilly (Beitrag 1419972)

*) Das Programm könnte die DFM Datei manipulieren und vor dem nächsten Start muss das Programm neu kompiliert werden. (Aber das gilt eigentlich nicht.)

Da hätte ich noch eine Variante: Die Änderung in einer Language-Resource ablegen (z.B. <myapp>.DE), die dann beim Programmstart ja automatisch geladen wird und die DFM-Werte der EXE überschreibt. Damit beschränkt sich der Aufwand rein auf das Abspeichern des Wertes. :twisted:

[mkinzler]

Zum Glück ist eine Language Ressource keine Datei. Man könnte diese aber in einem ADS "verstecken" und hat somit quasi keine Datei :stupid: