PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : c-funktionen mit variabler anzahl von parametern



JAF
21-02-2007, 18:51
hi,

ich schreibe gerade ein GTK+ anwendung mit TreeView (also einer tabelle).

dabei moechte ich aber, dass meine tabellen flexibel bleiben, dass heisst...
zur zeit sind es z.b. 8 spalten, 2 davon mit text, der rest mit zahlen, aber vielleicht muss es ich es mal erweitern und dann will ich nicht unbedingt viel aendern muessen.

meine problem: ich muss ich im schon mit


gtk_list_store_new(anzahl der spalten, G_TYPE_STRING, G_TYPE_INT, ...)

oder einer ähnlichen gtk+-funktion sagen, wie viele spalten das sind bzw. was darin gespeichert werden soll. wie mache ich das, wenn ich z.b. 10 felder habe er die funktion dann dementsprechend ausfuehrt (also anzahl auf 10 und 10 mal die datentypen der funktion uebergibt?)

ausserdem wenn ich die struktur fuer eine zeile der tabelle entwerfe (2x string, 6xzahl), kann ich ueberpruefen, wie viele werte das sind in der struktur (also hier 8) gespeichert sind und diese z.b. wie bei einem array nach der reihe - ohne den namen zu kennen - aufrufen? z.b. struktur[0] = erster wert, struktur[1]=2, usw.

hat jemand eine idee was ich bei diesen beiden problemen machen kann?

mfg jaf

JAF
22-02-2007, 11:56
hi, hab das 1. problem schon behoben / eine loesung dafuer gefunden.

ich verwende nun eine andere funktion von GTK+:



static GType t_zelldaten_spalten_typ[] = {
G_TYPE_STRING,
G_TYPE_STRING,
G_TYPE_DOUBLE,
G_TYPE_DOUBLE,
G_TYPE_DOUBLE,
G_TYPE_DOUBLE,
G_TYPE_DOUBLE,
G_TYPE_DOUBLE,
G_TYPE_DOUBLE,
G_TYPE_DOUBLE,
};

//und:

store = gtk_list_store_newv (sizeof(t_zelldaten_spalten_typ)/sizeof(GType), t_zelldaten_spalten_typ);



jetzt bleibt nur mehr die frage:

kann ich anhand von dem "GType t_zelldaten_spalten_typ[]" eine array erzeugen, wo die felder mir genau diese datentypen aufnehmen?
oder hat jemand einen anderen vorschlag dafuer?

mfg jaf

jeebee
22-02-2007, 16:44
dazu machst du ja den ListStore den du dann mit einem TreeView oder ähnlichem anzeigen kannst. (Einige Beispiele auf http://developer.gnome.org/doc/API/2.0/gtk/TreeWidget.html).

JAF
22-02-2007, 17:29
ja, ich weiss, ich speichere auch schon die daten damit und zeige sie an.

also meinst du ich sollte gleich auf das array verzichten und immer nur mit dem ListStore arbeiten und bei den anderen funktionen auch die ListStore abfragen, beim speichern auch direkt vom liststore -> datei und bei laden datei -> liststore?

mfg jaf

jeebee
22-02-2007, 21:26
also bei meinem aktuellen Projekt hab ich die Daten doppelt geführt, wobei ich den ListStore erst erstelle wenn er wirklich benötigt wird. Ich habs vor allem so gelöst, weil ich mich nicht auf den ListStore als Ausgabe beschränken will, sondern die ganze Sache auch im Terminal brauchen will. Wenn du aber eine Anwendung schreibst die sicher nur Gtk als Ausgabe-Möglichkeit braucht, könntest du auch nur mit dem ListStore arbeiten. Allerdings könnte es auch einfacher sein, wenn du zum Einlesen und Speichern noch etwas Eigenes zur Verfügung hast. Was ich in der Beziehung am liebsten habe ist eine GList von eigenen Structs. Bsp:

typedef struct {
gint id;
gchar key[10];
gpointer user_data;
} my_type;

my_type *new_object(gint id, gchar *key, gpointer user_data) {
my_type *new = g_slice_alloc(sizeof(my_type));
new->id = id; snprintf(new->key, 10, "%s", key); new->user_data = user_data;
return new;
}

void save_data(GList *data_list) {
FILE *f = fopen(file, "w");
GList *l = g_list_first(data_list);
while(l != NULL) {
fprintf(f, "%i:%s:%p\n", l->data->id, l->data->key, l->data->user_data);
l = g_list_next(l);
}
fclose(f);
return;
}

GList *read_data() {
FILE *f = fopen(file, "r");
GList *list = NULL;
gchar *buf[512];
gint id;
gchar key[10];
gpointer user_data;
my_type *obj;
while(fgets(buf, sizeof(buf), f) != 0) {
/* daten parsen */
obj = new_object(id, key, user_data);
list = g_list_append(list, obj);
}
return list;
}


int main(int argc, char *argv[]) {
/* ... */
GList *my_data = read_data();
/* ... */
save_data(my_data);
} wäre eine einfache und wohl noch nicht fehlerfreie Variante mit GList und eigenem struct.