[XE2] Live Bindings

[mquadrat]

Hallo zusammen,

gibt es irgendwo eine halbwegs sinnvolle Dokumentation der Live-Bindings? Die Dokumentation im docwiki von Embarcadero ist - vorsichtig ausgedrückt - arg übersichtlich. Zu TBindList beschränkt sich die Doku auf einen Satz "TBindList and TBindGridList are used to populate a list or grid.". Da wäre ich persönlich nie drauf gekommen. :roll: In sämtlichen Samples (die ich dank docwiki und anschließendem SVN Update des Samples Ordner gefunden habe) wird das immer in Verbindung mit TBindScopeDB genutzt. Da ich nun aber keine Datasets verwende, wollte ich schauen ob ich da nicht auch TBindScope verwenden kann. Die Hilfe hilft nicht wirklich weiter, statt dessen wird statt gar keinem Text lieber mal die Beschreibung von TComponent angezeigt. Bleibt also der Blick in den Source-Code.

Und damit komme ich zur eigentlichen Frage: Hab ich was übersehen oder kann ich via Live-Binding keine TObjectList<T> an VCL-Controls binden?

[Union]

Schau mal hier und da

[mquadrat]

Der Post von Stevie (Delphi Sorcery) bezieht sich auf das DSharp-Databinding. Ich versuche mich nur gerade zwischen Live-Bindings (Vorteil: "offiziell", Expression-Engine) und DSharp (Vorteil: näher an dem was ich eigentlich suche) zu entscheiden ;)

Ich muss aber beim Live-Binding doch den Scope angeben. Und da finde ich nicht wirklich was an Doku. Also beispielsweise: Welche Interfaces muss die Listenklasse erfüllen etc.

[Stevie]

Bezüglich der Expression Engine - DSharp Bindings werden in Zukunft (soom (tm)) eine Integration mit DWS bekommen.

[mquadrat]

Nice. Dann wäre das ja auch geklärt 8-)

[Stevie]

Hab gerade eine erste Version commited - designtime Unterstützung gibt's noch keine.

Daher muss man vorerst noch einiges im Code machen. In zukünftigen Versionen wird man es ähnlich wie bei den LiveBindings im Designer einstellen können.

Hier ein kurzer Beispiel Code:

Delphi-Quellcode:

uses
  DSharp.Core.DataConversion.Expressions,
  DSharp.DelphiWebScript.Expression;

procedure TForm1.FormCreate(Sender: TObject);
var
  bind: TBinding;
  conv: TExpressionConverter;
  expr: TDelphiWebScriptExpression;
begin
  conv := TExpressionConverter.Create;
  expr := TDelphiWebScriptExpression.Create;
  expr.Text := 'UpperCase(Edit1.Text)';
  expr.BindObject(Edit1);
  conv.TargetToSourceExpression := expr;
  bind := TBinding.Create(Label1, 'Caption', Edit1, 'Text', bmOneWayToSource, conv);
end;

[Elvis]

Stevie, wie löst du das Dependency-Tacking?
Ich meine, wenn mein Ausdruck von 3 Properties eines Objektes und 2 weiteren eines anderen abhängt, müsste sie ja dann neu evaluiert werden, wenn sich mind. eine davon ändert. (In deinem Fall der Text von einer TextBox)
Und das auch noch mit einer Verzögerung von X Millisekunden. Sodass du nur ein Refresh machst, wenn sich 10 Eigenschaften ändern.

Databinding ohne autom. nur das zu aktualisieren, was auch geändert werden muss, bringt glaube ich für komplexe Systeme nicht viel bis gar nix.
Die Perf-Kosten immer alles zu aktualisieren, oder der Verwaltungsaufwand um zu entscheiden was wann aktualisiert werden muss, würde ja den Aufwand eines Projektes mind. auf die Ebene bringen, die man ohne DataBinding hätte.
In Delphi sollte man sich ja in die Published-Properties klinken können, wenn ich mich nicht irre. Die Frage ist nur, ob du alle lesenden Zugriffe bemerkst.
Mir fällt da gerade was ein, aber da würde ich dich dann im jeweiligen DataBinding-Thread zu nerven. ;-)

[Stevie]

