Guten Tag Ich habe ein Problem, ich möchte von 6 Tastern die Reihenfolge merken. (H1,H2,H3,H4,H5,H6). Zu den Tastern gibt es 6 LEDs (L1,L2,L3,L4,L5,L6); Beispiel: die Taster wurden in der folgenden Reihenfolge gedrückt und gedrückt gehalten. H1, H2, H4, H5, H6, H3 L1 leuchtet so lange, bis H1 nicht mehr gedrückt ist. In diesem Moment geht L2 an und leuchtet so lange, bis H2 nicht mehr gedrückt ist. In diesem Moment geht L4 an und leuchtet so lange, bis H4 nicht mehr gedrückt ist, und so weiter. Ich habe keinen Plan wie vorzugehen. Bei drei Tastern hätte ich es geschafft weil weniger Kombinationen vorkämen. Ich dachte an Arrays oder so die, die Reihenfolge abspeichert und dann ausgibt. Aber kann dies nicht umsetzen. Ich wäre sehr Froh wenn ihr mir weiterhelfen könntet.
Elektro F. schrieb: > Ich dachte an Arrays oder > so die, die Reihenfolge abspeichert und dann ausgibt. Zähle einfach den Arrayindex hoch, wenn eine weitere Taste gedrückt wird und speichere dort deren Nummer ab. Zur Ausgabe läufst Du das Array hoch, wenn eine Taste losgelassen wird. Was soll den passieren, wenn das Loslassen in anderer Reihenfolge erfolgt? 6 Tasten gedrückt zu halten, sind das rastende Tasten?
Elektro F. schrieb: > L1 leuchtet so lange, bis H1 nicht mehr gedrückt ist. > > In diesem Moment geht L2 an und leuchtet so lange, bis H2 nicht mehr > gedrückt ist. > > In diesem Moment geht L4 an und leuchtet so lange, bis H4 nicht mehr > gedrückt ist, und so weiter. Das ist keine vollständige Beschreibung des gewünschten Verhaltens. Allenfalls ein Beispiel. Zuerst musst du dir klarwerden wie dein Verhalten sein soll und das so beschreiben dass es jemand anderes verstehen kann. Erst dann kann man das in Software machen.
Peter D. schrieb: > Elektro F. schrieb: >> Ich dachte an Arrays oder >> so die, die Reihenfolge abspeichert und dann ausgibt. > > Zähle einfach den Arrayindex hoch, wenn eine weitere Taste gedrückt wird > und speichere dort deren Nummer ab. > Zur Ausgabe läufst Du das Array hoch, wenn eine Taste losgelassen wird. Versuche dies mal so umzusetzen > Was soll den passieren, wenn das Loslassen in anderer Reihenfolge > erfolgt? dann soll dieser Taster übersprungen werden der in der falschen Reihenfolge losgelassen wird und seine LED wird nicht leuchten, ausser alles startet von Neu. > 6 Tasten gedrückt zu halten, sind das rastende Tasten? Ja Vielen Dank für deine Antwort
Elektro F. schrieb: > Beispiel: die Taster wurden in der folgenden Reihenfolge gedrückt und > gedrückt gehalten. H1, H2, H4, H5, H6, H3 > > L1 leuchtet so lange, bis H1 nicht mehr gedrückt ist. > > In diesem Moment geht L2 an und leuchtet so lange, bis H2 nicht mehr > gedrückt ist. > > In diesem Moment geht L4 an und leuchtet so lange, bis H4 nicht mehr > gedrückt ist, und so weiter. Nette Schulaufgabe, mal was Neues... ;-) Was soll passieren, wenn die H2 vor der H1 losgelassen wird? Zur Problemlösung: Du musst ein Progamm schreiben, das laufend 1. die Tasten abfragt und bei einer "Einschaltflanke" (die kann pyhsikalisch steigend oder fallend sein, je nachdem wie die Taster angeschlossen sind) den Tasterdruck in einen Ringpuffer schreiben. Und dann muss das Programm 2. die "nächste Taste" im Ringpuffer auslesen, die zugejörige Lampe einschalten und kontrollieren, ob die Taste noch immer gedrückt ist. Falls nicht, dann wird die Lampe ausgeschaltet und der Index für die "nächste Taste" hochgezählt.
Gast
#6963000
Elektro F. schrieb: > ausser alles startet von Neu. Und was ist das Kriterium dafür? Wann startet alles 'Neu'? Was soll passieren wenn H1, H2, und H3 nacheinander gedrückt wurden, dann H1 losgelassen wird und L2 leuchtet, dann aber H1 wieder gedrückt wird? Du siehst, daß deine Beschreibung diverse Fälle noch nicht abdeckt.
Dann wird H1 wieder hintenangestellt.
Elektro F. schrieb: > Dann wird H1 wieder hintenangestellt. Und "vorne" rausgelöscht? Das wird langsam doch nett aufwendig. Denn jetzt musst du auch noch die "Loslassflanke" erkennen und das Array umsortieren oder Einträge darin invalidieren. Ich denke, du solltest da mal die komplette Bedienlogik mit allen diesen Ausnahme- und Sonderfällen genau spezifizieren.
Elektro F. schrieb: > Dann wird H1 wieder hintenangestellt. Und bei Tasten, die noch nicht an der Reihe waren? Und Du siehst wirklich noch selber durch, was das Ganze werden soll?
Diese die Tasten die nicht an der Reihe waren, kommen einfach nicht dran. Wisst ihr wie ich eine for schleife mache die an eine Bedingung geknüpft ist? Wenn ein Taster gedrückt wird auf positive Flanke, soll die for Schleife nur eins raufzählen.
Also ein Array wäre ja dann doch sehr komplex, bedingt durch das mitten drin löschen, sortieren, hinten doch wieder einfügen usw. Dann dachte ich an FIFO, aber da wirds auch net besser mit zwischen drin was herauslöschen usw. Eigentlich wären ja verkettete Listen dafür perfekt :-D Kurz umhängen oder hinten anhängen...
Adam P. schrieb: > Also ein Array wäre ja dann doch sehr komplex, > bedingt durch das mitten drin löschen, sortieren, hinten doch wieder > einfügen usw. > > Dann dachte ich an FIFO, aber da wirds auch net besser mit zwischen drin > was herauslöschen usw. > > Eigentlich wären ja verkettete Listen dafür perfekt :-D > Kurz umhängen oder hinten anhängen... Ok davon habe ich kein Plan
Gast
#6963111
Es wird Zeit für ein gutes Buch über die Einführung ins Programmieren. So mit Schleifen, Arrays, Kontrollstrukturen etc. Prgrammieren ist mehr als Copy&Paste.
Elektro F. schrieb: > Ok davon habe ich kein Plan Also das geht schon mit Arrays, aber da sollte man dann doch schon wissen wie und was man macht. Das ist nicht eben mal eine for-Schleife und 2-3 if-Abfragen.
Elektro F. schrieb: > Wenn ein Taster gedrückt wird auf positive Flanke, soll die for Schleife > nur eins raufzählen. Deine Denkweise und der daraus resultierende Ansatz ist nicht zur Problemlösung geeignet. Es ist einfach so: du hast genau 1 Schleife in deinem Programm. Das ist die Hauptschleife. Die wird so schnell wie möglich so oft wie möglich durchlaufen. In dieser Hauptschleife liest du pro Durchlauf die Eingänge ein, erkennst Flanken und aktualisierst deine "Tastentabelle" entsprechend. Dann rechnest du aus den Eingängen und dem aktuellen Zustand in der "Tastentabelle" den ein- oder auszuschaltenden Ausgang und aktualiserst diesen. Danach ist ein Schleifendurchlauf zu Ende und du fängst sofort wieder von vorn an. Pro Sekunde darf die Hauptschleife ruhig 10000 mal oder noch öfter durchgerechnet werden.
Weiterhin solltest du auf folgende Situation achten: Erste Taste wird nicht losgelassen, die anderen werden wild herumgedrückt, sprich immer wieder neu eingereiht => Dies würde zu einem Buffer Overflow führen oder wenn du dies abfängst, kannst du keine neuen Ereignisse speichern. Das sollte man sich erstmal alles grob aufzeichnen und durchdenken.
Adam P. schrieb: > Also ein Array wäre ja dann doch sehr komplex, > bedingt durch das mitten drin löschen, sortieren, hinten doch wieder > einfügen usw. Ganz so schlimm ist das nicht. Es wird ja nur der erste Eintrag gelöscht, also einfach das Array um 1 nach unten kopieren. Für einen Neuling erscheint mir diese Aufgabe aber auch zu komplex. Man hat es ja schon schwer, den Ablauf zu verstehen. @Elektro F. Hat das irgend einen praktischen Hintergrund oder ist alles nur Spielerei?
Adam P. schrieb: > Dies würde zu einem Buffer Overflow führen Wenn es nur 6 Tasten gibt, dann braucht man nur einen Buffer mit 6 Speicherplätzen... Man könnte sich z.B. auch nicht die Reihenfolge der 6 Tasten speichern, sondern Betätigungszeitpunkte. Und wenn ich so drüber nachdenke, hätte dieser Ansatz einige Vorteile ;-)
Lothar M. schrieb: > Wenn es nur 6 Tasten gibt, dann braucht man nur einen Buffer mit 6 > Speicherplätzen... Ja da waren meine Finger schneller :-D Klar hast ja recht, da bei jedem loslassen, dass Array neu sortiert wird.
Dann scheint es ja gar net so wild zu sein. Die Stellen im Array sind im unbenutztem Zustand immer 0. Die Tasten bekommen Werte von 1-6. Und bei jeder "loslass"-Flanke checkt man das Array und entfernt die Taste daraus bzw. schiebt alles eins nach vorne. Hab da zuerst viel zu komplex gedacht...
Und als aller erstes die Entprellung der Tasten nicht vergessen. Ansonsten wird das lustig mit der Flankenerkennung.
N. M. schrieb: > Und als aller erstes die Entprellung der Tasten nicht vergessen. > Ansonsten wird das lustig mit der Flankenerkennung. Wenn man genau drüber nachdenkt, dann ist das bei der Anwendung hier allerdings unkritisch. Höchstens einer drückt die Tasten im ms-Abstand UND es kommt dann tatsächlich noch auf die Reihenfolge an... Aber dann muss man gleich auch die Frage beantworten: was gilt denn dann als "zuerst betätigt"? Der Taster, der zuerst Kontakt gegeben hat, oder der, der sich zuerst "beruhigt" hat?
Lothar M. schrieb: > was gilt denn dann > als "zuerst betätigt"? Der Taster, der zuerst Kontakt gegeben hat, oder > der, der sich zuerst "beruhigt" hat? Ich glaub das wäre egal, wenn man die Tasten alle 1ms einliest. Beim Interrupt würde ich vllt. die Flanke nehmen, aber ohne könnte auch folgendes passieren: - beide Taster sind 0 (Zeitpunkt 0.0ms) - T1 wird gedrückt (Zeitpunkt 0.2ms) - T2 wird gedrückt (Zeitpunkt 0.8ms) - Tasten werden eingelesen => beide 1 (Zeitpunkt 1.0ms) Was war dann nun zu erst - beide gleichzeitig? Aber das liegt dann an der Abtastung. Kommt auf die Anforderung an.
Adam P. schrieb: > Beim Interrupt Zur Lösung dieser Aufgabe wird (zumindest nach bisherigen Anforderungen) kein Interrupt benötigt (bisher noch nicht mal der des millis()-Timers, der sowieso läuft). > Was war dann nun zu erst - beide gleichzeitig? Jetzt wirds philosophisch, denn im echten Leben passiert nichts "gleichzeitig". Da sind immer ein paar fs oder gar ps dazwischen. Schon insofern kann man sich diese "Gleichzeitigkeitsdiskussion" schenken. Und natürlich besonders auch, weil Mechanik bis hin zum mechanischen Kontakt im Spiel ist und Spiel hat.
Lothar M. schrieb: > Wenn man genau drüber nachdenkt, dann ist das bei der Anwendung hier > allerdings unkritisch. Was den Endzustand angeht wahrscheinlich schon. Ich habe mir gerade nur das Feuerwerk im Hintergrund vorgestellt bzgl. Listen oder Reihenfolgen umsortieren wenn die Taster prellen. Lothar M. schrieb: > was gilt denn dann als "zuerst betätigt"? Der Taster, der zuerst Kontakt > gegeben hat, oder der, der sich zuerst "beruhigt" hat? Man könnte ja auch entprellen und sich den Timestamp der Pegelwechsel (ungefiltert) merken.
N. M. schrieb: > Man könnte ja auch entprellen und sich den Timestamp der Pegelwechsel > (ungefiltert) merken. Mit einem Timestamp ist es noch einfacher: man fragt einfach in jedem Durchlauf ab, ob der Taster x gedrückt ist. Falls nicht, trägt man die aktuelle Zeit in den Speicherplatz für den Taster x ein. Aber falls der Taster x gedrückt ist, dann wird nichts geändert und es bleibt der letzte Zeitpunkt drin, an dem er nicht betätigt war.
Vielleicht sollte man die ganze Entprell-Geschichte hier vorerst beenden und den TO erstmal die Hauptfunktionalität schreiben lassen :) Einfach jede 10 oder 100ms einlesen und schauen ob der Rest funktioniert, verfeinern kann man immer noch. Hab da so den Eindruck, dass solche Diskussionen (auch wenn wichtig) einige Anfänger eher überfordern als helfen.
Adam P. schrieb: > Einfach jede 10 oder 100ms einlesen Nein, ich würde hier die Zeit samt Prellen komplett ignorieren. Man muss sich nicht in Zeiten pressen, wo keine Zeit nötig ist. Denn auch wenn es allzu menschlich ist, in Zeiten statt in Zuständen zu denken, so sind hier zu Lösung der Aufgabe nur Zustände interessant. Denn wenn der H1 und der H2 nacheinander gedrückt wurden, dann der H3 gedrückt wird und prellt, und danach der H4 gedrückt wird und prellt, dann muss halt der zeitliche Abstand zwischen dem Betätigen von H3 und H4 so lang sein, dass das Prellen kein Thema ist. Und dann wird durch das Prellen nur am Ende der Tabelle der H3 ein paar mal eingetragen und wieder gelöscht.
Es sind schlussendlich auch keine Taster sondern Helligkeitstransistoren, ich wollte es einfach zum vereinfacht darzustellen mit Taster zeigen.
Elektro F. schrieb: > Es sind schlussendlich auch keine Taster sondern > Helligkeitstransistoren Je nach Beschaltung, hätten wir uns da aber die ganze Entprell-Geschichte sparen können! ...
Adam P. schrieb: > Je nach Beschaltung, hätten wir uns da aber die ganze > Entprell-Geschichte sparen können! ... Welche ganze Geschichte denn? Entprellen ist doch nur die Lib im Timerinterrupt einbinden und dann im Main das Eventbit testen. Da die Mainloop keinerlei Zeit benötigt, geht aber auch ein 10ms Delay für den Libaufruf. Oder auch meine Macrovariante.
Peter D. schrieb: > Entprellen ist doch nur die Lib Ja...die eine Sache ist, einfach was verwenden und nich wissen was da eigentlich passiert - oder - es verstehen und selbst schreiben. Ich verwende selbst bei Arduino so gut es geht keine Libs. Die können so funktionieren wie man es sich wünscht, müssen aber nicht, schon alles erlebt. Es war auf das ganze Gespräch bzgl. Entprellen bezogen.
Gast
#6963377
Adam P. schrieb: > Ich verwende selbst bei Arduino so gut es geht keine Libs. Ich verwende auch nur wenige. Aber ich gucke gerne von open-source ab, deswegen finde ich schon gut, dass so vieles veröffentlicht wurde.
Elektro F. schrieb: > Es sind schlussendlich auch keine Taster sondern Helligkeitstransistoren Und das Ganze ist final auch nur ein Teil der üblichen Salami...
Gast
#6963502
tldr; Was ich vermisse in der ganzen Diskussion ist das Stichwort 'queue'...
Klaus schrieb: > Was ich vermisse in der ganzen Diskussion ist das Stichwort 'queue'... Das ist der neudeutsche Ausdruck für einen Ringpuffer. Und der war schon recht bald im Gespräch. Ein weiterer Name wäre auch Fifo. Allerdings funkt dabei das "loslassen und nochmal drücken" ganz heftig dazwischen...
Lothar M. schrieb: > Mit einem Timestamp ist es noch einfacher: man fragt einfach in jedem > Durchlauf ab, ob der Taster x gedrückt ist. > Falls nicht, trägt man die aktuelle Zeit in den Speicherplatz für den > Taster x ein. Der beigefügte Entwurf versucht die Idee umzusetzen. Ist etwas gesprächig, Led 99 meint keine LED an.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
Gelegentliches Prellen inklusive, stört aber nicht weiter
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Gast
#6963607
Auch "Warteschlange" wäre richtig, wird allerdings von jedem verstanden.
Gast
#6963617
LostInMusic schrieb: > Auch "Warteschlange" wäre richtig, wird allerdings von jedem verstanden. Das darf natürlich nicht sein, ist zu einfach.
Elektro F. schrieb: > Es sind schlussendlich auch keine Taster sondern > Helligkeitstransistoren, ich wollte es einfach zum vereinfacht > darzustellen mit Taster zeigen. beschreib doch mal dein PROBLEM (den Anwendungsfall), und nicht deine vermeintliche LÖSUNG. (Tasten, Lampen an oder aus etc)
Gast
#6963730
Lothar M. schrieb: > Klaus schrieb: >> Was ich vermisse in der ganzen Diskussion ist das Stichwort 'queue'... > Das ist der neudeutsche Ausdruck für einen Ringpuffer. Und der war schon > recht bald im Gespräch. Ein weiterer Name wäre auch Fifo. Genau das meine ich damit: Mit jedem dieser Begriffe kann Elektro F. offensichtlich absolut gar nichts anfangen. Merkt denn keiner, dass ihr den guten Mann komplett überfordert? Und dann noch ablenkende Zwischenrufe wie "Listen oder Reihenfolgen umsortieren wenn die Taster prellen"... Leute, bitte !!! Ich hab so eine dumpfe Ahnung, dass Elektro F. eigentlich was total Banales bauen will. Der verquirkten Beschreibung nach bin ich mir da sogar fast sicher. Irgendwas wie 6 Lichtschranken/Bewegungsmelder (in sich kreuzenden Fluren?), dazu 6 Leuchten, die er der Reihe nach einschalten will - und die sich verzögert wieder ausschalten sollen? Aber macht mal wie ihr denkt, für so komplexe Probleme bin ich zu einfältig...
Klaus schrieb: > Mit jedem dieser Begriffe kann Elektro F. offensichtlich absolut gar > nichts anfangen. Darf man deshalb diese Begriffe nicht verwenden? Muss man sich eine weichgespülte Version dieser Begriffe überlegen? > Und dann noch ablenkende Zwischenrufe wie "Listen oder Reihenfolgen > umsortieren wenn die Taster prellen"... Ja, da hätte er leichter mal gleich nicht mit Tastern angefangen, die kurz danach wie Schalter rasten und letztlich dann nocht zu Transistoren mutieren. > Irgendwas wie 6 Lichtschranken/Bewegungsmelder > dazu 6 Leuchten, die er der Reihe nach einschalten will > und die sich verzögert wieder ausschalten sollen? Und wofür bräcuhte man da eine Abhängigkeit untereinander? Aber ich hätte da auch noch ein paar solcher Ideen, die würden den TO aber noch mehr verwirren. > Ich hab so eine dumpfe Ahnung Ja, da kann nur einer Licht ins Dunkel bringen. Und der beste Ansatz ist eben wie üblich, nicht die geplante Lösung, sondern die eigentliche Aufgabe zu beschreiben. Elektro F. schrieb: > Bei drei Tastern hätte ich es geschafft Dann zeig doch mal, wie du das mit 3 Tasten machen würdest. Vielleicht klappt ja der Weg übers Reengineering besser... ;-)
Ich denke ich würde die Pins für Taster und LED-Diode in ein Struct packen. Für die Reihenfolge kommt dann eine doppelt verkettete Liste zum Einsatz. Das sieht dann ungefähr so aus:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
Die Flankenerkennung ob ein Taster gedrückt oder losgelassen wird sieht dann so aus:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
Dann fehlen noch removeThingie() und addThingie(), die die doppelt verkettete Liste verwalten. Als Startpunkt dient hier DVListStart. next und prev dienen zum durchhangeln durch die Liste. Eventuell sollten removeThingie() und addThingie() noch das Update der LEDs übernehmen.
Anbei mal ein fertiger Code (ungetestet). Die Pins habe ich von 1..12 durchnumeriert, da muß man dann die gewünschte Zuordnung eintragen. Ein Entprellen ist nicht nötig. Zur Übersicht habe ich alle Schritte in kleine Funktionen unterteilt. In der Loop sieht man schön das EVA-Prinzip. Der mit Abstand schwerste Schritt war aus den verschiedensten Textschnipseln den (hoffentlich korrekten) Ablauf herzuleiten.
Peter D. schrieb: > Anbei mal ein fertiger Code (ungetestet). läuft perfekt mit zwei Ergänzungen: a) in Setup() die pinModes festlegen, sonst sieht man nichts
1 | |
2 | |
3 | |
4 | |
5 | |
b) in input_keys() musste ich negieren, bei meiner "Hardware" ist key pressed LOW/FALSE
1 | |
Bin ja gespannt ob sich der TO nochmal meldet.
Helmut H. schrieb: > Bin ja gespannt ob sich der TO nochmal meldet. Ja evtl. war das alles mal wieder für die Katz...
Danke Leute für die vielen Beispiele und Denkenssprünge. Ich habe es nun geschaft, ich werde den Code noch ein wenig verschönern und den Variablen bessere Namen geben. Anschliessend lade ich den Code hier rauf.
Hier ist noch der fertige Code
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
128 | |
129 | |
130 | |
131 | |
132 | |
133 | |
134 | |
135 | |
136 | |
137 | |
138 | |
139 | |
140 | |
141 | |
142 | |
143 | |
144 | |
145 | |
146 | |
147 | |
148 | |
149 | |
150 | |
151 | |
152 | |
153 | |
154 | |
155 | |
156 | |
157 | |
158 | |
159 | |
160 | |
161 | |
162 | |
163 | |
164 | |
165 | |
166 | |
167 | |
168 | |
169 | |
170 | |
171 | |
172 | |
173 | |
174 | |
175 | |
176 | |
177 | |
178 | |
179 | |
180 | |
181 | |
182 | |
183 | |
184 | |
185 | |
186 | |
187 | |
188 | |
189 | |
190 | |
191 | |
192 | |
193 | |
194 | |
195 | |
196 | |
197 | |
198 | |
199 | |
200 | |
201 | |
202 | |
203 | |
204 | |
205 | |
206 | |
207 | |
208 | |
209 | |
210 | |
211 | |
212 | |
213 | |
214 | |
215 | |
216 | |
217 | |
218 | |
219 | |
220 | |
221 | |
222 | |
223 | |
224 | |
225 | |
226 | |
227 | |
228 | |
229 | |
230 | |
231 | |
232 | |
233 | |
234 | |
235 | |
236 | |
237 | |
238 | |
239 | |
240 | |
241 | |
242 | |
243 | |
244 | |
245 | |
246 | |
247 | |
248 | |
249 | |
250 | |
251 | |
252 | |
253 | |
254 | |
255 | |
256 | |
257 | |
258 | |
259 | |
260 | |
261 | |
262 | |
263 | |
264 | |
265 | |
266 | |
267 | |
268 | |
269 | |
270 | |
271 | |
272 | |
273 | |
274 | |
275 | |
276 | |
277 | |
278 | |
279 | |
280 | |
281 | |
282 | |
283 | |
284 | |
285 | |
286 | |
287 | |
288 | |
289 | |
290 | |
291 | |
292 | |
293 | |
294 | |
295 | |
296 | |
297 | |
298 | |
299 | |
300 | |
301 | |
302 | |
303 | |
304 | |
305 | |
306 | |
307 | |
308 | |
309 | |
310 | |
311 | |
312 | |
313 | |
314 | |
315 | |
316 | |
317 | |
318 | |
319 | |
320 | |
321 | |
322 | |
323 | |
324 | |
325 | |
326 | |
327 | |
328 | |
329 | |
330 | |
331 | |
332 | |
333 | |
334 | |
335 | |
336 | |
337 | |
338 | |
339 | |
340 | |
341 | |
342 | |
343 | |
344 | |
345 | |
346 | |
347 | |
348 | |
349 | |
350 | |
351 | |
352 | |
353 | |
354 | |
355 | |
356 | |
357 | |
358 | |
359 | |
360 | |
361 | |
362 | |
363 | |
364 | |
365 | |
366 | |
367 | |
368 | |
369 | |
370 | |
371 | |
372 | |
373 | |
374 | |
375 | |
376 | |
377 | |
378 | |
379 | |
380 | |
381 | |
382 | |
383 | |
384 | |
385 | |
386 | |
387 | |
388 | |
389 | |
390 | |
391 | |
392 | |
393 | |
394 | |
395 | |
396 | |
397 | |
398 | |
399 | |
400 | |
401 | |
402 | |
403 | |
404 | |
405 | |
406 | |
407 | |
408 | |
409 | |
410 | |
411 | |
412 | |
413 | |
414 | |
415 | |
416 | |
417 | |
418 | |
419 | |
420 | |
421 | |
422 | |
423 | |
424 | |
425 | |
426 | |
427 | |
428 | |
429 | |
430 | |
431 | |
432 | |
433 | |
434 | |
435 | |
436 | |
437 | |
438 | |
439 | |
440 | |
441 | |
442 | |
443 | |
444 | |
445 | |
446 | |
447 | |
448 | |
449 | |
450 | |
451 | |
452 | |
453 | |
454 | |
455 | |
456 | |
457 | |
458 | |
459 | |
460 | |
461 | |
462 | |
463 | |
464 | |
465 | |
466 | |
467 | |
468 | |
469 | |
470 | |
471 | |
472 | |
473 | |
474 | |
475 | |
476 | |
477 | |
478 | |
479 | |
480 | |
481 | |
482 | |
483 | |
484 | |
485 | |
486 | |
487 | |
488 | |
489 | |
490 | |
491 | |
492 | |
493 | |
494 | |
495 | |
496 | |
497 | |
498 | |
499 | |
500 | |
501 | |
502 | |
503 | |
504 | |
505 | |
506 | |
507 | |
508 | |
509 | |
510 | |
511 | |
512 | |
513 | |
514 | |
515 | |
516 | |
517 | |
518 | |
519 | |
520 | |
521 | |
522 | |
523 | |
524 | |
525 | |
526 | |
527 | |
528 | |
529 | |
530 | |
531 | |
532 | |
533 | |
534 | |
535 | |
536 | |
537 | |
538 | |
539 | |
540 | |
541 | |
542 | |
543 | |
544 | |
545 | |
546 | |
547 | |
548 | |
549 | |
550 | |
551 | |
552 | |
553 | |
Was, glaubst Du, hat wohl diese Zeile zu bedeuten?: Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang Man, wie ich diese 12 Meter langen Postings hasse...!
Gast
#6985482
das sollte die Forensoftware mal blockieren oder automatisch in Anhang wandeln wenn Text in C oder Code Tags länger als ein Limit sind.
Elektro F. schrieb: > Hier ist noch der fertige Code Wirst Du nach Programmzeilen bezahlt? Da siehst Du ja nichtmal selber mehr durch. Was soll der Quatsch, einem float ein bool zuzuweisen?
Gast
#7019145
Sorry, erst im nachhinein gemerkt. Hier nochmals als Datei:
Gast
#7019710
Ich bin schwer beeindruckt! u.A. auch von der Unzahl Warnungen Leider kann ich dem Programm keinen Sinn und Zweck entnehmen. Und deinen Beschreibungen hier im Thread auch nicht wirklich. Das alles ist wirklich gut verschlüsselt. Ich kann das Programm nicht "lesen". Ein paar Sachen stören mich beim "lesen" - durchnummerierte Variablen - Funktionen mit über 25 Zeilen, naja - komplizierte Bedingungen in if Statements - geschachtelte if Blöcke, so ab ca 2 bis 3 Wenn ich nur begreifen würde, was es tun soll ....
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.