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

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

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 FreeAndNil(Objekt); statt Objekt.Free; aufzurufen

[Stevie]

Zitat von mkinzler:

Deshalb ist es immer besser FreeAndNil(Objekt); statt 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 von Stevie:

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 von Stevie:

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 von 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.

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.

[geskill]

Zitat von jaenicke:

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.

Stimmt mit dem with hat der Debugger Probleme!
Verstehe aber nicht, warum du die Benutzung so kritisch siehst, ich glaube das ist reine Geschmackssache. Ohne with weiß man zwar ohne groß zu überlegen ganz genau, zu welchem Object etwas gehört, jedoch wird dadurch auch der Code unübersichtlicher und es wirkt aufgebläht. Mit dem with ist Code wesentlich aufgeräumter und man beschränkt sich stärker auf die wesentlichen Teile.
Mir ist schon klar, dass es Probleme geben kann, wenn man die with Anweisungen verschachtelt, da nun einige Methoden überdeckt werden, aber mit geschärftem Blick sieht man dies in der Regel.

[Daniel]

Ich bitte darum, die "With-Diskussion" (so sie denn sein muss), in einem separaten Thema zu führen. Hier passt's streng genommen nicht her.

[stahli]

[FireMonkey]
Die FM-Controls haben eine Eigenschaft "HitTest", mit der man die Controls einfach "mausdurchlässig" machen kann.

Auch gibt es die Eigenschaft "EnableDragHighlight", mit der man den automatischen Rahmen bei DragOver abschalten kann (im Bild das innere Panel).
Optisch ist das nicht schlecht, DragOver und DragDrop wird dennoch behandelt.

Bei verschachtelten Controls (z.B. Styles) wäre es schön, wenn man "HitTestDrop" deaktivieren könnte (z.B. für die SubControls).
Dann würde auf DragOver immer das "MainControl" reagieren, aber auf Mouseover und Klicks könnten ggf. auch die Subcontrols reagieren.

Ich würde das für eine sehr nützliche Funktion halten, die eine sehr viel genauere GUI-Gestaltung ermöglichen würde...
[/FireMonkey]

[Stevie]

Zitat von jaenicke:

Zitat von Stevie:

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.

Ok, falsche Formulierung meinerseits. Ich korrigiere sie wie folgt: FreeAndNil sollte man nur dann nutzen, wenn man auch an irgendeiner anderen Stelle auf Assigned prüft darauf angewiesen ist, dass die Referenz nil ist.