Delphi zählt falsch

[Coder]

Hallo!
ich habe Delphi 3 Pro und möchte einen Algorithmus schreiben, der ein Bild automatisch aus einem TextString heraus generiert.

Doch , wenn ich das Programm ausführe "kann es" manchmal sein [das ist nicht immer],
daß wenn ich den Text im Memo1.text verändere , also noch Zeichen davor schreibe, daß der Ergebnisstring jedes Mal anders aussieht, und Delphi auch derbe Fehlermeldungen [Zugriffsverletzungen] zeigt. Und, man kann es provozieren, wenn man mehrmals nacheinander auf die Buttons drückt.
Weiß jemand, woran das liegt?

Denn "Colord" dürfte sich nicht von Mal zu Mal verändern, da es ja jedes Mal aus EDIT ausgelesen wird.
Nicht aus dem veränderte Memo1.

hab mal den wichtigsten Source in ein extrap Projekt extrahiert [läuft auch in der einfachen Form fehlerhaft] und 2 Bilder raufgeladen [65 kb]
http://rapidshare.de/files-de/366296/inet.zip.html

Passwort ist : board

[sorry, für das beschissene Einrücken, aber ich wollte es original belassen]

ich hoffe, mir kann jemand helfen.

[jbg]

Zitat:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
begin
  Application.Terminate;
end;

Aua.

[omata]

Moin,

sorry das ich das jetzt hier so sagen muss.

Aber, erstmal wieso muss ich das von irgend einer Seite runterladen, dass kann man hier im Forum hinterlegen. Dann wieso muss ich für so einen Sch*** ein Passwort eingeben?

Ein Programm wird nicht mit Application.Terminate beendet, sondern mit Close.

Variablen werden niemals im Public-Teil deklariert. Also ab damit in den Privat-Teil.

Die Hinweise des Compliers solltest du mal lesen!
Dort steht z.B. das pwd nicht initalisiert wird.

Dann schreibst du Length (texi)*2 und greifst auch noch indiziert Texi[i] drauf zu,
kein Wunder, dass da eine Zugriffsverletzung auftritt.

Da du unter Projekt->Optionen, die Bereichsprüfung schon deakiviert hast, zeigt dir Delphi ja auch nicht (immer) die Verletzung an (toll gemacht!)

Also such nicht den Fehler bei Delphi, meisst sitzt der Fehler vor dem Gerät.

Nochmal: sorry, aber da konnte ich mich jetzt nicht zurückhalten.


Thorsten

[Coder]

mhh, weiß nicht, was soll daran falsch sein?
ich glaube nicht daß dort der Fehler liegt.
was gibt es denn besseres?
Close; ?


nein, ich meine... wenn Ihr auf Button 3 oder bei den beiden [button 3 und 1] abwechselnd drückt...
tritt der Fehler auf.

oder: HIER ist der Code:
_______________________________

Delphi-Quellcode:

procedure TForm1.Button3Click(Sender: TObject);
var
pwl,i, Colord_cnt: integer;
ColordString,Colord, Texti : string;
ColorByte : Byte;

begin

Colord := edit1.text;
Colord_cnt:=1;
pwl :=Length (Edit1.Text); <-<-<---<<<< gerade editiert , hinzugefügt
for i := 1 to Length (texi)*2 do
    begin
    Colord_cnt:=Colord_cnt +1;
      if Colord_cnt > pwl then
        begin
           Colord_cnt:= 1;
        end;

Colorbyte:= ord(Colord[Colord_cnt]) ;
Colord[Colord_cnt] :=  chr (Colorbyte+3);

Texi[i] := chr (ord (Texi[i]) xor ord(Colord[Colord_cnt]));
end;

Label1.Caption := Colord;
end;

[SirThornberry]

Bitte delphi-tags setzen, so erkennt man keine einrückung und kann dementsprechend nicht effizient helfen.

[SirThornberry]

das der Fehler nur autritt wenn du abwechselnd die buttons drückst ist zufall. Denn wie schon geschrieben sorgt folgendes eindeutig dafür das außerhalb von dem speicherbereich von "texi" geschrieben wird.

