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

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

[geskill]

Gerade bisschen verträumt am Programmieren da passiert doch glatt sowas:

FIcon := TIcon.Create.Handle := GetIconHandle;

Erst als der Compiler meckerte habe ich den Fehler gemerkt. jaja

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

[himitsu]

Das Schönste wäre ja, wenn Emba eine "ältere" Version kostenfrei abgeben würde.

Sobald z.B. XE2 rauskommt, könnte man doch eine "nicht upgradberechtigte", "nicht kommerziell nutzbare" und "leicht abgespeckte Proffessional ohne Quellcodes" freigeben?

Quasi grob mit den Beschränkungen vom Starter
und dafür beim Starter die schlimmsten Beschränkungen "beheben", beim Debuggen und in der Codevervollständigung (welches alles ja selbst im D7 Personal noch ging).


Und nein, nicht für mich ... IMHO ist alles unterhalb einer Prof (also Starter) nicht nutzbar.
(abgesehn von der subjektiv empfundenen IDE-Stabilität war selbst TDE noch um längen besser "nutzbar")