Für das Aktualisieren der Bindings ist das INotifyPropertyChanged interface zuständig. Wenn ein an das Binding angeschlossenes Object (Source oder Target) dieses interface implementiert klinkt sich das Binding dort ein. Bei allen allen Änderungen musst du das Aktualisieren manuell antriggern. Für die ScriptExpressions gibt es bisher garkeinen Automatismus - das wäre auch extrem schwierig, weil ich eigentlich ja nur ein Delphi Object in das Script bekannt mache. Damit kannst du im Script eigentlich nahezu alles anstellen, was du willst (und soweit die RTTI reicht, über die es dort angesprochen wird - mehr Infos dazu wird Eric Grange wissen). D.h. woher soll die Delphi Seite wissen, ob und wann es was triggern muss, da es ja nix vom Inhalt des Scripts kennt. Wenn man lustig sein will, kann man die Script Expressions auch für seine komplette Business Logik nutzen.

Verzögerte Aktualisierung ist nicht unterstützt - halte ich auch bisher nicht für notwendig. Bindings sind für den Transport von Informationen aus der GUI in andere Layer. Da sollten keine großartigen Berechnungen durchgeführt werden. Und falls das doch notwendig ist, gibt es immer noch die Möglichkeit, den UpdateTrigger des Bindings auf LostFocus oder Explicit zu setzen.

In dem Beispiel, was ich oben gepostet habe, triggert also das Binding immer, wenn ich im Edit etwas ändere. Ob die Script expression etwas komplett anderes in das Label schreibt, was überhaupt nix mit dem Edit1.Text zu tun hat, ist dann eine andere Sache und es wird auch nicht getriggert, wenn sich irgendwas im Script verwendetes ändert.

[mquadrat]

Hauptsächlich wird das ja denke ich auch für die Formatierungen oder simple Wertableitungen verwendet werden.

[Stevie]

Zitat:

Zitat von mquadrat (Beitrag 1126746)

Hauptsächlich wird das ja denke ich auch für die Formatierungen oder simple Wertableitungen verwendet werden.

Richtig. Dich hält aber trotzdem nix davon ab, alle Möglichkeiten von DWS (und das sind nicht wenige) auszuschöpfen und da nen Riesenscript an son Binding zu klemmen. Aber um die richtigen Timings und Trigger musst du dich dann selber kümmern.

[neo4a]

Zitat:

Zitat von Stevie (Beitrag 1126392)

Für das Aktualisieren der Bindings ist das INotifyPropertyChanged interface zuständig. Wenn ein an das Binding angeschlossenes Object (Source oder Target) dieses interface implementiert klinkt sich das Binding dort ein.

Das Objekt muss aber mindestens so

Delphi-Quellcode:

class(TInterfacedPersistent, INotifyPropertyChanged)

deklariert sein, TInterfacedObject z.B. gibt einen RTTI- Fehler.

[Stevie]

Zitat:

Zitat von neo4a (Beitrag 1126800)

Zitat:

Zitat von Stevie (Beitrag 1126392)

Für das Aktualisieren der Bindings ist das INotifyPropertyChanged interface zuständig. Wenn ein an das Binding angeschlossenes Object (Source oder Target) dieses interface implementiert klinkt sich das Binding dort ein.

Das Objekt muss aber mindestens so

Delphi-Quellcode:

class(TInterfacedPersistent, INotifyPropertyChanged)

deklariert sein, TInterfacedObject z.B. gibt einen RTTI- Fehler.

Logisch, weil die Referenzzählung dir dann dazwischen haut. Dafür gibts TPropertyChangedBase in der DSharp.Core.PropertyChangedBase.pas

[neo4a]

Zitat:

Zitat von Stevie (Beitrag 1126802)

Logisch, weil die Referenzzählung dir dann dazwischen haut. Dafür gibts TPropertyChangedBase in der DSharp.Core.PropertyChangedBase.pas

..logisch, und das steht wo? ;)

BTW, bist Du schon mit dem StringGrid-DataBinding einen Schritt weiter?

[Stevie]

Zitat:

Zitat von neo4a (Beitrag 1126808)

Zitat:

Zitat von Stevie (Beitrag 1126802)

Logisch, weil die Referenzzählung dir dann dazwischen haut. Dafür gibts TPropertyChangedBase in der DSharp.Core.PropertyChangedBase.pas

..logisch, und das steht wo? ;)

Jetzt hier :twisted: Ich dachte, das sei allgemein bekannt, dass man Objekte und referenzgezählte Interfaces nicht vermischen sollte. Das ist der Preis der non GC Sprache. ;)

Zitat:

Zitat von neo4a (Beitrag 1126808)

