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

[jaenicke]

Richtig, denn wenn man tatsächlich etwas initialisieren muss dann kann man das bei Verwendung der Klasse über eine entsprechende Methode.

Wenn man aber die Klasse an sich ändert und die dann an den falschen Stellen verwendet wird... ohje, was für ein Durcheinander, insbesondere in einem Team... finde da mal den Fehler.

[himitsu]

OK, dann versucht z.B. mal die interne StringList des TRichEdit zu kommen und die Bugs zu fixen, welche seit D2009 existieren, ohne die VCL neu zu kompilieren.

Irgendwer hat deren Deklaration nicht öffentlich gemacht.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1108293)

OK, dann versucht z.B. mal die interne StringList des TRichEdit zu kommen und die Bugs zu fixen, welche seit D2009 existieren, ohne die VCL neu zu kompilieren.

Irgendwer hat deren Deklaration nicht öffentlich gemacht.

Dann korrigier ich mich:

Zitat:

Zitat von Stevie (Beitrag 1108289)

Klingt für mich aber eher nach nem Workaround für schlechtes Design einen Bug.

Wieso sollte man also ein Sprach Feature einbauen, um einen Bug zu fixen?! :shock:

Und wo wir von Bug sprechen, um was handelt es sich? (schon im QC eingetragen?)

[stahli]

Das sehe ich ach so. Wenn man schon etwas WÜNSCHT, dann gleich eine VCL2 (statt einer Problemlösung durch die Hintertür).

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1108301)

dann gleich eine VCL2

"be careful what you wish for ..."

[himitsu]

einfaches Beispiel:

Delphi-Quellcode:

RichEdit1.Lines.Clear;
RichEdit1.Lines.Add('fdfdfd');
RichEdit1.Lines.Add('fdfdfd');
RichEdit1.Lines.Add('xx1234567890xx');
//RichEdit1.SelStart := Pos('4567', RichEdit1.Lines.Text) - 1;  // *1
RichEdit1.SelStart := Pos('4567', RichEdit1.Text) - 1;        // *2
RichEdit1.SelLength := Length('4567');

1) hier ist klar, daß leider #13#10 (sLinebreak) rauskommt, obwohl man das leicht ändern könnte.
2) den Schrott hier hat Emba aber absichtlich verbaut und dabei vergessen auch SelStart/SelLength mit umzurechnen

Emba hatte mit der Umstellung auf Unicode auch endlich mal das Richedit-Control upgegradet und nutzt nun nicht mehr die überaltete Version. (von RICHEDIT v2 auf v3 oder war's von 3 auf 4 :gruebel: )
Wie dem auch sei, komischer Weise nutzt diese Komponente intern als Zeilenumbruch die #13 (Mac :shock: ), also dachte Emba sich, es ist mal "schlau" und ersetzt "einfach" die #13 mit sLineBreak, beim Auslesen.
Tja, und nun haben wir den Salat ... pro Zeile verschiebt sich der Index.

Ja, es sind irgendwo mehrere QC-Einträge und auch mehrere DP-Beiträge dazu vorhanden, aber seitens Emba keine wirkliche Reaktion.
Es gibt auch 2-3 "einfache" Lösungen. (die StringList anpassen, aber leider ist der Zugriff darüber langsam und direkt über die WinAPI oder die Indize von SelStart/SelLength umrechnen)


Dis ist mal ein wirklicher Wunschtraum ... daß alle QC-Einträge beantwortet und die Probleme behoben sind.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1108313)

Dis ist mal ein wirklicher Wunschtraum ... daß alle QC-Einträge beantwortet und die Probleme behoben sind.

Manchmal bist du echt naiv. Klar, ebend mal jedes vermeindliche "Fehlverhalten" fixen - ist ja auch total Hupe, ob Programme, die schon immer liefen, plötzlich ihren Dienst versagen, oder ihr Verhalten ändern. Hab schon oft genug erlebt, dass ein übereifriger Entwickler sich gedacht hat "Ui, da is ja nen Fehler, ich beheb den mal" und plötzlich knallts am anderen Ende, weil irgendwer mal vor Urzeiten nen Workaround gebaut hat oder sich auf dieses Verhalten verlassen hat.

