Hallo Zusammen,
ich habe in einem etwas umfangreicherm Sketch eine Handvoll Variablen (im 4-stelligen Bereich). Um da etwas Übersicht und "thematische" Trennung hin zu bekommen, würde ich die am liebsten in verschiedenen Reitern unterbringen.
Geht das und wenn ja wie?
Danke schon mal im Voraus.
mach den Reiter als Header Datei (i.e. globals.h) ... und include die Headerdatei mit #include "globals.h"
variablen.h
#pragma once // include guard
extern int globaleVariable; // deklaration
variablen.cpp
#include "variablen.h"
int globaleVariable = 4711; // definition
Beide Dateien als Tab in der IDE anlegen, neben deiner *.ino
Variablentest.ino
#include "variablen.h"
void setup()
{
Serial.begin(9600);
Serial.println(globaleVariable); // nutzung
}
void loop()
{
}
Um da etwas Übersicht und "thematische" Trennung hin zu bekommen, würde ich die am liebsten in verschiedenen Reitern unterbringen.
Das geht auch.
Du solltest aber auch überlegen, welche Variablen gar nicht global gebraucht werden.
Vielleicht werden dann aus einer dreistelligen Anzahl ein paar weniger. Das erhöht auch die Übersicht.
Es kann natürlich auch mehrere .h Dateien (und unabhängig davon, wenn du willst) auch .cpp Dateien geben, die dann in separaten Reitern sichtbar werden.
Boah!!! Ihr seid super!!!
Das setze ich mal direkt am WE um- meine Frau wird sich freuen 
Reduzieren kann man da nichts. Kern des Projekts ist ein 7"TFT mit Touch- es gibt (aktuell) 16 verschiedene Seiten, bei der Hauptseite sind einzelne Sektoren in der Gestaltung veränderbar (z.b. Text-Kalender; Tageskalender, Wochenkalender, Monatskalender) Daher haben viele Elemente veränderliche Positionen und Inhalte, so dass ich aus mehreren Unterfunktionen Zugriff auf die Variablen haben muss...
Ich hoffe ihr haut mir das jetzt nicht um die Ohren, weil ich irgendetwas grundlegendes falsch verstanden habe :o
Ja!
Globale Variablen, sind die Pest!
Ich vermeide sie, wo es nur geht.
Gründe, könnte ich einige nennen!
(im 4-stelligen Bereich)
Da kann das zusammenfassen, nach Themenbereichen, auch nur ein Schritt sein.
Es gibt ja noch viel mehr Möglichkeiten Code und Daten zu strukturieren, zu modularisieren.
Reduzieren kann man da nichts. Kern des Projekts ist ein 7"TFT mit Touch- es gibt (aktuell) 16 verschiedene Seiten, bei der Hauptseite sind einzelne Sektoren in der Gestaltung veränderbar (z.b. Text-Kalender; Tageskalender, Wochenkalender, Monatskalender) Daher haben viele Elemente veränderliche Positionen und Inhalte, so dass ich aus mehreren Unterfunktionen Zugriff auf die Variablen haben muss...
Doch doch, da geht mit Sicherheit was!
Aber um Vorschläge zu machen, habe ich zu wenig Überblick über den Code.
Ich bastel die Tage noch etwas am Code- hänge derzeit mit 2 SPI- Modulen die sich gegenseitig bremsen- das will ich noch machen und dann kann ich den mal hier rein setzen... ist aber ein Bandwurm über ca. 15 reiter- das will sich keiner hier antun 
Es gibt (aktuell) 16 verschiedene Seiten, bei der Hauptseite sind einzelne Sektoren in der Gestaltung veränderbar (z.b. Text-Kalender; Tageskalender, Wochenkalender, Monatskalender) Daher haben viele Elemente veränderliche Positionen und Inhalte, so dass ich aus mehreren Unterfunktionen Zugriff auf die Variablen haben muss...
Das Argument gilt nur für dich persönlich, generell bin ich mit combie einer Meinung, dass "reduzieren kann man da nichts" nicht wirklich überzeugt.
Aber hier im Forum einen Sketch mit tausenden Variablen umzustrukturieren und dir vermutlich OOP näher zu bringen, ist auch viel Arbeit. Also, viel Erfolg erstmal am Wochenende.
Gut- ok, dass nichts geht ist übertrieben- man kann da sicher einiges in aarays packen- das hab ich nicht konsequent gemacht... ist halt so wenn so ein Projekt wächst...
Beruflich muss bin ich schon in Industrie 4.0 unterwegs- sprich bei uns läuft alles mit Excel- wenn ich da mal schnell ein kleines Makro machen will, mach ich das auch (inzwischen nicht mehr) einfach mit 2- 3 Zeilen mehr aber simpel... wenn das dann wächst denke ich mir auch "hätte ich mal lieber 2-3 Schleifen in einander geschachtelt bräuchte ich jetzt nur ne Handvoll Werte anpassen".... aber so ist es halt
OT:
Ich dachte immer Excel wäre uralt. (Industrie 3.1 oder so was), und 4.0 heisst, dass man jetzt cloudbasiertes Excel365 verwendet und die Tabellen Microsoft schenkt, damit sie einen hoffentlich wieder dran lassen, wenn sie schon Geld dafür nehmen.
Daher haben viele Elemente veränderliche Positionen und Inhalte, so dass ich aus mehreren Unterfunktionen Zugriff auf die Variablen haben muss...
class Element : public HasPosition
{
protected:
Position position;
public:
virtual void draw(DisplayDriver &display) = 0;
}
Natürlich stark vereinfacht....
Aber so kann jedes Element seine eigene Position beinhalten, und sich selber malen.
Natürlich stark vereinfacht....
Wenn es schon eine BasisKlasse HasPosition gibt, sollte die doch auch die Position haben, oder ?
Hunderte x und y Werte in globalen Variablen zu speichern: Das sollte man schon irgendwohin auslagern, damit man das nicht mit ansehen muss.
Ich bastel am WE mal etwas und dann präsentiere ich mal den aktuellen Stand
Hallo,
habe leider noch nicht ganz begriffen was Du vorhast. Eventuell sind aber mehrdimensionale Felder (Arrays) ein Lösungsansatz. Wenn ich mich da auf Deine Monitor Anwendung beziehen kann könnte das so aussehen
x-Element, y-Element , Seite-Element
z.B
int Wert [5] [5] [5];
Auf diese Art hast Du Zugriff auf z.B 125 verschiedene Variable. Aber es muss natürlich Sinn machen die alle Wert nennen zu können.
Rentner:
Eventuell sind aber mehrdimensionale Felder (Arrays) ein Lösungsansatz.
Nein. Bitte nicht. Schaue dir Strukturen und Klassen an
Aber es muss natürlich Sinn machen die alle Wert nennen zu können.
Und das ist nie der Fall. Es gibt einfache Wege um Daten zu strukturieren bei denen jede Variable einen passenden Namen hat
michael_x:
Wenn es schon eine BasisKlasse HasPosition gibt, sollte die doch auch die Position haben, oder ?
Wie gesagt... es ist nur ein Entwurf....
HasPosition hatte ich eigentlich als Interface gedacht.
In Pascal oder PHP hatte ich es (in etwa) so geschrieben:
class Element implements Position
Denn es ist ja keine "ist eine" Beziehung.
"Element ist eine Position" hört sich irgendwie falsch an.
"Element hat eine Position" hört sich dagegen weit besser an.
Darum dachte ich so spontan, die Position zu einer Eigenschaft des Elements zu machen.
Naja...
Ein Interface soll eigentlich die Implementierung bestimmter Methoden erzwingen und enthält daher nur abstrakte Methoden.
Bei einer Basis-Klasse namens hasPosition nimmt man dann dass diese etwas über die Position enthält. Dann sollte die Position auch in der Basis-Klasse sein. Oder sollte irgendeine andere Interaktion mit der Position stattfinden.
Wenn du "hat ein" statt "ist ein" willst (was im Prinzip hier korrekt ist) dann ist Vererbung aber nicht die Lösung. Sondern die Klasse muss ein Objekt einer Positions-Klasse enthalten. Was auch der Fall ist. Dann braucht man aber das Interface nicht
Leider macht C++ keinen Unterschied, zwischen Interface und Basisklasse.
(das fehlt mir etwas)
Das stimmt so nicht. Interfaces existieren nicht als Konzept wie in C# oder Java (wo sie konsequent in den Framework Libraries verwendet werden), aber sie sind letztlich nur abstrakte Basisklassen die nur abstrakte Methoden enthalten.
Du kannst auch eine abstrakte Basisklasse haben die nicht-virtuelle Methoden oder Variablen enthält.
Also in der Tat, machen für mich Arrays nur begrenzt Sinn... Wenn ich Sensorwerte empfange und im Sketch verarbeite und dann weiter sende habe ich da sehr viele Daten mit identischer Struktur- sowas mache ich auch in einem Array...
Aber wenn ich beispielsweise die Position meiner Uhr ändern will, nehme ich lieber "UhrX" und "UhrY"....