Meine Gründe doch zu den Forentage zu fahren!

Moin Zusammen!

Sorry, my non-German readers - this is a post only for the German community.

Habt Ihr nicht alle nach den ForenTagen „geschrien“? Warum sind den die Anmeldungszahlen nicht schon durch die Decke?

Mist – hab mich selber noch nicht angemeldet… Direkt mal nachholen.

Uwe hat ja schon das ein oder andere geschrieben – Thema Agenda...

Sorry - ich habe leider auch keine Zeit einen Vortrag vorzubereiten. Aber natürlich stehe ich für Fragen zur Verfügung.

Ist es nicht genau das, worum es bei den Forentage geht/gehen sollte – besonders nach der C-Zeit – IRL-Treffen um sich auszutauschen und Kontakte zu knüpfen?

Hier meine Gründe warum ich zu den Forentage fahre:

1. Ian Barker treffen – Er kommt extra nach Deutschland. Ich Skype zwar öfter mit Ihm am persönlich ist doch immer etwas anderes…
2. Neuste Katzen Infos mit Mathias austauschen.
3. Der Community-Abend
4. Leute Treffen, die mich davon überzeugen wollen, dass ich es sowieso falsch mache. (Natürlich nur um die Argumente zu entkräften)
5. Fragen zu beantworten.
6. Die Delphi-Entwickler „Jugend“ zu fördern. (Neugierig was das bedeutet? Dann meldet Euch an und Fragt mich!)
7. Ich bin gespannt, ob Mathias wieder die Übersetzung macht – wie in den guten alten Zeiten für David-I.

Habe ich etwas vergessen?

Ach ja die Vorträge.

Delphi 12 – sicherlich wieder ein großer Schritt nach vorne – kenn ich schon, aber solltet Ihr euch ansehen.
Den Vortrag von Thomas kenne ich auch schon, da er in unserer Delphi-Frühstücks-Crew ist und uns das schon mal vorgestellt hat – trotzdem Interessant.
Ich mag keine „Webanwendungen“ und auch nicht den Trend dahin – Sorry Michale, aber ich denke es könnte für viele Projekte interessant sein.
Naja – die Weiterentwicklung von TMS Web Core ist sicherlich beeindruckend. Aber wie Ihr ja sicherlich wisst, erzeuge ich lieber ISAPI.DLL’s – trotzdem werde ich mir den Vortag ansehen.
Na gut „stochastische Bestandsprojektionen“ – das habe ich wohl in Mathe verschlafen – oder war in der Zeit im Computerraum.

Also das sind meine Gründe…

Wenn Ihr noch einen Braucht, ja ich beantworte auch Fragen zu meine FDK und zu meinem MVVM-Framework…

Ich hoffe wir sehen uns im Shamrock…

Mavarik 

PS.: Ihr kennt Ian Barker nicht?

Dann habt Ihr sicherlich die Live-Streams der Apocalype Coding Group während Corona verpasst: Hier ist der 32h Replay!

oder

diese Ankündigung!

Escape the Button-Click development. Part II

 I know it's quite some time since my last blog post -  Sorry I was too busy...

if you have not read the 1st part, here is the link:
Escape the Button-Click development. Part I

OK - now the next question is how to update the Form/View.

We have to decide if we want to link the View to the ViewModel. Let's take a closer look at the differences.

Link to the View

In this case, you can write something like fView.Grid.Cells[0,0] := 'Date/Time';

Not bad - only some lines must be changed to address the View-Reference, but on the other hand, you also have the link to the view in your unit tests, and that is something we want to avoid. So this is a shortcut that only helps with separating your code from the View, but not a step to be able to create nice unit tests.

Not link to the View

This is a good approach, but how to update the view?
Without any special components at your Viewmodel or special Components on your View you have to call some kind of property change procedure by hand.

If some content has changed in your Viewmodel e.G. 

fName := 'Frank';
PropertyChange;

On your View there must be at least some code to handle this like:

Procedure PropertyChange;
begin
    EdName.Text := fViewModel.Name;
end;

Of course, you do not want to create a procedure for each control/field and you also don't want to update every UI-Element on every change of one field.

You can use a Enum:

Type
  ToUpdate = (toAll,tuName,tuTown...);

But in this case, I would simply use an Integer - perhaps you define a const value for each, but this is up to you.

This is your View:

  TMainView = class(TForm)
    Edit1: TEdit;
    Edit2: TEdit;
    Save: TButton;
  private
    fViewModel : TMainViewModel;

    Procedure PropertyChange(aWhat : Integer);
  public
    Constructor Create(aViewModel : TMainViewModel);
  end;

And this is the PropertyChange:

Procedure TMainView.PropertyChange(aWhat : Integer);
begin
  case aWhat of
    0 : begin
          Edit1.Text   := ''
          Edit2.Text   := ''
          Save.Enabled := false; 
        end;
    1 : Edit1.Text   := fViewModel.Name;
    2 : Edit2.Text   := fViewModel.Street;
    3 : Save.Enabled := fViewModel.CanSave;
  end; // of case
end;

That's it - not very fancy, but this approach is doing the job. If you want to write a unit test for this you can just write a little mockup for this procedure and you can test the behavior of your "Save-Button".

That is all for the moment.