Hinweis unterdrücken "Auf x zugewiesener Wert wird niemals benutzt"

[Sir Rufo]

Zitat:

Zitat von Union (Beitrag 1260989)

Im OP steht doch was von Delphi 7. Gab's da schon class vars, functions und properties?

Im Profil des TE steht was von XE2 (dafür habe ich mich entschieden ;))

[himitsu]

Selbst wenn D7:
- Class-Functions gab es definitiv schon
- Class-Var bin ich nicht mehr sicher, aber ich glaub schon und wenn doch nicht, dann kann man das auch anders lösen (z.B. globale Variable in der Implementation)

Gab es nicht ein Feature-Request von mir, wo ich mir wünschte, daß dieses standardmäßig mit dem Delphi aus dem Profil gefüllt wird, oder wo standardmäßig "nichts" da ausgewählt ist?

[Der schöne Günther]

Weniger zur Technik, sondern zur Philosophie:

Zitat:

Zitat von Sir Rufo (Beitrag 1260987)

Hier eine Variante ohne diese Abhängigkeiten und Überflüssiges (z.B.

Delphi-Quellcode:

IWaitCursor

) und vor allem auch kaskadierbar

Kritik soll es nicht sein (ist ja technisch einwandfrei, Daumen hoch auf für das

Delphi-Quellcode:

[weak]

!), aber ich finde grade bei Dingen wie etwas, das in seinem Konstruktor und Destruktor aktiv das Gesamtbild des Systems verändert es nicht angebracht, das automatisch ablaufen zu lassen wenn es out of scope geht.

Habe ich ein

Delphi-Quellcode:

procedure aufwändigeAufgabe();
begin
   // Schritt 1
   TWaitCursor.Show();
   doStuff();
   doEvenMoreStuff();
   
   // Schritt 2
   transferMoney();
   logStuff();
end;

und jemand spaltet mir das, ohne es besser zu wissen in

Delphi-Quellcode:

procedure aufwändigeAufgabe();
begin
   schritt1();
   schritt2();
end;

procedure schritt1();
begin
   TWaitCursor.Show();
   doStuff();
   doEvenMoreStuff();
end;

[...]

auf, ist das Stundenglas nur noch für Schritt 1 zu sehen. Ja, hätte Refactor-Man es richtig gemacht, hätte er es in

Delphi-Quellcode:

aufwändigeAufgabe()

gelassen. Aber ich finde den Fehler kann man zu einfach machen.


Ich packe gerne Dinge wie eine lokale

Delphi-Quellcode:

TStringList

in eine interface-referenzierte Tonne um mir den try..finally-Block für das Aufräumen zu sparen, aber grade im Fall mit dem Cursor wäre mein persönlicher Geschmack wirklich weiterhin ein waschechter try..finally-Block. Da sieht man auch auf den ersten Blick was man hat- Ohne zu wissen, was sich hinter den

Delphi-Quellcode:

TWaitCursor

-Kulissen abspielt.

[Dejan Vu]

Unabhängig davon könnte man dem TE -da die Frage schon beantwortet wurde- den Tipp geben, hier keine Klasse zu erzeugen, sondern eher einen kleinen UI-Controller, der das übernimmt. Da Delphi das Paradigma 'Wer Dreck macht, muss aufräumen' vorgibt (Create/Free, Begin/EndUpdate usw.) sollte man das imho hier auch bewusst so umsetzen:

Delphi-Quellcode:

...
  UIController.BeginWaitCursor;
  Try
    DoFoo();
    DoBar();
    UIController.BeginSQLWaitCursor;
    Try
      DoDatabaseStuff();
    Finally
      UIController.EndWaitCursor;
    End;
    DoEvenMoreStuff();
  Finally
    UIController.EndWaitCursor;
  End;
...

Und wenn Refactor-Man jetzt loslegt, muss er ja die Try-Finally-Blöcke zusammen lassen.