Übrigens, Problem solved:

Delphi-Quellcode:

RichEdit1.Lines.Delimiter := #13;
RichEdit1.Lines.StrictDelimiter := True;
RichEdit1.SelStart := Pos('4567', RichEdit1.Lines.DelimitedText) - 1;

[himitsu]

Aber schau lieber nicht nach, was Lines macht.

Bei jedem zugriff auf Lines.Text / Lines.DelimitedText wird Memo/RichEdit erstmal komplett zerlegt.
Im Inneren speichern die den Text zusammenhängens.

Lines ließt nun jede Zeile aus und setzt das wieder zusammen.

Delphi-Quellcode:

for i := 0 to Zeilen - 1 do
  Result := Result + Zeile[i] + Zeilenumbruch;

Was soeine Schleife nun auf den Speicherverbrauch und die Laufzeit für Auswirkungen haben kann/wird, kannst'e dir bestimmt denken?

Hätte Emba nicht oder nur geringfügig (#13 => #10) in RichEdit.Text rumgepfuscht, dann sähe das anders aus, da Memo.Text, im Gegensatz zu Memo.Lines.Text, alles zusammen ausließt.


Hey, würden Fehler schneller behoben und auch mal in älteren Versionen, würden nicht so viele Langzeitbugfixes in den Programmen rumgammeln. :angle:





Gut, am Liebsten hatte ich auch mal das 1-0-Problem der Strings beseitigt, aber sowas wird wohl nie passieren.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1108319)

Was soeine Schleife nun auf den Speicherverbrauch und die Laufzeit für Auswirkungen haben kann/wird, kannst'e dir bestimmt denken?

Ja, unheimlich schlimme, weil man ja bestimmt im Sekundentakt die Markierung in nem RichEdit verändern möchte und das dann tierisch den Speicherverbrauch in die Höhe und die Performance in den Keller treibt... :roll:

Und wer ernsthaft ein Programm für Textverarbeitung schreibt, wo dann mal "große" Dokumente geladen sein könnten, wird bestimmt nicht TRichEdit nutzen...

Zitat:

Zitat von himitsu (Beitrag 1108313)

Wie dem auch sei, komischer Weise nutzt diese Komponente intern als Zeilenumbruch die #13 (Mac :shock: ), also dachte Emba sich, es ist mal "schlau" und ersetzt "einfach" die #13 mit sLineBreak, beim Auslesen.
Tja, und nun haben wir den Salat ... pro Zeile verschiebt sich der Index.

Nicht, dass der Delphi Sourcecode ein Paradebeispiel für clean Code wäre, aber hätten sie es nicht so gemacht, wäre das ein klarer Verstoß gegen das Liskov Substitution Principle gewesen, denn TRichEditStrings ist nunmal von TStrings abgeleitet.

P.S. Übrigens... http://docwiki.embarcadero.com/VCL/d...hEdit.FindText

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1108293)

OK, dann versucht z.B. mal die interne StringList des TRichEdit zu kommen und die Bugs zu fixen, welche seit D2009 existieren, ohne die VCL neu zu kompilieren.

