4. Infos zu UpdateData und weshalb ich es nicht verwende !

Infos zu UpdateData und weshalb ich es nicht verwende !

  • R

    Erstmal zur Theorie:
    Mit UpdateData wird der dynamische Datenaustausch zwischen Steuerelementen und den zugehörigen Variablen realisiert.

    Zur Praxis:
    Zum 1. braucht jeder dynamische Datenaustausch eine Codezeile innerhalb der Funktion DoDataExchange, zum zweiten eine Zeile innerhalb des Klassenobjekts, wo die zugehörige Variable steht.

    class C1
{
  CString m_strData; 1. Zeile
};

void C1::DoDataExchange( ...)
{
  DDX_VARIABLE( pDE, IDC_MYSTRING, m_strData); // 2. Zeile
}

void SetData( int iValue)
{
  m_strData.Format("%d", iValue);  // 3. Zeile
  UpdateData( FALSE); // 4. Zeile
}

    1. Nachteil:
    Macht man nun jedes Control zu einem DDX-Element, wird bei jedem Aufruf von UpdateData jedes Element aktualisiert -> der ganze Dialog flimmert bei öfteren Aktualisierfunktionen
    2. Nachteil:
    Da jedes Element aktualisiert wird, ist die Funktion nicht besonders schnell, also total das Gegenteil von dem, was über Grafikausgaben und Geschwindigkeit gesagt wird: "Aktualisiere nur das, was sich geändert hat!".
    3. Nachteil:
    Mehr Code ...
    Obiges Beispiel ohne DDX würde so aussehen:

    void SetData( int iValue)
{
  SetDlgItemInt( IDC_MYSTRING, iValue);
}

    und last not least der
    4. Nachteil:
    Das Control besitzt einen internen Speicher für seine Daten, zusätzlich wird noch ein prozessinterner Speicher angelegt für die DDX-Variable, also doppelter Speicherverbrauch.

    0
  • O

    Nehm ich auch nie.

    Ausser bei Dialogen "Werte eintragen und auf Ok klicken".
    Da ist das ungemein praktisch.

    Ein Ersatz wäre sowas evtl. (müsste noch ausgebaut werden)

    class ByValue
{
public:
    void SetControl(CWnd* parent,int id)
    {
        _control = GetDlgItem(parent->m_hWnd,id);
    }
    operator =(LPCTSTR text)
    {
        SetWindowText(_control,text);
    }
    operator =(int val)
    {
        char num[12];
        SetWindowText(_control,itoa(val,num,10));
    }
    operator CString()
    {
        int len = GetWindowTextLength(_control);
        CString text;
        GetWindowText(_control,text.GetBuffer(len),len + 1);
        return text;
    }
    operator int()
    {
        return atoi(operator CString());
    }
    CString get()
    {
        return operator CString();
    }
protected:
    HWND _control;
};

    [ Dieser Beitrag wurde am 12.12.2002 um 09:54 Uhr von Nemesyzz editiert. ]

    0

  • Ausser bei Dialogen "Werte eintragen und auf Ok klicken".
    Da ist das ungemein praktisch.

    Genau dafür ist es aber doch auch gedacht!
    Die meisten Dialoge brauchen keine SetData-Funktion.
    Das ist nur bei Dialogen der Fall, wo eine Auswahl in einem Feld den Wert in einem anderen Feld ändert.

    0
  • R

    Ausser bei Dialogen "Werte eintragen und auf Ok klicken".
    Da ist das ungemein praktisch.

    Nunja, es gibt Programmierer und Software-Zusammenklicker ;o)

    Die meisten Dialoge brauchen keine SetData-Funktion

    Das war ein Beispiel, um zu zeigen, dass selbst das Aktualisieren nur eines einzigen Steuerelements mindestens 2 Zeilen benötigt!
    Und wir alle wissen doch, dass C-Programmmierer faul sind

    a = b ? c ? 1 : 0 : 2;
    0
  • V

    Hi zusammen,

    @RenéG:

    Ich gebe dir grundsätzlich recht. Nur würde ich es anders formulieren. Man sollte meiner Meinung nach sagen, dass man auf DDX verzichten sollte, sobald es sich um Code handelt, der bezüglich des Zeitkriteriums als kritisch zu betrachten ist oder man sichtbare Problem damit hat. Man sollte also um das Problem wissen. Aber wie gesagt, für den Puristen und vom Grundsatz her stimmt deine Aussgage natürlich.

    Das mehr Code dabei rauskommt, stimmt natürlich auch. Aber den muss man ja nicht selber tippen. Von daher würde der Faule wohl eher DDX verwenden;).

    Grüße, Volle.

    P.S.: Du hast aber nicht das Projekt mit den 600 Steuerelementen bezogen, oder:D? Gibt es da eigentlich schon einen Screenshot?

    0
  • O

    Hallo,

    die Sinnhaftigkeit des Artikel ist nicht so ganz klar.

    Du gibst zwei Beispile an. Im ersten deklarierst Du ein Engabefeld as CSTring und im zweiten füllst Du lediglich ein Editfeld. Wo ist der Sinn?

    im header:
    CEdit m_str;

    Im code:
    im Code sprichst Du dann das Element ganz einfach durch m_str an. Dies dint lediglich zur Vereinfachung und zum besseren Überlick als jedesmal mit der Resource ID rumzuhampeln.
    Desweiteren sollte man auch das Subclassen (in der heutigen Zeit nicht gerade selten) nicht vergessen.

    Fazit:
    Wenn Du ein Element nicht als String dekalrierst brauchst Du auch kein UdpateData. daher ist Dein Artikel in dem Vergleich Deiner Daten schlicht weg FALSCH.

    Gruß

    Ocrana

    0
  • R

    Du gibst zwei Beispile an. Im ersten deklarierst Du ein Engabefeld as CSTring und im zweiten füllst Du lediglich ein Editfeld. Wo ist der Sinn?

    Tut mir leid, es handelt sich um ein und das gleiche Beispiel, einmal mit DDX, einmal ohne!

    daher ist Dein Artikel in dem Vergleich Deiner Daten schlicht weg FALSCH.

    Nur weil Du 1 Abschnitt der 4 beschriebenen als falsch ansiehst musst Du doch nicht alles abstempeln!

    0
  • O

    Hallo,

    Du machst einerseits ein DDX_VARIABLE. Der zweite Abschnitt ist aber, so wie Du Ihn schreibst ein DDX_CONTROL. Du kannst nicht einerseits einen String mit einem Controlfeld deklarieren und diesen Füllen und dann einfach nur das Control füllen.
    In dem was Du schreibst liegen Welten. Daher ist es falsch.

    Gruß

    Ocrana

    0
  • R

    Ich sehe noch immer kein DDX_CONTROL, weil bei einem DDX_CONTROL das Membercontrol ( z.B. CEdit) gesubclassed wird, ich aber nur einen String an ein Edit schicken möchte, ohne Subclassing.
    In meinem Bsp. finde ich nur einen String und eine Control-ID, nix DDX_CONTROL, sondern DDX_Text!

    0
Anmelden zum Antworten