Träume, Wünsche und Wahnvorstellungen...

[mkinzler]

Ein Class-Helper greift auch nicht in das Vererbungsschema ein. So wie du es wünschtst müsste er das aber.

[himitsu]

An der Vererbung wollte ich doch auch garnichts verändert haben?

Nur eben einen automatisch Aufruf, bei den grundlegenden Funktionen eines Objektes. (Freigeben und Erstellen)

Aber wenn man unbedingt meint damit würde die Vererbung verändert, dann hpchstens so, daß noch eine Ebene ganz hinten angehängt wird, egal wie weit die entsprechende Klasse noch abgeleitet wurde.
Quasi so'ne Art Late Binding, wie es andere Sprachen können.


Zum FindText: Das Pos war nur drin, um zu Zeigen, daß sich die Position unterscheidet und ich mich nicht verzählt hab.

[Stevie]

Zitat von himitsu:

Zum FindText: Das Pos war nur drin, um zu Zeigen, daß sich die Position unterscheidet und ich mich nicht verzählt hab.

Und genau deshalb gibt es FindText. Gibt übrigens auch nen Thread im Emba Forum dazu.

[himitsu]

Wenn ich jetzt noch nicht weiß, was ich suche, dann lese ich mir also den Text aus, parse ihn
und dann nehme ich das Geparste und suche es über FindText nochmal, obwohl ich ja eigentlich schon weiß wo er liegt (welche allerdings nicht ganz stimmt) ?

Ja, es gibt gute Gründe, warum es z.B. keinen delphieigenen Syntaxhighlighter gibt, weil da nichts ordentlich funktioniert.

PS: FindText (EM_FINDTEXT) gibt es nicht, weil Emba so blöde den Text verändert.


[add]
Ups, FindText findet ja doch nichts?

Code:

