Moin, ich habe hier ein Programm, das mit Hilfe des Motifwidgets XmFileSelectionBox auf das Dateisystem zugreift, um Dateien zu öffnen bzw. den Namen für neue Dateien in Erfahrung zu bringen. Aus historischen Gründen ist der Code für das Öffnen der Dateien in zwei Moduln untergebracht: In file.c befindet sich der Code, der nur für diese Anwendung geschrieben worden ist, in getfiles.c befinden sich die Teile, die ursprünglich von verschiedenen Anwendungen genutzt worden sind (aber nicht mehr werden). Weil die FSB (FileSelectionBox) auf den Code in file.c zugreifen muß, wird sie in file.c erstellt, dann an eine Funktion in getfiles.c übergeben und ausgeführt. Soweit die Situation. Mein Problem ist folgendes: Für eine Erweiterung der FSB (Anzeigen von versteckten Dateien) muß ich zwei Listen quer durch getfiles.c schleppen. Wie soll ich das machen: 1. Mit modulglobalen Variablen in getfiles.c. 2. In einem Attribut der FSB, wodurch ich den Typ der Listen unnötigerweise auch in file.c bekanntmachen müßte. Eine Übergabe der Listen durch Funktionsparameter kommt nicht in Frage, da einige der Beteiligten Funktionen Prototypfunktionen sind, deren Typ ich nicht ändern kann. Vor globalen Variablen schrecke ich zurück, das habe ich bislang auch nicht gebraucht. Ich hoffe halt, daß es noch eine Lösung gibt, die ich bisher übersehen habe. Wenn etwas unklar ist, bitte ich um Nachfragen, je mehr ich erklären muß, desto besser verstehe ich das Problem. Danke schonmal! Thorsten -- The world is dangerous not because of those who are evil; but because of those who do nothing. - Einstein
On Tuesday 21 October 2003 22:26, Thorsten Haude wrote:
Soweit die Situation. Mein Problem ist folgendes: Für eine Erweiterung der FSB (Anzeigen von versteckten Dateien) muß ich zwei Listen quer durch getfiles.c schleppen. Wie soll ich das machen: 1. Mit modulglobalen Variablen in getfiles.c. 2. In einem Attribut der FSB, wodurch ich den Typ der Listen unnötigerweise auch in file.c bekanntmachen müßte.
Eine Übergabe der Listen durch Funktionsparameter kommt nicht in Frage, da einige der Beteiligten Funktionen Prototypfunktionen sind, deren Typ ich nicht ändern kann.
Vor globalen Variablen schrecke ich zurück, das habe ich bislang auch nicht gebraucht. Ich hoffe halt, daß es noch eine Lösung gibt, die ich bisher übersehen habe.
Es ist schon eine Weile her, daß ich zuletzt Motif programmiert habe...
Du wirst nicht darum herumkommen, diese Listen an das Widget zu hängen; sie
beziehen sich ja wohl auf eine Instanz der XmFileSelectionBox, nicht auf die
Widget-Klasse global.
Wenn Du das nicht tust, ist auch schon egal, ob die Dinger richtig global
sind, oder ob Du statische Variablen (oder per malloc() erzeugte) per
Funktion an die andere Seite übergibst, um sie dort in einer anderen
statischen Variablen abzulegen. Aufpassen mußt Du dann auf jeden Fall, daß Du
die Listen auch wieder richtig abräumst.
Ich weiß, daß das speziell mit Xt/Motif nicht einfach ist, aber hast Du schon
mal daran gedacht, das XmSelectionBox-Widget abzuleiten und um die gewünschte
Funktionalität zu erweitern?
Übrigens: All das sind die Gründe, warum ich schon lange auf C++/Qt
umgestiegen bin. ;-)
CU
--
Stefan Hundhammer
Moin,
* Stefan Hundhammer
On Tuesday 21 October 2003 22:26, Thorsten Haude wrote:
Soweit die Situation. Mein Problem ist folgendes: Für eine Erweiterung der FSB (Anzeigen von versteckten Dateien) muß ich zwei Listen quer durch getfiles.c schleppen. Wie soll ich das machen: 1. Mit modulglobalen Variablen in getfiles.c. 2. In einem Attribut der FSB, wodurch ich den Typ der Listen unnötigerweise auch in file.c bekanntmachen müßte.
Eine Übergabe der Listen durch Funktionsparameter kommt nicht in Frage, da einige der Beteiligten Funktionen Prototypfunktionen sind, deren Typ ich nicht ändern kann.
Vor globalen Variablen schrecke ich zurück, das habe ich bislang auch nicht gebraucht. Ich hoffe halt, daß es noch eine Lösung gibt, die ich bisher übersehen habe.
Es ist schon eine Weile her, daß ich zuletzt Motif programmiert habe...
Du wirst nicht darum herumkommen, diese Listen an das Widget zu hängen; sie beziehen sich ja wohl auf eine Instanz der XmFileSelectionBox, nicht auf die Widget-Klasse global.
Schon, aber die FSB blockt momentan die Anwendung, mehr als eine ist also eh nicht nötig. Allerdings muß das ja nicht immer so bleiben, ein Argument ist das schon. Jetzt fragt sich nur, wie weit man sich C zurechtbiegen soll, um objektorienriert zu werden.
Wenn Du das nicht tust, ist auch schon egal, ob die Dinger richtig global sind, oder ob Du statische Variablen (oder per malloc() erzeugte) per Funktion an die andere Seite übergibst, um sie dort in einer anderen statischen Variablen abzulegen. Aufpassen mußt Du dann auf jeden Fall, daß Du die Listen auch wieder richtig abräumst.
Ich muß sie ja nicht übergeben, die Kapselung wird nur durchbrochen, weil ich mit dem Leben muß, was C für OOP hält. Die FSB hat nur ein Feld, das ich nutzen kann, also muß ich eine Struktur anhängen.
Ich weiß, daß das speziell mit Xt/Motif nicht einfach ist, aber hast Du schon mal daran gedacht, das XmSelectionBox-Widget abzuleiten und um die gewünschte Funktionalität zu erweitern?
Ja, aber nur kurz. Ich habe noch nie ein Motifwidget abgeleitet, und ich will nicht mit einem so wichtigen und komplizierten wie der FSB anfangen.
Übrigens: All das sind die Gründe, warum ich schon lange auf C++/Qt umgestiegen bin. ;-)
Tja, wenn Du ein Qt-Widget nennen kannst, das auch nur annähernd an NEdit's Textwidget heranreicht, ist der erste Schritt zum Umstieg schon getan. Qt müßte dann nur noch auf jedes Unix, Windows, OS/2, MacOS und VMS portiert werden. Thorsten -- A future startup with no patents of its own will be forced to pay whatever price the giants choose to impose. That price might be high: Established companies have an interest in excluding future competitors. - Bill Gates
On Tue, 28 Oct 2003 at 22:20 (+0100), Thorsten Haude wrote:
* Stefan Hundhammer
[2003-10-22 11:31]: Übrigens: All das sind die Gründe, warum ich schon lange auf C++/Qt umgestiegen bin. ;-)
Tja, wenn Du ein Qt-Widget nennen kannst, das auch nur annähernd an NEdit's Textwidget heranreicht, ist der erste Schritt zum Umstieg schon getan.
Das wäre nicht das Problem. Qt kann Motif-Widgets und native Widgets mischen.
Qt müßte dann nur noch auf jedes Unix, Windows, OS/2, MacOS und VMS portiert werden.
Das schon eher. Qt gibt es zwar für Windows und MacOS X aber zumindest die Windows-Version ist weder frei noch kostenlos. Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ "Was wir wissen, ist ein Tropfen; was wir nicht wissen, ein Ozean." -- Isaac Newton
Moin,
* Bernhard Walle
On Tue, 28 Oct 2003 at 22:20 (+0100), Thorsten Haude wrote:
* Stefan Hundhammer
[2003-10-22 11:31]: Übrigens: All das sind die Gründe, warum ich schon lange auf C++/Qt umgestiegen bin. ;-)
Tja, wenn Du ein Qt-Widget nennen kannst, das auch nur annähernd an NEdit's Textwidget heranreicht, ist der erste Schritt zum Umstieg schon getan.
Das wäre nicht das Problem. Qt kann Motif-Widgets und native Widgets mischen.
Ach. Das ist zumindest ein Argument für Qt und gegen GTK. Thorsten -- You get your education from copyrighted books, you get your news from copyrighted papers and TV programs, you get your jobs from copyrighted want ads, you get your entertainment from copyrighted music and motion pictures - every aspect of life is affected by the law of copyright. - L. Ray Patterson
On Tuesday 28 October 2003 22:20, Thorsten Haude wrote:
Übrigens: All das sind die Gründe, warum ich schon lange auf C++/Qt umgestiegen bin. ;-)
Tja, wenn Du ein Qt-Widget nennen kannst, das auch nur annähernd an NEdit's Textwidget heranreicht, ist der erste Schritt zum Umstieg schon getan.
Ich weiß nicht besonders viel von NEdit, aber schau' Dir doch das mal an: http://doc.trolltech.com/3.2/qmultilineedit.html
Qt müßte dann nur noch auf jedes Unix, Windows, OS/2, MacOS und VMS portiert werden.
Alle möglichen Unixe werden unterstützt, Win32 und (AFAIK) MacOS auch. Mit
OS/2 und VMS sieht es natürlich schlecht aus; aber das gilt wohl ganz
allgemein (für das ganze System), nicht nur für Qt.
;-)
CU
--
Stefan Hundhammer
Moin,
* Stefan Hundhammer
On Tuesday 28 October 2003 22:20, Thorsten Haude wrote:
Tja, wenn Du ein Qt-Widget nennen kannst, das auch nur annähernd an NEdit's Textwidget heranreicht, ist der erste Schritt zum Umstieg schon getan.
Ich weiß nicht besonders viel von NEdit, aber schau' Dir doch das mal an:
"This class is obsolete." Das war aber ein Tiefschlag. Thorsten -- begin 666 magritte.txt.vbs Ceci n'est pas un attachement. end
On Wednesday 29 October 2003 22:28, Thorsten Haude wrote:
"This class is obsolete."
Das war aber ein Tiefschlag.
Alte Gewohnheiten sterben nicht so schnell... ;-)
Aber dort steht ja auch gleich, was man stattdessen verwenden soll:
http://doc.trolltech.com/3.2/qtextedit.html
CU
--
Stefan Hundhammer
participants (3)
-
Bernhard Walle
-
Stefan Hundhammer
-
Thorsten Haude