true//false ????



  • hab ich gemacht,
    hat nichts gebracht,
    es geht nicht
    hast du vielleicht eine andere idee, woran es noch liegen könnte.
    Ich habe eine ähnliche abfrage woanderes und die geht auch, die hatte ich auch als vorlage genommen, halt hab ich es so umgeändert wie ich es da wo ich momentan bin, brauche.
    da ist bestimmt wieder irgendwo ein dankfehler meinerseits drin, aber wo nur oder kann das auch sein das das tätsichlich nicht funktioniert???



  • hm ...
    Wie hast du denn m_v1, m_v2 usw deklariert?



  • über den klassenassistent, vom typ BOOL,
    dachte ich auch erst....



  • Zeig mal deine Funktion ...
    (so langsam gehen mir die Ideen aus :D)
    Allerdings muss ich jetzt noch ma kurz in die Schule, kanns mir erst in ner Stunde angucken.



  • sinds denn tatsächlich membervariablen der checkboxen, oder...?und updatedata(false) holt doch die werte aus den checkboxen in die membervariablen.. true weist die geänderten werte in membervariablen den steuerelemente zu



  • bellaschönchen schrieb:

    und updatedata(false) holt doch die werte aus den checkboxen in die membervariablen.. true weist die geänderten werte in membervariablen den steuerelemente zu

    Tut mir leid, da muss ich dich enttäuschen, es ist genau anders herum:

    MSDN schrieb:

    Flag that indicates whether dialog box is being initialized (FALSE) or data is being retrieved (TRUE).



  • if (in_file.Open(file_name, CFile::modeCreate|CFile::modeReadWrite))
    {
    UpdateData(TRUE); 
    //wenn V1 markiert dann schreiben,usw...
    if(m_v1==true)
    {
    wenn gesetzt dann schreibe in File			
    }
    if(m_v2==true)
    {
    .
    .
    .
    }
    else
    {	
    in_file.WriteString("geht nicht");
    in_file.WriteString("\n");
    		}
    in_file.Close();
    }
    CStdioFile out_file;
    
    	if (out_file.Open(file_name,  CFile::modeReadWrite, &cfeException))
    	 { 
    // öffnen des urfiles, lesen in puffer und dann in neues File schreiben
    if (in_file.Open(urfile, CFile::modeRead, &cfeException))
    {	
    					DWORD laenge = in_file.GetLength();	
    	in_file.Read( buf, laenge);
    	DWORD dwActual = out_file.SeekToEnd();
    	out_file.Write(buf,laenge);
    	}
    	out_file.Close();
    	in_file.Close();
    }
    

    so sieht das alles aus, aber das das alles passiert wenn ich auf den weiter button drücke kann doch auch nicht sein.
    Der weiter button, tut weiter blättern in einer verketteten liste, und wenn der gedrückt wird soll das was markiert ist in das File geschrieben werden und halt eben weiter geblättert werden innerhalb der verketteten liste.



  • BOOL versteht sich aber schlecht mit bool. Nimm mal TRUE statt true.



  • war ein versuch wert
    geht aber auch nicht.....



  • estartu_de schrieb:

    BOOL versteht sich aber schlecht mit bool. Nimm mal TRUE statt true.

    Das ist quatsch. TRUE ist als 1 definiert. Und alles ungleich 0 ist true.



  • Mag ja sein, aber ich kann mich errinnern, von einem "Guru" den Rat bekommen zu haben, dass ich die nach Möglichkeit nicht mischen soll.
    Da halte ich mich dran - jedem das seine.



  • Das ist ja was anderes. Natürlich sollte man sie nicht mischen, weil es Warnungen gibt und man Warnungen grundsätzlich vermeiden sollte. Das ändert nichts daran, dass es funktioniert.



  • Wenn dir der "Guru" den rat gegeben hat, das nicht zu mischen, dann mestimmt auch, das man niemals (NIEMALS! N I E M A L S !) mit "==true" oder "==TRUE" vergleichen sollte!?

    Ja, da bin ich total verbohrt und laß nicht mit mir reden.
    Denn das geht leider nur solange gut, bis es mal schief geht, da sich hinreichend viele API's nicht an "true == 1" halten.

    Und außerdem lifert in

    bool b = ...;
    if (b == true)
    

    der Ausdruck "b==true" einen bool zurück - nun möchtest du ja wissen, ob dieser true oder false ist, also schreibst du besser (b==true)==true

    was auch nur einen bool zurückliefert, also doch besser ((b==true)==true)==true
    was..

    😃



  • Wie bitte? Kannst du deinen Text mal übersetzen? was ist zb der Quatsch mit "da sich hinreichend viele API's nicht an "true == 1" halten. " ??



  • Nein, das kam in dem Zusammenhang nicht vor.

    Außerdem ist das Weglassen Geschmackssache.



  • @peterchen: Wenn du schon Langeweile hast und solch einen komischen Quark von dir gibst dann mecker doch mal hieran herum...

    BOOL b = 200;
    if((!!b != 0) == TRUE)
      machWas();
    

    PS: Hab auch Langeweile.
    PPS: Warum versaue ich eigentlich fremde Threads. Dickes sorry an den Ersteller 😉 .



  • kann man das true net komplett weglassen? ist doch standardeinstellung:
    if(b)...



  • Natürlich. Deswegen auch meine forsche Antwort auf seinen Beitrag ...



  • @dEUs:

    1. WinAPI definiert normalerweise

    BOOL function(...)
    If the function succeeds, the return value is nonzero

    (vergleich == TRUE ist falsch)

    1. VARIANT_BOOL (üblicherweise in ActiveX / Dispatch-Schnittstellen verwendet)
      hier ist zum einen VARIANT_TRUE == (short)-1, zum anderen halten sich viele Implementationen nicht daran, nur VARIANT_TRUE oder VARIANT_FALSE zurückzugeben. 1 hatte ich selbst schon, von "Anzahl" hab ich schon gehört

    VC6 warnt wenigstens bei

    BOOL b;
    if (b == true) // mix: int and bool
    

    macht aber nicht jeder Compiler.

    der vergleich eines kleinen bool mit true ist im prinzip redundant:
    bool b;
    (b); // wert des Ausrucks ist true oder false
    (b==true); // wert des ausdrucks ist true oder false, identisch mit (b)

    Das macht zwar Sinn, wenn man explizit klarstellen möchte das man hier einen bool testet, verführt aber (leider) sehr schnell zu == TRUE / == VARIANT_TRUE vergleichen, und das Risiko ist es m.E. nicht wert.

    vergleich mit false ist insofern ungefährlich, als das es immer 0 ist (mir ist zumindest kein anderes bekannt 🙄 ). Hier sehe ich sogar ein daß bei folgendem Code

    if ( QueryThingieIfItsOK(p, *vcmxpadw, yadda yadda) == false)
    if ( !QueryThingieIfItsOK(p, *vcmxpadw, yadda yadda) )
    

    die erste zeile deutlicher ist, würde es aber nicht machen.

    ist, denke ich, alles eine Sache der (schlechten) Erfahrungen die man mit sich selbst und anderen gemacht hat. Wenn man einmal 6h nach einem simplen Fehler gesucht hat, sollte man sich schon überlegen, wie man den in Zukunft vermeidet. probleme mit "==true/TRUE" sind mir aber bisher oft genug und nicht nur bei mir untergekommen, daß ich jedem davon abraten würde.



  • zu 1)
    Da vergleichst du aber net bool mit BOOL sondern int mit BOOL ...


Anmelden zum Antworten