Ergebnis der Suchanfrage

• Forum: Object-Pascal / Delphi-Language

  Re: Gemeinsame OnClick - Behandlung

    Delphi
    by choose, 5. Dez 2003
  Was hältst Du von einem Parameter, dem Du die auszusparenden bzw. zu verwendenen Klassen angibst?
  SetPropIfPossibleAndIsInstanceOf(Sender, , 'Width', 200);
  bzw
  SetPropIfPossibleAndIsNotInstanceOf(Sender, , 'Visible', True);
  
  Vielleicht sollte man das wirklich einmal in einer Unit zusammenfassen :gruebel:
• Forum: Object-Pascal / Delphi-Language

  Re: Gemeinsame OnClick - Behandlung

    Delphi
    by choose, 5. Dez 2003
  Hi himitsu,
  
  ich habe meine ad hoc-Lösung ein bisschen überarbeitet
  
  type
  TTypeKinds = set of TTypeKind;
  
  procedure SetPropIfPossible(const AnInstance: TObject;
  const APropName: string; const ANeededTypes: TTypeKinds;
  const AValue: Variant); overload;
• Forum: Object-Pascal / Delphi-Language

  Re: Gemeinsame OnClick - Behandlung

    Delphi
    by choose, 5. Dez 2003
  :D
  
  
  Probleme wird es dann geben, wenn es sich nicht um "Standardeigenschaften" handeln sollte. Hier sollte IMHO eine sichere, wartbare und übersichtliche Lösung gewählt werden.
  Für "die schnelle Nummer zwischendruch" ist die RTTI bei Published Properties aber durchaus eine gute Wahl, zb so (nur mit D7 getestet, ggf gibt es die easy accessors in anderen Versionen nicht in dieser Form)
  
  uses...
• Forum: Object-Pascal / Delphi-Language

  Re: Gemeinsame OnClick - Behandlung

    Delphi
    by choose, 5. Dez 2003
  Ohne Pointer zu programmieren ist also wie Safersex, Bernd, und was sind dann CrackerClasses, Pfui ;)
  
  @Doc F: Weder CrackerClasses noch Konstruckte der Form
  asm
  mov , eax
  end;
  sind Lösungen, die "sicher" funktionieren (obgleich Crackerclasses bedingt auch in D8 funktioneren sollen... *grummel*)
  Ich habe schon Komponenten gesehen, die zwar von TControl erben, die Getter und Setter der...
• Forum: Object-Pascal / Delphi-Language

  Re: Gemeinsame OnClick - Behandlung

    Delphi
    by choose, 5. Dez 2003
  Hi himitsu,
  
  bei selbstgeschriebenen Klassen mit Interfaces, für die "dreckige Lösung" mit RTTI und für den OO-Entwickler mit einem Visitor, lässt sich das Problem ohne n Fallunterscheidungen (die mit der Wahrscheinlichkeit p immer 0<m<=n Fehlerhaben, bei denen die Übersicht gegen 1/n^2 strebt und die Wartbeikeit bei n! liegt ;)) lösen.