Es dürfte in aktuellen Delphis auch mit Lambda-Ausdrücken gehen...

Delphi-Quellcode:

Procedure WaitCursor (a : Action); // Oder wie das auch immer deklariert wird
begin
  oldCursor := Screen.Cursor;
  Screen.Cursor := clWait;
  try
    Action();
  finally
    Screen.Cursor := oldCursor;
  End
End;

Da jetzt gerade ein Interface zu verwenden, erscheint mir etwas unglücklich.

[Sir Rufo]

@Dejan Vu

Wenn es danach geht, muss man die gesamte Vorgehensweise in Frage stellen.

Denn Sinn macht das hier nur, wenn der echte Code in einem Thread gestartet wird (oder - igitt - mit

Delphi-Quellcode:

Application.ProcessMessages

rumhantiert wird), ansonsten sieht man davon eher recht wenig (z.B. das Setzen des TrafficLights im Ausgangsbeitrag), da der MainThread blockiert ist.

Wenn das aber in einem Thread erfolgt, dann wird der Cursor viel zu früh wieder zurück gesetzt.

[p80286]

Hallo zusammen,

mir ist schon des öfteren mal eine Konstruktion wie

Delphi-Quellcode:

Myclass.Create;
Myclass.Machwas;

über den Weg gelaufen.

Meiner Meinung nach richtig wäre

Delphi-Quellcode:

Wert:=Myclass.Create;
Wert.Machwas;
Wert.Free;

Da erstere Version auch funktioniert (?) könntet Ihr mich einmal aufklären was dahinter steckt?

Gruß
K-H

[mkinzler]

Es ist ein Konstruktoraufruf ohne das die zurückgegeben Referenz in einer Variable gespeichert wird

[himitsu]

Zitat:

Delphi-Quellcode:

Myclass.xxx

Du meinst doch bestimmt TMyClass?

Nja, das ist im Prinzip ein

Delphi-Quellcode:

procedure ShowWaitCursor;

(ohne Klasse), nur daß man den Code aufgeräumt hat und es in der zugehörigen Klasse positionierte.


Und nur weil man es ohne explizite Referenz nutzen kann

Delphi-Quellcode:

begin
  TWaitCursor.Show;  // oder als einfache Funktion "ShowWaitCursor;"
  ...
end;

verbietet es keiner, wenn man in Sonderfällen dennoch eine Referenz verwendet.

z.B.:

Delphi-Quellcode:

begin
  X := TWaitCursor.Show;
  try
    ...
  finally
    X := nil;  // oder X.Hide;
  end;
  ...
end;

[mkinzler]

Falls ohne T, dann wird der Konstruktor einfach als normle Methode auf eine viorhandene Instanz angewendet.

[Sir Rufo]

Wenn

Delphi-Quellcode:

MyClass

ein Klassentyp ist und dann muss

Delphi-Quellcode:

MyClass.MachWas

eine

Delphi-Quellcode:

class procedure

sein.

Daraus folgt weiterhin, dass mit

Delphi-Quellcode:

MyClass.Create;

ein Speicherleck erzeugt wird.

Wenn

Delphi-Quellcode:

MyClass : TMyClass;

ist (Instanz-Variable), dann wird mit

Delphi-Quellcode:

MyClass.Create;

der

Delphi-Quellcode:

constructor

nochmals durchlaufen ohne eine weitere Instanz zu erzeugen. Dazu muss aber

Delphi-Quellcode:

MyClass

schon mit einer gültigen Instanz belegt sein.

So aus dem Kontext herausgerissen, kann man dazu also herzlich wenig sagen, ausser im Nebel herumstochern.

Zitat:

Zitat von mkinzler (Beitrag 1261009)

Falls ohne T, dann wird der Konstruktor einfach als normle Methode auf eine viorhandene Instanz angewendet.

Das T ist nicht zwingend vorgeschrieben, aber sehr empfehlenswert