BTW, bist Du schon mit dem StringGrid-DataBinding einen Schritt weiter?

Hab ich noch nicht mit angefangen.

[neo4a]

Zitat:

Zitat von Stevie (Beitrag 1126817)

Zitat:

Zitat von neo4a (Beitrag 1126808)

Zitat:

Zitat von Stevie (Beitrag 1126802)

Logisch, weil die Referenzzählung dir dann dazwischen haut. Dafür gibts TPropertyChangedBase in der DSharp.Core.PropertyChangedBase.pas

..logisch, und das steht wo? ;)

Jetzt hier :twisted: Ich dachte, das sei allgemein bekannt, dass man Objekte und referenzgezählte Interfaces nicht vermischen sollte.

Die Fehlermeldung in diesem Zusammenhang (also bei Benutzung von TInterfacedObject) spricht aber nur von RTTI-Funktionalität, die nicht unterstützt wird...

[Thom]

Zitat:

Zitat von Stevie (Beitrag 1126817)

Ich dachte, das sei allgemein bekannt, dass man Objekte und referenzgezählte Interfaces nicht vermischen sollte. Das ist der Preis der non GC Sprache.

Dumme Frage: Weshalb? :gruebel: Und was verstehst Du unter "vermischen"?

[Stevie]

Zitat:

Zitat von Thom (Beitrag 1126825)

Zitat:

Zitat von Stevie (Beitrag 1126817)

Ich dachte, das sei allgemein bekannt, dass man Objekte und referenzgezählte Interfaces nicht vermischen sollte. Das ist der Preis der non GC Sprache.

Dumme Frage: Weshalb? :gruebel: Und was verstehst Du unter "vermischen"?

Delphi-Quellcode:

procedure Test(i: IInterface);
begin

end;

var
  o: TInterfacedObject;
begin
  o := TInterfacedObject.Create;
  Test(o);
  // Objekt wurde freigegeben, da RefCount auf Null gesunken ist
end;

[Thom]

Vielleicht sollte man den Aufruf korrekt durchführen?

Delphi-Quellcode:

procedure Test(i: IInterface);
begin

end;

var
  o: TInterfacedObject;
begin
  o := TInterfacedObject.Create;
  Test(o as IInterface); //<- RefCount wird automatisch erhöht
  //Objekt "lebt" noch!
end;

[mquadrat]

Das mag zwar das korrekte Ergebnis liefern, ist aber extremst unintuitiv.

[Thom]

Eine korrekte Programmierung ist "extremst unintuitiv" und eine falsche Handhabung führt zur Schlußfolgerung "Ich dachte, das sei allgemein bekannt, dass man Objekte und referenzgezählte Interfaces nicht vermischen sollte. Das ist der Preis der non GC Sprache."

:gruebel:

Ich habe den Eindruck, daß einige Leute gar nicht mehr ohne "Compiler-Magie" leben können und wenn diese mal versagt, kommt gleich das große Gezetere und der Hinweis darauf, wie toll das andere Sprachen hinbekommen... :lol:

[Stevie]

Zitat:

Zitat von Thom (Beitrag 1126957)

Vielleicht sollte man den Aufruf korrekt durchführen?

Delphi-Quellcode:

procedure Test(i: IInterface);
begin

end;

var
  o: TInterfacedObject;
begin
  o := TInterfacedObject.Create;
  Test(o as IInterface); //<- RefCount wird automatisch erhöht
  //Objekt "lebt" noch!
end;

Gratulation, du hast den Scope nun auf die komplette Routine erweitert. Führt trotzdem dazu, dass o am Ende freigegeben wird. Mit diesem Vorgehen kann man gut RAII in Delphi umsetzen.

Zitat:

Zitat von Thom (Beitrag 1126986)

Ich habe den Eindruck, daß einige Leute gar nicht mehr ohne "Compiler-Magie" leben können und wenn diese mal versagt, kommt gleich das große Gezetere und der Hinweis darauf, wie toll das andere Sprachen hinbekommen... :lol:

