Timer Steuern

Uruk-h4j

ziemlich schwer zu lesen dein Programm....

Aber ich würde für die 4 Richtungen 2 Boolsche variablen anlegen die man dann kombinieren kann.

nennen wir wie mal

BOOL A;
BOOL B;

dann wäre:

A=0 und B=0 -> bewegung nach oben
A=0 und B=1 -> Bewegung nach rechts
A=1 und B=0 -> Bewegung nach unten
A=1 und B=1 -> Bewegung nach links

Wenn du jetzt festlegst, ab wann die Bewegung zu ende wäre, dann kannst du die Variablen setzen.

Z.B.

//Nach RECHTS
if((A == 0) && (B == 1))
{
 for(int i=0; i<=20; i++)
 { 
  //20schritte
  //Deine Funktionen

  if(i==20)
  {
    A = 0; //TRUE
    B = 0; //FALSE
  }
 }
}

//Nach OBEN
if((A == 0) && (B == 0))
{
 for(int j=0; j<=30; j++)
 { 
  //30 schritte
  //Deine Funktionen

  if(i==30)
  {
    A = 1; //TRUE
    B = 1; //FALSE
  }
 }
}

//USW

Ist recht pirmitiv, aber mit dem Prinzip kannst du deine Grafik theoretisch in alle ecken schubsen.

Prim3

BOOL A;
BOOL B;

Die Varaiblen BOOL A & B was ist das für nen Typ mit int habe ich das probiert. Oder wie lege ich das an damit der nicht mekert?

Uruk-h4j

verwende mal satzzeichen

BOOL ist ein Boolscher Wert, der "TRUE" (wahr) und "FALSE" (unwar / falsch) sein kann. Hat nichts mit Integer zu tun. Mit Integer das zu relisieren, was ich da gepostet hab ist umständlich und inffizient. ich glaiub man kann BOOL auch klein schreiben, also "bool". Sollte aber eigenlich keinen unterschied machen. VS kennt beide varianten.

Martin Richter

Uruk-h4j schrieb:

BOOL ist ein Boolscher Wert, der "TRUE" (wahr) und "FALSE" (unwar / falsch) sein kann. Hat nichts mit Integer zu tun. Mit Integer das zu relisieren, was ich da gepostet hab ist umständlich und inffizient. ich glaiub man kann BOOL auch klein schreiben, also "bool". Sollte aber eigenlich keinen unterschied machen. VS kennt beide varianten.

Du irrst schwer.
BOOL (großgeschrieben) ist ein int und kann jeden Wert eines int annehmen (auch -1, oder 4711). Deshalb sollte man eine BOOL Variable nicht mit TRUE vergleichen!

bool (kleingeschrieben) kann dagegen wirklich nur die Werte true (1) und false(0) (kleingeschrieben annehmen).

Ich verwende wo es geht nur bool!

estartu

Martin Richter schrieb:

Deshalb sollte man eine BOOL Variable nicht mit TRUE vergleichen!

Womit dann?

bool (kleingeschrieben) kann dagegen wirklich nur die Werte true (1) und false(0) (kleingeschrieben annehmen).

Ich verwende wo es geht nur bool!

Genau, aber sobald man eine GUI dabei hat, wird es bunt gemischt.

Martin Richter

[quote="estartu"]

Martin Richter schrieb:

Deshalb sollte man eine BOOL Variable nicht mit TRUE vergleichen!

Womit dann?
[quote="estartu"]

Meistens kann man sich einen Vergleich sparen. In einem if und while genügt es einfach die Variable zu schreiben ohne == oder !=.

Ansonsten ist nur der Vergleich zu FALSE sicher.

BOOL bMyState = 56; // Das geht!

if (bMyState) // OK
...
if (!bMyState) // OK
...
if (bMyState==FALSE) // OK
...
if (bMyState!=FALSE) // OK
...
if (bMyState==TRUE) // FAAAAALSCH!!!!!!
...
if (bMyState!=TRUE) // FAAAAALSCH!!!!!!
...

Ich verwendenur die Varianten 1 und 2!
Ein BOOL wir durch den Vergleich !=0 (!=FALSE) korrekt in einen bool gewandelt.

bool (kleingeschrieben) kann dagegen wirklich nur die Werte true (1) und false(0) (kleingeschrieben annehmen).

Ich verwende wo es geht nur bool!

Genau, aber sobald man eine GUI dabei hat, wird es bunt gemischt.

Aber das stört doch keinen. ein bool kann immer für ein BOOL herhalten!
Also bervorzuge ich grundsätzlich bool. Sag mir mal wo Du BOOL wirklich brauchst?

estartu

Kannst du das mit dem TRUE begründen?
Ich vergleiche tendenziell eher mit TRUE und habe noch keine direkten Nebenwirkungen bemerkt.

Alleine für die Wandlung BOOL nach bool mache ich das unzählige Male.

Jochen Kalmbach

estartu schrieb:

Kannst du das mit dem TRUE begründen?
Ich vergleiche tendenziell eher mit TRUE und habe noch keine direkten Nebenwirkungen bemerkt.

Vergelichst Du Variant-Bolls auch mit TRUE!? Dann machst Du aber was falsch... denn dort gibt es "VARIANT_TRUE"

FALSE ist eigentlich immer "0"! TRUE kann sich je nach (ungeschicktem) Define entweder 1 oder -1 sein...
Deswegen: Immer mit "FALSE" vergleichen und *nie* mit "TRUE"!

Martin Richter

estartu schrieb:

Kannst du das mit dem TRUE begründen?
Ich vergleiche tendenziell eher mit TRUE und habe noch keine direkten Nebenwirkungen bemerkt.

Alleine für die Wandlung BOOL nach bool mache ich das unzählige Male.

Horror!

Mein Beispiel, warum man es nie machen sollte:

BOOL bValue = 56; 
// Legaler Code und kann ein legaler return 
// wert einer SDK Funktion sein (dort steht nur !=0 bei success z.B.)

// boolValue ist nun false
bool boolValue = bValue==TRUE;

estartu

Okay, also ich verwende es eigentlich nur im Zusammenhang mit Checkboxen.
Da sollte es ja nicht so schlimm sein.

Martin Richter schrieb:

Mein Beispiel, warum man es nie machen sollte:

BOOL bValue = 56; 
// Legaler Code und kann ein legaler return 
// wert einer SDK Funktion sein (dort steht nur !=0 bei success z.B.)

// boolValue ist nun false
bool boolValue = bValue==TRUE;

Okay, wenn da "!=0 bei success" steht dann vergleiche ich auch auf 0.

Martin Richter

estartu schrieb:

Okay, also ich verwende es eigentlich nur im Zusammenhang mit Checkboxen.
Da sollte es ja nicht so schlimm sein.

Was prüfst Du da? Den Status?
Nur als Anmerkung: Auch hier sollte man vorsichtig sein. Eine Tristate-Checkbox kennt 0,1,2 und da 2!=TRUE ist, liegt hier mindestens auch solch ein Problem.
Du baust also die UI um und schon wirds lustig...

Man sollte ==TRUE niemals nicht und überhaupt nicht verwenden!

estartu

Hmm, viel zu viele Fallen für einen eigentlich so einfach scheinenden Datentyp.

Martin Richter

estartu schrieb:

Hmm, viel zu viele Fallen für einen eigentlich so einfach scheinenden Datentyp.

Die Falle ist immer der == Operator!

hustbaer

Martin Richter schrieb:

Man sollte ==TRUE niemals nicht und überhaupt nicht verwenden!

ACK!