abc[#13#10]12345[#13#10]67890
abc[#13#10]12345[#13#10]67890[#13#10]
abc[#13#10]12345[#13#10]67890
45[#13#10]67
45[#13#10]67
-1
-1
7

abc[#13]12345[#13]67890
abc[#13#10]12345[#13#10]67890[#13#10]
abc[#13#10]12345[#13#10]67890
45[#13#10]67
45[#13#10]67
-1
-1
7

Delphi-Quellcode:

procedure TForm2.FormCreate(Sender: TObject);
var
  S: String;
begin
  S := 'abc' + sLineBreak + '12345' + sLineBreak + '67890';
  Memo1.Lines.Add(StringReplace(S, #13#10, '[#13#10]', [rfReplaceAll]));
  RichEdit1.Text := S;

  S := RichEdit1.Lines.Text;
  Memo1.Lines.Add(StringReplace(S, #13#10, '[#13#10]', [rfReplaceAll]));

  S := RichEdit1.Text;
  Memo1.Lines.Add(StringReplace(S, #13#10, '[#13#10]', [rfReplaceAll]));

  S := Copy(RichEdit1.Lines.Text, 9, 6);
  Memo1.Lines.Add(StringReplace(S, #13#10, '[#13#10]', [rfReplaceAll]));

  S := Copy(RichEdit1.Text, 9, 6);
  Memo1.Lines.Add(StringReplace(S, #13#10, '[#13#10]', [rfReplaceAll]));

  S := Copy(RichEdit1.Text, 9, 6);
  Memo1.Lines.Add(IntToStr(RichEdit1.FindText(S, 0, Length(RichEdit1.Text), [])));

  S := '45' + sLineBreak + '67';
  Memo1.Lines.Add(IntToStr(RichEdit1.FindText(S, 0, Length(RichEdit1.Text), [])));

  S := '45'#13'67';
  Memo1.Lines.Add(IntToStr(RichEdit1.FindText(S, 0, Length(RichEdit1.Text), [])));



  Memo1.Lines.Add('');



  S := 'abc'#13'12345'#13'67890';
  Memo1.Lines.Add(StringReplace(S, #13, '[#13]', [rfReplaceAll]));
  RichEdit1.Text := S;

  S := RichEdit1.Lines.Text;
  Memo1.Lines.Add(StringReplace(S, #13#10, '[#13#10]', [rfReplaceAll]));

  S := RichEdit1.Text;
  Memo1.Lines.Add(StringReplace(S, #13#10, '[#13#10]', [rfReplaceAll]));

  S := Copy(RichEdit1.Lines.Text, 9, 6);
  Memo1.Lines.Add(StringReplace(S, #13#10, '[#13#10]', [rfReplaceAll]));

  S := Copy(RichEdit1.Text, 9, 6);
  Memo1.Lines.Add(StringReplace(S, #13#10, '[#13#10]', [rfReplaceAll]));

  S := Copy(RichEdit1.Text, 9, 6);
  Memo1.Lines.Add(IntToStr(RichEdit1.FindText(S, 0, Length(RichEdit1.Text), [])));

  S := '45' + sLineBreak + '67';
  Memo1.Lines.Add(IntToStr(RichEdit1.FindText(S, 0, Length(RichEdit1.Text), [])));

  S := '45'#13'67';
  Memo1.Lines.Add(IntToStr(RichEdit1.FindText(S, 0, Length(RichEdit1.Text), [])));
end;

Entweder man ändert alle Schnittstellen oder läßt es,
denn so ist ja nix mehr Kompatibel zueinander.


Bzw., hätte man alles so gelassen ,wie es war, dann wäre jetzt .Text, .FindText, .SelStart, .SelLength und .SelText zwar mit #13, aber immerhin kompatibel zueinander,
wärend .Lines und vorallem .Lines.Text dennoch die #13#10 (sLineBreak) hätte.

[Stevie]

Beschwer dich halt bei MS, die haben das im RichEdit 2.0 geändert. Das Problem liegt in der WinAPI, denn WM_GETTEXT, was für die Property Text benutzt wird, liefert #13#10 als Zeilenumbruch zurück, aber die EM_* Messages arbeiten mit #13. Wenn dir das Verhalten nicht passt, überschreib die Property und schreib den Getter um und nutz EM_GETTEXTEX mit GT_DEFAULT als Flag.

[himitsu]

Ist ja nicht so, daß es keine anderen Wege gäbe, als den Text nachträglich zu verändern, aber das dann nichtmal durchgängig überall zu machen.
Wie gesagt, .Text und .SelText unangetastet zu lassen, oder höchsten die #13 durch 'ne #10 ersetzt (mit einem Linuxzeilenumgruch kommen die Meisten doch wohl noch zurecht? ) wäre doch gegangen?
Wenn es jetzt keine neue VCL gäbe und sich da eh viel ändern würde, hätte ich nach inzwischen 2 weiteren Delphiversionen, aber eh keine Hoffnung mehr, daß sich da jemals was dran ändern könnte.

Aber nja, Wunschträume müssen/werden ja eh nicht unbedingt in Erfüllung gehen.

[Neutral General]

Hallo,

Habe nicht mitgelesen in letzter Zeit und ich weiß auch nicht obs hier 100%ig reinpasst, aber das muss ich jetzt mal grad loswerden:

Delphi-Quellcode:

TItem= class
end;

TKlasse<T: TItem> = class
private
  FItems: TObjectList<T>;
end;

Zitat:

[DCC Fehler]E2511 Typparameter 'T' muss ein Klassentyp sein

Delphi-Quellcode:

TItem= class
end;

TKlasse<T: TItem, class> = class
private
  FItems: TObjectList<T>;
end;

Zitat:

[DCC Fehler] E2552 CLASS- oder RECORD-Einschränkung und Klassentypeinschränkung dürfen nicht zusammen angegeben werden

Ich WÜNSCHE mir, dass dieser Unsinn behoben wird!
Wieso akzeptiert/merkt Delphi nicht, dass "T: TItem" (indirekt) bedeutet, dass T ein Klassentyp ist?

[jaenicke]

Zitat von Neutral General:

Ich WÜNSCHE mir, dass dieser Unsinn behoben wird!
Wieso akzeptiert/merkt Delphi nicht, dass "T: TItem" (indirekt) bedeutet, dass T ein Klassentyp ist?

Das ist in Delphi XE bereits behoben, dort kompiliert der erste Code problemlos.

[Neutral General]

Zitat von jaenicke:

Zitat von Neutral General:

Ich WÜNSCHE mir, dass dieser Unsinn behoben wird!
Wieso akzeptiert/merkt Delphi nicht, dass "T: TItem" (indirekt) bedeutet, dass T ein Klassentyp ist?

Das ist in Delphi XE bereits behoben, dort kompiliert der erste Code problemlos.

Oha, gut zu wissen
Ärgere mich jetzt schon mindestens das 2. mal ziemlich über dieses Verhalten (D2009)

[Stevie]

Generics vor Delphi XE =

Was mir mal wieder auffällt: Warum scheint eigentlich kaum einer QC zu benutzen? Da kann man nachlesen, welche Bugs wann gefixt wurden oder ob der Bug, den man gerade entdeckt hat, schon bekannt ist. Und nicht selten gibt es auch Zusatzinfos dazu, warum irgendetwas nicht gefixt wird und/oder by design dieses oder jenes Verhalten hat. Und im Zweifel mal den Bug eintragen, damit er auch irgendwann mal gefixt wird und man sich nicht die nächsten X Jahre weiter drüber ärgert. Jaja, manche Bugs stehen schon jahrelang drin - aber die, die garnicht reported werden, werden noch unwahrscheinlicher gefixt.