Ich hab den Eindruck, dass du nicht weißt, wovon du sprichst. Klar, in dem Beispiel, hast du dem Objekt ein paar Zeilen mehr Lifetime geschenkt. Löst aber nicht das Problem, dass die Referenzzählung irgendwann unweigerlich zuschlägt. Das kann man nur durch explizites Aufrufen von _AddRef umgehen. Und dann hast du das Problem bloß verschoben, denn in dem Fall musst du entweder die Objekt Referenz so lange rumschleppen, bis du es freigeben musst, oder über einen cast des interfaces das dahinterliegende Objekt freigeben, da dass ja durch das Aushebeln der Referenzzählung durch das explizite um 1 erhöhen nicht mehr automatisch freigegeben wird. Fakt ist, ohne die Referenzzählung auszuschalten, bekommst du keine gescheite Vermischung von TInterfacedObject Derivat Referenzen und interface Referenzen hin.

[Thom]

Stevie,

ich fasse das einmal zusammen:

• Ich stelle eine Frage, um eine - meiner Meinung nach - fragwürdige Aussage Deinerseits besser zu verstehen.
• Daraufhin bringst Du ein Beispiel, das auf einer unkorrekten Handhabung basiert.
• Ich weise nach, daß das von Dir angesprochene Problem zu umgehen ist.

Anstatt jetzt zu sagen bzw. zu schreiben: "Ja, das könnte man so machen, aber..." kommt

Zitat:

Zitat von Stevie (Beitrag 1127000)

Gratulation, du hast den Scope nun auf die komplette Routine erweitert. Führt trotzdem dazu, dass o am Ende freigegeben wird.
[...]
Ich hab den Eindruck, dass du nicht weißt, wovon du sprichst.

"o am Ende freigegeben wird"? Aha... Wo in Deinem Beispiel wird die Verwendung des Objektes o nach Beendigung der Prozedur außerhalb beschrieben? Daß Interfaces bzw. Objekte mit einem Interface automatisch freigegeben werden, wenn die Referenzzählung bei Null angekommen ist, ist ja gerade eine grundlegende Idee dieser Technik. Will man solche Objekte erhalten, muß man lediglich den Referenzzähler explizit erhöhen, falls das eben nicht durch "Compiler-Magie" erledigt wird.

Zitat:

Fakt ist, ohne die Referenzzählung auszuschalten, bekommst du keine gescheite Vermischung von TInterfacedObject Derivat Referenzen und interface Referenzen hin.

Ich schon - wenn Du's nicht hinbekommst, solltes Du Dich fragen, weshalb...

Vielen Dank für diese eindrucksvolle Demonstration Deiner Fachkenntnisse und deiner Überheblichkeit. :thumb: :lol:

[mquadrat]

So, jetzt entspannen wir uns alle erst mal.


Ich finde es durchaus unintuitiv (von mir aus auch nervig und fehlerträchtig, wenn die Wörter besser passen sollten) wenn ein Objekt einer Klasse explizit in ein Interface gecastet werden muss, obwohl die Klasse ansich das Interface bereits bestätigt hat. Der korrekte Weg ist es sicher, aber gefallen muss es mir deshalb ja noch nicht ;) Und die Menge der Threads und Blog-Posts zu diesem Thema zeigt imho durchaus, dass es unintuitiv ist.

[Stevie]

Der erste, der in diesem Thread "überheblich" daher kam (was ich im übrigens nicht so aufgefasst habe, ich bin da relativ unempfindlich), warst du mit folgender Aussage:

Zitat:

Zitat von Thom (Beitrag 1126986)

Ich habe den Eindruck, daß einige Leute gar nicht mehr ohne "Compiler-Magie" leben können und wenn diese mal versagt, kommt gleich das große Gezetere und der Hinweis darauf, wie toll das andere Sprachen hinbekommen... :lol:

Nebenbei versagt in meinem Beispiel überhaupt keine "Compiler-Magie". Dein Softcast führt nur zu einem weiteren AddRef und Release (schau in den Debugger, wenn du mir nicht glaubst), welche den Lifecycle des Objekts auf den gesamten Prozedurbereich ausdehnen, anstatt nur auf den Call der Test Prozedur. Ähnliches passiert, wenn man eine Funktion hat, die eine Referenz zurückliefert, man diese aber nicht irgendwo speichert.

Außerdem war mein Beispiel das Minimalste, um zu zeigen, was passiert, wenn man Objektreferenz und Interface Referenz vermischt - und ich bin davon ausgegangen, dass man das auf ein komplexeres Szenario (Objekt wird außerhalb dieser Routine weiterverwendet) abstrahieren kann.