Delphi-Quellcode:

for i := 1 to Length (texi)*2 do 
begin
  [...]
  Texi[i] := chr (ord (Texi[i]) xor ord(Colord[Colord_cnt])); 
end;

Denn wenn "texi" eine länge von "2" hat dann schreibst du bei obiger schleife mit "Texi[i]" mindestens 2 mal außerhalb des speicherbeichs von "texi" (länge(2) * 2 = 4 => du schrebist auf Index 3 und Index 4 obwohl deine Variable von der Länge her nur Index 1 und 2 hat). Dies kann dazu führen das du irgend ein Object von dir im speicher teilweise überschreibst. Und deswegen krachts dann auch wenn du das object ode was auch immer verwenden willst (weil es ja nicht mehr in ordnung ist sondern teilweise mit falschem code überschrieben wurde).

[Coder]

oh, son shit...
Texi(i) << das is der Fehler, der mir nicht aufgefallen ist...
die Länge des Strings aus Edit1 hab ich wohl bedacht.
nur keine Extravariable für die Länge von Memo1.. die nicht ..
Sind Inhalt von Edit1 und Memo1 gleichlang gibts ja auch keie Probleme ...
grrrr
shit 8 Stunden... sitz ich da dran ... 1x gut hingucken hätte mir geholfen...

