Timer Steuern
-
Jo Danke...muss da nichts Rechnen! Das ist die Bahn einer Fertigungs Strasse bei uns im Schul Labor.. Die Farblich unterteilten Bahnen sind verschiedene Sektoren die bereits mit Indukiv Sensoren bestückt sind... Es läuft alles drauf hinaus das die Signale von den Sensoren von einem Microcontroller erfasst werden und ich mit dessen Signalen in c++ darstellen kann wo welcher Schlitten sich befindet! Also noch jede Menge Arbeit.. so Probier es mal so aus wie du sagst! :p

-
Glaube das Prinzip von der if else an der Stelle habe ich kapiert. Habe dann jetzt versucht nach dem else anfängt mit an einem bestimmtem Takt die ganze Sache wieder mit nem neuem if wieder auf der Y-Achse nach unten laufen tu lassen! Bin da mit if aber wohl auf dem Holzweg. Kannst du mir noch einer sagen wie ich dann nach else weiter machen muss damit noch ein paar mehr Richtungsänderungen einbauen kann???
Danke
Prim3
-
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 linksWenn 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 } } } //USWIst recht pirmitiv, aber mit dem Prinzip kannst du deine Grafik theoretisch in alle ecken schubsen.
-
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?
-
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.
-
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!
-
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.

-
[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?
-
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.

-
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"!
-
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;
-
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.

-
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!
-
Hmm, viel zu viele Fallen für einen eigentlich so einfach scheinenden Datentyp.

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

Die Falle ist immer der == Operator!
-
Martin Richter schrieb:
Man sollte ==TRUE niemals nicht und überhaupt nicht verwenden!
ACK!