Eventuell überzeugt dich jemand, der mehr Ahnung von Delphi hat (Zweiter Absatz: "That basically means that mixing object references and interface references is dodgy". Und auch andere Delphi Entwickler sind schon in diese Falle getappt und es wird auch regelmäßig auf die Gefahren beim Vermischen (siehe die beiden letzten Absätze in der accepted answer) von beidem hingewiesen.

Falls das Erklären dieses fundierten Sachverhalts als Überheblichkeit missinterpretiert werden konnte, entschuldige ich mich dafür.

[Union]

Ich hab da mal eine mehr praxisorientierte Frage: Wie führe ich eigene Methoden und Konverter sinnvoll ein und wie konfiguriere ich diese, dass sie in der Topologie Vorrang haben?

Beispielsweise habe ich ein Edit an eine Property eines anderen Controls gebunden. Wird er Inhalt des Edits gelöscht und ein Notify ausgeführt, so knallt es natürlich mit einem EConversionError, weil ja folgendes passiert:

Delphi-Quellcode:

StrToInt('')

Ich könnte das natürlich ganz oben beim Notifier individuell abfangen, nur brauche ich dann keine LiveBindings mehr ;)

[Stevie]

DSharp hat durch einige Hilfsmethoden für TValue Konvertierungen für nahezu alle Standard Typen.

Bei den LiveBindings würde ich an dieser Stelle StrToIntDef benutzen.

[Union]

Spassvogel ;) D# ist ja bestimmt toll, aber mir geht es um XE2 (wie ja im Titel auch steht). Dass ich StrToIntDef benutzen sollte ist mir auch klar. Nur nicht wie ich das in das Binding reinbekomme. Und wie ich es in der Topologie steuere damit die richtige Methode verwendet wird.

[Stevie]

Also wenn ich über ne TBindExpression nen Edit und ne SpinEdit verbinde, brauch ich garnix konvertieren, wenn das Edit leer ist, wird 0 ins SpinEdit geschrieben (XE2 Update 1).

P.S. Für dich dürfte System.Bindings.Outputs.RegisterBasicOutputConvert ers interessant zum Anschauen sein. Dort werden die ganzen Default Converter gebaut.

[Union]

Ich habe ein TLabel.Top an TSpinEdit.Value gebunden. Wenn ich den Spinedit-Inhalt dann mit Entf komplett lösche, gibt es intern eine Exception. Die wird natürlich nur angezeigt wenn ich debugge... Funktional ist alles in Ordnung, das Top hat dann 0. Jetz tstell ich mir mal vor ich teste eine Anwendung wo ALLES nur noch über Livebindings läüft - das wird dann richtig eklig.

Code:

7c812afb kernel32.RaiseException + 0x52
System.SysUtils.ConvertErrorFmt($40FAB0,(...))
System.SysUtils.StrToInt(???)
Vcl.Samples.Spin.TSpinEdit.GetValue
System.Rtti.RawInvoke(???,???)
System.Rtti.Invoke($66BFA0,((($66AAEC, Pointer($67A878) as IValueData, 112, 51824, 27249264, $19FCA70, TClass($19FCA70), 112, -13712, 27249264, 5,86978591229431e-38, 1,34629252168586e-316, 0,00000000009933e-4933, 27249264, 2724,9264, 27249264, 27249264, ($19FCA70, nil), $19FCA70))),???,$4010A0,False)
System.Rtti.TRttiInstanceProperty.DoGetValue(???)
System.Rtti.TRttiProperty.GetValue(???)

Und meine weitere Frage war ja, wie ich eigene Methoden da reinbekomme. [edit]Ich gucks mal an. Auf die embwiki kann ich ja wahrscheinlich noch etwas warten[/edit]

[stahli]

etwas OT:

Zitat:

Zitat von Union (Beitrag 1127213)

Wenn ich den Spinedit-Inhalt dann mit Entf komplett lösche, gibt es intern eine Exception. Die wird natürlich nur angezeigt wenn ich debugge... Funktional ist alles in Ordnung, das Top hat dann 0.

Mich hat das auch schon mehrfach gestört, dass im SpinEdit nicht explizit auf '' getestet und 0 zugewiesen wird (oder alternativ StrToIntDef verwendet wird). Ich konnte das dann irgendwie immer noch vorher abfangen, aber ein solch unnötiges Problem ... ärgerlich.

EDIT: Aber Dein genanntes Problem dürfte sich auf das SpinEdit beschränken - oder?
Sonst hört sich das Binding ja ganz gut an. Vielleicht solltest Du für den ernsthaften Einsatz ein NullabelSpinEdit ableiten, das diesen Fehler intern vermeidet.