hoffentlich hab ich da nix wichtiges bei meinem Windows im RAM überschrieben :I
[RegKey [HCU/MSwindows/Curvers/format_C:_when_shutdown = 0x0]
[RegKey [HCU/MSwindows/Curvers/format_C:_when_shutdown = 0x1] -...

(wenn ich mich gleich nach dem Reboot wieder melde, wißt Ihr bescheid :D)

DANKE.

Sorry, wegen der Delphi Tags... das kannte ich nicht.

Sorry, auch für den externen Dateiupload.
ich bin es nicht gewohnt auf boards etwas raufzuladen.
wird meist nicht gern gesehn.
ok, bei 65 kb wird wohl keiner was sagen.
und da ich auch gerade per FTP nicht an meinen server rankam habe ich rapidshare genommen.
leider verwenden die Javascript... [owbohl ich im dort source nichts böeses entdecken konnte]
naja, und mit Passwort dachte ich , sollte dann schon sein.
muß ja außer uns keiner auf den ersten Blick° wissen, was drin ist.

°ok, es gibt zipcracker und "board" steht auch in jedem "Dictionary"

[OT]eigentlich würd ich ja sowieso gerne 7zip verwenden :D mit AES.
Aber leider ist das Format noch nicht weit verbreitet genug. Und die wenigsten wissen, daß man das auch mit der neuesten Winrar [bin registiert, find das einfach gut!] öffnen kann [da sind neue 2 Dlls im Formatverz]
[/OT]

Ach nochwas ... warum darf ich nicht Application.terminate nehmen?
ich dachte, close; wäre nur für Formulare.
und warum nicht im Public teil deklarieren??


Also, dennoch DANKE. :cheers:

[jbg]

Zitat:

Zitat von Coder

warum darf ich nicht Application.terminate nehmen?

Weil Application.Terminate einige Events auslässt, weil es mehr für einen abrupten Programmabbruch gedacht ist.

Zitat:

ich dachte, close; wäre nur für Formulare.

Ist es auch. Nur hat das Hauptformular da eine besondere Rolle. Wenn man Close für das Hauptformular aufruft, wird die Anwendung geloschen und nicht wie bei Application.Terminate abgebrochen.

Zitat:

und warum nicht im Public teil deklarieren??

Das Stichwort heißt Kapselung der Daten. Felder/Attribute gehören grundsätzlich in den private Abschnitt und in ganz seltenen idiologischen Ausnahmen in den protected Abschnitt (vgl. Indy-Komponenten, die dem Prinzip von "wir bieten alles in protected an und private is verboten, da nicht erweiterbar" folgen).

[SirThornberry]

in public werden nur dinge declariert die wirklich public sein sollen, also von anderen Klassen verwendet werden sollen.

[Hansa]

Zitat:

Zitat von jbg

...Felder/Attribute gehören grundsätzlich in den private Abschnitt und in ganz seltenen idiologischen Ausnahmen in den protected Abschnitt ..

Dann wäre ich aber ein ganz seltener Ideologe. 8) Habe mal ein paar Forms durchgeschaut und war selber überrascht : es gibt in den größeren Forms fast nur protected Deklarationen. Und die kamen nach und nach da rein, so daß ich das gar nicht so gemerkt habe. Und zwar weil es gar nicht anders geht.

Zumindest wenn man OOP von Anfang an eingesetzt hat und das OOP-Konzept durchgängig beibehält. Wenn das aber eine ganz seltene Ausnahme sein sollte, na dann gute Nacht, Delphi-"Programmierer". :mrgreen:

[SirThornberry]

@Hansa: Man sollte aber nicht alles in Protected packen sondern nur das was für abgeleitete Klassen wirklich nötig ist. Wenn man zum beispiel einen grafischen Button als Komponente programmiert so braucht man in aller regel nur die Canvas unter Protected lassen (was ja glaub ich schon von je her so ist). Alles andere braucht nicht mehr angerührt werden. Naja, warum schreib ich das überhaupt, so wie sich dein Post anhört bist du einer der wenigen die das Konzept der OOP richtig verstanden haben und auch umsetzen (ich bin leider einer der nicht so ganz konsquenten - ich änder dann wenn ich abgeleitet habe erst die Basisklassen um wenn ich mitbekomme das ich doch auf irgend eine private-variable/methode zugreifen muss)

[jbg]

Zitat:

Zitat von Hansa

Dann wäre ich aber ein ganz seltener Ideologe.

Ich schrieb von Felder/Attribute und nicht von Eigenschaften (property)

Sowas wie

Delphi-Quellcode:

protected
  FMyField: TMyType;
end;

meinte ich.

Delphi-Quellcode:

protected
  property MyField: TMyType read FMyField;
end;

ist natürlich erlaubt :wink:

[IngoD7]

[OFF-Topic]

Zitat:

Zitat von jbg

Zitat:

Zitat von Coder

warum darf ich nicht Application.terminate nehmen?

Weil Application.Terminate einige Events auslässt, weil es mehr für einen abrupten Programmabbruch gedacht ist.

Was durchaus beabsichtigt sein kann. Von einer verbotenen Nutzung im Sinne von "nicht dürfen" kann also keine Rede sein. Allerdings sollte man sich dann auch nicht wundern, wenn z.B. die Form.OnClose-Routine nicht abgearbeitet wird. :wink:

[/OFF-Topic]

[Hansa]

Zitat:

Zitat von jbg

Ich schrieb von Felder/Attribute und nicht von Eigenschaften (property)

Sowas wie

Delphi-Quellcode:

protected
  FMyField: TMyType;
end;

meinte ich.

Was soll den damit sein ? :shock:

Konkretes Beispiel :

Delphi-Quellcode:

  protected
    ArtNr : string;
    ArtGef : boolean;
    VonArtNr,
    BisArtNr : integer;
...
    KommaCols : set of byte;
...

Das ist bei weitem nicht alles. Ungefähr so sieht die class aus, die ich verwende, um einen Artikel zu erfassen. Ob das sich jetzt um den Lagerbestand oder eine Rechnungsposition handelt, das ist völlig egal. Der Artikel muß nur da sein.

Es ist doch wohl schon mal grundlegend, zu wissen, ob ein Artikel vorhanden ist. Ist das nicht der Fall so kann ich eben keinen Lagerbestand usw. abspeichern. Und anderes auch nicht. Die Variable "ArtGef" muß also auch dem Lagerbestand zugänglich sein. Ansonsten müßte sie neu definiert und ausgewertet werden, was die vorhandene Form aber so oder so schon macht. Ergo : Rad neu erfinden und zig-fach verwalten. Es ist schon erschreckend, zu sehen, daß das OOP Konzept so gut wie nirgends berücksichtigt und offensichtlich auch ncht gelehrt wird.

Und wie so was mit private gehen soll, das soll mir erst mal einer sagen. :mrgreen:

[moritz]

So, hier mal mein Kommentar dazu:
1) Was ist an dem Programm so toll, dass man es mit einem Passwort schützen muss?
2) Du pack's JPEG-Dateien... Das ist in etwa so sinnvoll, wie eine ZIP-Datei zweimal zu packen
3) Der Code sollte etwas formatiert sein, sonst kann man da nichts lesen
4) Was soll das Programm machen?