Was hat das jetzt mit dem Wunsch nach Konstruktoren in einem class helper zu tun?`

Alles was man in einem class helper macht, kann man einfach manuell auslösen. Klar musst du das dann bei jedem RichEdit, das du nutzt, aber von der Frage ausgehend, ob es möglich ist, ändert sich doch nichts. :gruebel:

[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:

Zitat von himitsu (Beitrag 1108513)

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. :roll:

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;

:arrow:

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;

:arrow:

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? :roll:

:evil:

[jaenicke]

Zitat:

Zitat von Neutral General (Beitrag 1108609)

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:

Zitat von jaenicke (Beitrag 1108623)

Zitat:

Zitat von Neutral General (Beitrag 1108609)

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 = :kotz:

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.

[stahli]

"Native Transparenz" wäre nicht schlecht.
So dass alle Controls (Panel, Edit etc) den Hintergrund vom Screen (also nicht nur die Farbe vom Parent) übernehmen können.
Technisch sollte das ja möglich sein, ich weiß aber nicht, ob die VCL dafür irgendwelche Voraussetzungen vom Windows brauchen würde.

[himitsu]

Es gibt einwas, das ist nativ Transparent.

TLabel

Den das ist eigentlich keine Komponente, hat nichts mit Windows zu tun und hat keinen eigenen Canvas.
Ist 'ne Delphikomponente, welche sich an die Parentkomponente hängt und sich auf dessen Canvas zeichnet.

[stahli]

Das ist ja das Problem.
Gelegentlich würde man ja gern einmal eine (teil-/halb-)transparente Komponente ÜBER eine andere legen (wie es bei Formularen möglich ist).
Ein Label kann man ja nicht über einem Panel anordnen.

[Memnarch]

@stahli:
Meinste so einen effekt?

http://www.delphipraxis.net/157689-t...kriiert-7.html

Dafür dird eine layered form benutzt. Dort kann ich erst den gesamten inhalt löschen(sodass wirklich nur der Desktop zu sehen ist), und darauf knall ich meine png bilder :)

PS: ja der Dekstop arbeitet ganz normal weiter und das ist auch zu sehen(progressbars, animationen etc)

[stahli]

Gewissermaßen schon, aber innerhalb einer Form.
Ich meine z.B. ein Panel, das statt der Funktionalität von ParentBackground auf Wunsch komplett bzw. teilweise durchsichtig wäre aber sonst alle Fähigkeiten eines Panels hat (ZOrder, MouseEvents, ggf. Focus, SubControls etc). Wenn sich etwas hinter dem Panel ändert, sollte diese Änderung zu sehen sein.

Man kann ja per Regionen Löcher in Panels "stanzen", aber dann existiert ja an der Stelle des Loches kein Panel.

Ein transparentes Panel könnte einige Formularaufbauten vereinfachen.
Auch könnte man ein transparentes Panel über andere Controls legen, das etwas einfärben oder darauf zeichnen und auf einfache Weise Mausereignisse abfangen.

Aber es ist ja bereits eine neue VCL angekündigt... :mrgreen:



PS: Aber Dein SreenSaver ist hübsch - davon mal abgesehen :thumb:

[blackfin]

@Stahli:
In den Billenium Effects ist genau so ein Panel implementiert, nennt sich TEffectsPanel und ist in 256 Stufen transparent und farbig einstellbar. (und noch zig andere Optionen...)
Ich nutze das schon lange für viele Projekte.
Kostet was, aber nicht viel. Man kann von den BE auch andere Sachen für das ein oder andere "Eye Candy" gebrauchen :-D
Kostenlose Trial gibts auch, die geht ohne Einschränkungen, aber nur, wenn die Delphi IDE gerade läuft.
Soll nun keine direkte "Werbung" sein (habe mit denen nichts am Hut), aber ich mag das ein oder andere aus dem Package recht gern :_)

Generell würde sich aber so etwas alternativ doch auch mit Boardmitteln selbst machen lassen?
Idee: Normales Panel ableiten, beim FormRepaint: "Screenshot" von Allem hinter dem Panel machen und mit Alphablending mit dem Panel + dessen Content verrechnen.
Nur das mit dem "wenn sich im Hintergrund was ändert" wird schwieriger. Das kann das TeffectsPanel ohne manuellen Eingriff (Refresh) auch nicht so ganz 100%ig :-D

Edit: zusammengeschmissenen Screenshot von ein paar sich überlagernden, farbigen TEffectsPanels auf einer Delphi-Form und darunter liegenden Controls + Image eingefügt.

[Medium]

Was das angeht, würde ich mir ja eine VCL mit "lookless-controls" für natives Win32/64 wünschen, grob so wie es WPF angerissen hat, aber weniger arbeitsintesiv in der Verwendung. Und mit vorgefertigten Standardsets. Ich bin zwar kein großer Freund von übermäßigem Custom-Look (ein gewisser Standard ist halt doch einfach Benutzerfreundlicher), aber die bestehende VCL ist mittlerweile ja doch etwas angestaubt und unflexibel geworden - das muss man einfach zugeben. Und grad die VCL war mal das Aushängeschild von Delphi, da hätte man sich meiner Meinung nach eine Spur mehr hinter klemmen dürfen.
Es gab ja sogar mal eine Zeit, wo selbst eingefleischte C-Entwickler ihre UIs mit abenteuerlichen Frameworks mit Delphi/VCL bauten, weil es einfach hübscher und komfortabler ging. Wär doch mal wieder was :)

[blackfin]

@Medium: Ganz meine Zustimmung :-D
Ich wünsche mir für Delphi eine DirectX / OpenGL-basierte GUI Library für Anwendungsprogramme...mit allen Standard-Controls...hach..ja..ich weiss, viele "Low-PCs" würden das nicht mögen, aber ich! :-D
Standard-Controls, die man über Shader steuern kann...wäre das nicht geil???? (nein? gut, ich find schon!!! :-D)
Und ja, ich mag dann doch, einen "Custom look" echt gern. Ich bin eigentlich ein bißchen Verfechter davon, dass Standard-Applikationen auch ein wenig mehr wie die Hauptmenüs von Spielen aussehen sollten, aber darüber kann man streiten :) Sehen aber einige Kunden (teilweise sogar grosse AGs) ähnlich.
Ich mag den Brot-und-Butter-Look von Windows-Applikationen nicht! :-D
Generell sollte das ganze API-Zeug der Standard-Controls im ersten Schritt genauso "skinnable" sein wie im Webbrowser mit CSS-Klassen..das wäre schon mal ein grosser Fortschritt.


ja, ich bin doof und ihr könnt mich steinigen

[Memnarch]

@Blackfin: Direct2D seit Win7, gibts glaub ich in XE auch irgendwo beispiele zu.

Und hoffentlich kommt keiner von euch auf den Keks alphablending selbst zu berechnen, dafür gibbet schließlich das hier:

(GDI)AlphaBlend

Damit hab ich auchmal perpixel transparenz für mein Towerdefense genutzt(D2010). Damit kann man sogar unter D7 schöne dinge machen.(icons mit perpixel alpha und son hokuspokus :D)

MFG
Memnarch

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1111770)

"Native Transparenz" wäre nicht schlecht.
So dass alle Controls (Panel, Edit etc) den Hintergrund vom Screen (also nicht nur die Farbe vom Parent) übernehmen können.
Technisch sollte das ja möglich sein, ich weiß aber nicht, ob die VCL dafür irgendwelche Voraussetzungen vom Windows brauchen würde.

TransparentColor und TransparentColorValue vom Form setzen und schon läufts. (wobei man dann durch das Form hindurch klicken kann an den "transparenten" Stellen)

[Memnarch]

@Stevie: Ja aber er sprach auch irgendwo von PixelAlpha, und nur eine Farbe setzen zu können erfüllt das nicht ganz.

[geskill]

Wenn man dem was ich gerade lese glaube schenken kann, kommt XE2 am 15. September...

https://forums.embarcadero.com/threa...ssageID=370581

Dort im EDN mal auf den Link zu der Komponente klicken und ganz unten auf der Seite steht:

Zitat:

The library is scheduled to be available September 15th 2011 together with the release of Delphi/C++Builder 2012.

[jaenicke]

Zeitlich würde es ja passen, aber ich bezweifle, dass die Veröffentlichung des Datums dort abgesprochen war. :D

[himitsu]

Beim XE Starter beschweren sich doch Welche, daß es einige Debugmöglichkeiten nicht gibt, wie z.B. dieses Lokale Variablen oder das Anzeigen des Wertes, wenn man mit der Maus über dem Variablennamen steht.

Find ich jetzut nicht wirklich schlimm, denn dieser Schrott funktioniert nicht immer.
Vorallem bei der Arbeit mit Packages dreht es gerne mal durch.

OK, Oftmals heißt es nur "kann nicht aufgelöst werden", aber wenn der Schrott stattdessen falsche werte anzeigt, dann steckt man richtig in der Scheiße.
Ich versuche seit einer Weile rauszufinden, warum eine Variable auf NIL steht (laut Debugger) und was stellt sich raus? Nix mit NIL, das Objekt ist drin, jedenfalls menn man sich dort mal ein IF Assigned reinbaut.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1112355)

Ich versuche seit einer Weile rauszufinden, warum eine Variable auf NIL steht (laut Debugger) und was stellt sich raus? Nix mit NIL, das Objekt ist drin, jedenfalls menn man sich dort mal ein IF Assigned reinbaut.

Assigned heißt noch lange nicht, dass dort ein Object drin steht sondern nur, dass es einen anderen Wert als nil hat.

[mkinzler]

Deshalb ist es immer besser

Delphi-Quellcode:

FreeAndNil(Objekt);

statt

Delphi-Quellcode:

Objekt.Free;

aufzurufen

[himitsu]

Das Objekt ist schon korrekt da (nachfolgender Code arbeitet soweit richtig, bis auf einen fehlerhaften Teil) und die Variable ist ungleich nil, aber der Debugger meint die wäre nil.


[add] Variable = Feld in einem Objekt ... genauer gesagt ist es die "Variable", welche Delphi anlegt, wenn man ein Objekt auf eine Form pappt.
(mit Erstellen/Freigabe hab ich da nix zu tun)

[Stevie]

Zitat:

Zitat von mkinzler (Beitrag 1112358)

Deshalb ist es immer besser

Delphi-Quellcode:

FreeAndNil(Objekt);

statt

Delphi-Quellcode:

Objekt.Free;

aufzurufen

Sehe ich nicht so, FreeAndNil sollte man nur dann nutzen, wenn man auch an irgendeiner anderen Stelle auf Assigned prüft. Genau solche Aussagen führen dazu, dass plötzlich überall FreeAndNil gemacht wird, anstatt Free aufzurufen.

[jbg]

Zitat:

Zitat von Stevie (Beitrag 1112364)

Sehe ich nicht so, FreeAndNil sollte man nur dann nutzen, wenn man auch an irgendeiner anderen Stelle auf Assigned prüft. Genau solche Aussagen führen dazu, dass plötzlich überall FreeAndNil gemacht wird, anstatt Free aufzurufen.

Und FreeAndNil bringt nichts wenn eine andere Variable auch auf das Objekt verweist. Dann ist zwar A nil aber B nicht.

[jaenicke]

Zitat:

Zitat von Stevie (Beitrag 1112364)

Sehe ich nicht so, FreeAndNil sollte man nur dann nutzen, wenn man auch an irgendeiner anderen Stelle auf Assigned prüft.

Das ist IMHO Blödsinn, denn es erschwert das Debuggen enorm, wenn aus irgendeinem Grund hinterher noch auf ein freigegebenes Objekt zugegriffen wird. Ja, klar, darf nicht sein, aber es passiert eben doch mal.

Die paar CPU-Zyklen mehr für FreeAndNil sind in der Regel nicht schlimm. Aber wenn man danach noch auf im Destruktor eines Objekts schon freigegebene Objekte zugreift, bekommt man eine Zugriffsverletzung an Adresse Null statt irgendwo im Speicher, merkt also sofort, dass da ein Objekt nicht (mehr) initialisiert ist.

Hier muss man sich eben entscheiden was einem wichtiger ist.

Zitat:

Zitat von himitsu (Beitrag 1112355)

Beim XE Starter beschweren sich doch Welche, daß es einige Debugmöglichkeiten nicht gibt, wie z.B. dieses Lokale Variablen oder das Anzeigen des Wertes, wenn man mit der Maus über dem Variablennamen steht.

Find ich jetzut nicht wirklich schlimm, denn dieser Schrott funktioniert nicht immer.

Bei mir funktioniert es nur so gut wie ausschließlich bei with nicht. Und wer das nutzt ist eh selbst schuld. An anderen Stellen habe ich das Problem nur äußerst selten.