[Union]

Also ich finde die Bindings auch sehr interessant. Fragt sich wie dann mit DB-Bindings und Performance aussieht. Ich habe mal das Notify nahezu komplett debugged - da werden ja für ein Binding gefühlte 10.000 Zeilen Sourcecode durchlaufen bis er beim RTTI ankommt.

[stahli]

Na ja, je komfortabler und flexibler ein Framework zu benutzen ist, um so mehr muss dieses ja auch selbst durchführen und berücksichtigen. Das sieht man ja auch schon an der Benutzung der RTTI.
Und wenn man ein Observer-Pattern o.ä. selbst realisiert erzeugt das ja auch einigen Code, der abgearbeitet werden muss. Ich wäre da bezüglich der Perfomance nicht so pessimistisch.

Aber Du kannst ja mal dynamisch 100 Controls erzeugen und verbinden...
(und vor allem Dein D7 im Profil ersetzen ;-))


EDIT: Da stellt sich mir noch die Frage, wie Controls bei LiveBinding reagieren, die sich in geschlossenen Formularen oder ausgeblendeten TabSheets o.ä. befinden. Befassen dies sich mit der Werteaktualisierung?
In meiner Lösung werden die Controls nur auf invalidate gesetzt und holen sich die neuen Werte, wenn sie neu gezeichnet werden. Das heißt, nicht sichtbare Controls kümmern sich nicht um neue Daten.

[Union]

Zitat:

Aber Du kannst ja mal dynamisch 100 Controls erzeugen und verbinden...
(und vor allem Dein D7 im Profil ersetzen )

Warum? Mit XE2 kann ich noch nicht produktiv arbeiten. Bereite es nur vor. Hoffe das wird diesmal was. Nicht wie 2005,2006,2009...

[Stevie]

Das Problem hat überhaupt nix mit Bindings zu tun sondern mit dem schrottigen TSpinEdit (nicht umsonst befindet sich diese Komponente unter Samples). Schau dir GetValue an und du weißt, warum dort ne Exception kommt, wenn der Text leer ist. Nur der Author selber weiß wahrscheinlich, warum er dort nicht StrToIntDef benutzt hat (vielleicht gabs das damals noch nicht). Dieser Fehler würde auch kommen, wenn du im OnChange ganz einfach

Delphi-Quellcode:

Label1.Top := SpinEdit1.Value

geschrieben hättest.

Nachtrag: Die Exception wird sogar geraised, wenn du einfach den Text im SpinEdit löschst und dann mit Pfeil hoch oder runter änderst. (GetValue wird getriggert)

[Union]

Ich hab das hier abprogrammiert ;)

[stahli]

Zitat:

Zitat von Stevie (Beitrag 1127264)

Nachtrag: Die Exception wird sogar geraised, wenn du einfach den Text im SpinEdit löschst und dann mit Pfeil hoch oder runter änderst. (GetValue wird getriggert)

Das habe ich auch schon leidvoll spüren dürfen (siehst Du ja im TodSpinEdit).

[Stevie]

Hab mal nen QC Eintrag dazu gemacht.

[stahli]

... wobei es da vielleicht doch logischer wäre, auf einen Leerstring zu prüfen und dann MinValue zuzuweisen. Wenn jedoch "Müller" eingegeben wird, macht eine "ordentliche" Exception ja schon Sinn...
(soll aber zu dem Thema dann auch wieder reichen)

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1127268)

... wobei es da vielleicht doch logischer wäre, auf einen Leerstring zu prüfen und dann MinValue zuzuweisen. Wenn jedoch "Müller" eingegeben wird, macht eine "ordentliche" Exception ja schon Sinn...
(soll aber zu dem Thema dann auch wieder reichen)

Sie macht auch in diesem Fall keinen Sinn - jedenfalls bei der Art und Weise, wie das SpinEdit funktioniert. Denn egal ob Leerstring oder Müller - in beiden Fällen wird MinValue zurückgeliefert. Es wird unnötigerweise eine Exception in Kauf genommen, die aber in jedem Fall abgefangen wird -> Unfug.

[Union]

Ich hab jetzt mal einen simplen Performancetest mit Bindung eines Label an ein Edit gemacht. Erwartungsgemäß ist das LiveBinding ca. 60 mal langsamer als eine direkte Zuweisung der Eigenschaften. Keine schlechte Leistung, wenn man bedenkt wieviel Code dafür durchlaufen wird.