[jbg]

Zitat:

Zitat von Hansa

Und wie so was mit private gehen soll, das soll mir erst mal einer sagen. :mrgreen:

Die vielen Felder in protected sind die "Tippfaule" Variante, die ich zugegebenermaßen auch manchmal verwendet. Man tippt eben nicht gerne viel.

Die (reine) Theorie der Kapselung würde das aber lieber so sehen.

Delphi-Quellcode:

private
    FArtNr : string;
    FArtGef : boolean;
    FVonArtNr,
    FBisArtNr : integer;
...
    FKommaCols : TByteSet;
  protected
    property ArtNr: string read FArtNr write FArtNr;
    property ArtGef: Boolean read FArtGef write FArtGef;
...

Dadurch wäre es nämlich möglich, die Datenstruktur neu zu organisieren, ohne das nach außen etwas verändert wird. (Tritt aber bei End-Anwendungen nicht so häufig auf. Bei Komponentenbibliotheken hingegen sehr oft).

Wobei Leute, die keine Ahnung von Delphi haben, sich hierbei auch Fragen würden, ob das denn wirklich gekapselt ist, da man doch

Delphi-Quellcode:

MyInstance.ArtNr := '1234';

schreiben kann und nicht wie in Java ein

Code:

MyInstance.setArtNr("1234");

nutzt. (habe ich erst kürzlich gehört).

[Robert_G]

Zitat:

Zitat von Hansa

Was soll den damit sein ? :shock:

Konkretes Beispiel :

Delphi-Quellcode:

  protected
    ArtNr : string;
    ArtGef : boolean;
    VonArtNr,
    BisArtNr : integer;
...
    KommaCols : set of byte;
...

Das ist bei weitem nicht alles. Ungefähr so sieht die class aus, die ich verwende, um einen Artikel zu erfassen. Ob das sich jetzt um den Lagerbestand oder eine Rechnungsposition handelt, das ist völlig egal. Der Artikel muß nur da sein.

Gutes Beispiel wie es nicht gehen sollte. :mrgreen:
Warum haben die Nachfahren von Artikel schreibenden Zugriff auf die Artikelnummer? :shock:
Im allgemeinen lasse ich Nachfahren nur dann auf Felder zugreifen, wenn ich es für konsistent halte. (Wobei ich auch dann höchsten den Setter als virtual deklariere ;) )
Denn hast du auf einmal einen falschen Schlüssel geht die Sucherei los. Haben die Nachfahren keinen schriebenden Zugriff, kann er nur beim Erzeugen der Instanz oder in TArticle zersägt worden sein.

Zitat:

Zitat von Hansa

Die Variable "ArtGef" muß also auch dem Lagerbestand zugänglich sein. Ansonsten müßte sie neu definiert und ausgewertet werden, was die vorhandene Form aber so oder so schon macht. Ergo : Rad neu erfinden und zig-fach verwalten.

Wie du unten siehst stellt es kein Problem dar. ;)

Zitat:

Zitat von Hansa

Es ist schon erschreckend, zu sehen, daß das OOP Konzept so gut wie nirgends berücksichtigt und offensichtlich auch ncht gelehrt wird.

Finde ich auch. :P

Zitat:

Zitat von Hansa

Und wie so was mit private gehen soll, das soll mir erst mal einer sagen. :mrgreen:

Bitte schön: ;)

Delphi-Quellcode:

type TArticle = class
private
  fArtNr : string;
...
published
  property ArtNr :string read fArtNr;
...
public constructor Create(const aArtNNr :string);
end;

type TSomeDescendant = class(TArticle)
...
public constructor Create(const: aArtNr: string; aSomeProperty :TSomeType);
...
end;
implementation

constructor TArticle.Create(const: aArtNr: string);
begin
  inherited Create();
  fArtNr := aArtNr;
end;

constructor TSomeDescendant.Create(const: aArtNr: string; aSomeProperty :TSomeType);
begin
  inherited Create(aArtNr);
  fSomeProperty := aSomeProperty;
end;

Wobei published properties nur Sinn machen, wenn man auf RTTI-Funktionen zurückgreifen möchte oder das Delphi-Streaming-System verwendet. (zum Beispiel in der Kombi TReader/TWriter & TCollection oder als persistente Einstellungen im OI).
Im Normalfall sollte public reichen. (Oder halt protected, wenn es nur die Nachfahren sehen sollen)

Zitat:

Wobei Leute, die keine Ahnung von Delphi haben, sich hierbei auch Fragen würden, ob das denn wirklich gekapselt ist, da man doch

Delphi-Quellcode:

MyInstance.ArtNr := '1234';

schreiben kann und nicht wie in Java ein

Zitat:

MyInstance.setArtNr("1234");

nutzt. (habe ich erst kürzlich gehört).

Hihi Java und seine expliziten Properties. :mrgreen: Ohne die wäre Java eine recht hübsche Sache. ;)

[Hansa]

@jbg : verstehe jetzt, was du meinst. 8) Und das in der Tat etwas Ideologie. Ich mache die Felder gleich protected und Du machst sie private, aber brauchst noch zusätzliche protected Zugriffsprozeduren. Bei Komponenten siehts auch wieder anders aus. Ich habe allerdings nur ca. 10 eigene. Zumindest sind soviele da, in eigenem Registerreiter. Die habe ich auch in diesem Stil gemacht. Allerdings kommt das eher von den Beispielen, die ich als Anregung genutzt habe. Und das ist auch wieder ein anderes Thema. Wenn z.B. nur die DCU, oder überhaupt etwas weitergegeben wird, was ableitbar sein soll, dann siehts total anders aus. Bei mir ist das aber egal, weil sowieso nur die EXE raus geht. :mrgreen:

Zitat:

Zitat von Robert_G

Gutes Beispiel wie es nicht gehen sollte. :mrgreen:

Du hast gerade noch gefehlt. :zwinker: Tja, was nicht gehen sollte, das geht aber trotzdem. Manchmal hat die Praxis eben schon ihre Vorzüge vor der Theorie. Und die protected Felder aufzusplitten in private Felder und protected Property-Prozeduren bringt keinen Zusatznutzen. Ich befürchte fast, die Wahrscheinlichkeit ist sogar höher, daß sich ein bloßer Tipfehler schlimmer auswirkt und schlechter ausfindig zu machen ist. Produktiver ist es wohl kaum.

Im Zusammenhang ist auch wieder die Objektablage interressant. Meine protected Felder liegen nämlich auf der Form. Und eine davon abstammende führt eventuell noch was neues ein, muß es aber nicht. Der Rest stammt vom Vorgänger. Wenn das Ganze nun sorgfältig hierarchisch aufgebaut ist, dann sehe ich kein Problem.

[Coder]

1) ich verschlüssel prinzipiell, wenn ich Daten woanders ablege. s.o. 7zip
2) das Zip hatte nur die Aufgabe alle Dateien zusammenzuhalten.
Du möchtest doch nicht jede Datei einzeln herunterladen, oder?
daß jpg schon maximal komprimiert ist (ok, bis auf 1-2% die da noch rauszuholen sind)
3) ich weiß.. ich hatte es aber nicht verändern wollen
3) es erstellt einen String aus dem nachher ein Bild [punkte,farbe] berechnet wird.