Qt zusammen mit API-nutztender Klasse "ComTools" v
Qt zusammen mit API-nutztender Klasse "ComTools" v
Hallo!
Ich möchte gerne in einem Programm gleichzeitig Qt und eine Klasse "ComTools" zur Komunikation über die Serielle Schnittstelle verwenden. Ich nutze Visual Studio.Net und habe bisher für Qt immer mit einem Makefileprojekt und qmake gearbeitet. Die Klasse ComTools beruht allerdings auf API Funktionen, wofür ich ja ein Win-32 Projekt anlegen müsste meine ich. In die Klasse sind auch noch mehrere Header eingebunden:
- conio.h
- stdio.h
- windows.h
Wie gehe ich jetzt am besten an die Sache heran? Makefileprojekt oder Win-32 Projekt, und was ist dabei zu beachten?
Vielleicht hat ja schonmal jemand ein ähnliches Problem gehabt. Würde mir sehr weiterhelfen.
Gruß Dom!
Ich möchte gerne in einem Programm gleichzeitig Qt und eine Klasse "ComTools" zur Komunikation über die Serielle Schnittstelle verwenden. Ich nutze Visual Studio.Net und habe bisher für Qt immer mit einem Makefileprojekt und qmake gearbeitet. Die Klasse ComTools beruht allerdings auf API Funktionen, wofür ich ja ein Win-32 Projekt anlegen müsste meine ich. In die Klasse sind auch noch mehrere Header eingebunden:
- conio.h
- stdio.h
- windows.h
Wie gehe ich jetzt am besten an die Sache heran? Makefileprojekt oder Win-32 Projekt, und was ist dabei zu beachten?
Vielleicht hat ja schonmal jemand ein ähnliches Problem gehabt. Würde mir sehr weiterhelfen.
Gruß Dom!
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Hallo Christian!
Erstmal danke für deine Antwort.
Nur leider weiß ich nicht wirklich wie ich jetzt damit umzugehen habe. Wie muss ich z.B. vorgehen, wenn ich das weiterhin mit qmake und nem Makefileprojekt erledigen möchte? Ich muss doch sicherlich irgendwo die windows.h und conio.h auftreiben und irgendwie mit einbinden oder? Hab mal im Visual Studio Ordner diese Dateien gesucht. Die windows.h gab es einmal, nur die conio.h leider zweimal und auch verschieden groß... Deshalb käme mir das ganz gelegen, wenn da schon jemand Erfahrung mit hat und mir kurz erklären kann, wie ich da verfahren muss.
Gruß Dom
Erstmal danke für deine Antwort.
Nur leider weiß ich nicht wirklich wie ich jetzt damit umzugehen habe. Wie muss ich z.B. vorgehen, wenn ich das weiterhin mit qmake und nem Makefileprojekt erledigen möchte? Ich muss doch sicherlich irgendwo die windows.h und conio.h auftreiben und irgendwie mit einbinden oder? Hab mal im Visual Studio Ordner diese Dateien gesucht. Die windows.h gab es einmal, nur die conio.h leider zweimal und auch verschieden groß... Deshalb käme mir das ganz gelegen, wenn da schon jemand Erfahrung mit hat und mir kurz erklären kann, wie ich da verfahren muss.
Gruß Dom
-
Querdenker
- Beiträge: 99
- Registriert: 1. Dezember 2005 17:44
- Wohnort: Karlsruhe
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Also ersmal danke für die Anregungen soweit.
Ich habe jetzt schon ein wenig herumprobiert und versuche mal die Problematik noch ein wenig näher zu beschreiben:
ComTools ist nichtmal eine Klasse, sodern einfach ein paar Funktionen,die auf API basieren, die es einem relativ leicht ermöglichen die serielle Schnittstelle zu verwenden. Die Funktionen wurden für die Verwendung in einer Win32 Konsolenanwendung geschrieben. Dort funktionieren sie auch wunderbar. Jetzt habe ich ausprobiert in einem Makefileprojekt mit Qt diese Funktionen einzubinden und aufzurufen. Auch ohne Einbinden von windows.h und conio.h gab es nur zwei kleine Fehlermeldungen wegen einer Typkonvertierung von char[] auf LPCSTR. Da habe ich einfach (LPCSTR) verwendet. Dann ließ sich das Programm ohne Fehler kompilieren. Eine Funktion aus ComTools, mit der man alle seriellen Schnittstellen im PC erkennen und deren Status abfragen kann, lauft in der Konsolenanwendung und gibt mir den richtigen Status der COM-Schnittstellen heraus. Die gleiche Funktion in meinem Makefileprojekt mit Qt gibt mir absurde Werte zurück.
Also kann da irgendwas noch nicht so ganz hinhauen. Auf den Verdacht hin, dass es an meiner nachträglich eingebauten Typkonvertierung liegt, habe ich diese Konvertierung ebenfalls in der Konsolenanwendung eingefügt. Diese gibt mir dann immernoch den korrekten Status der Schnittstellen zurück. Damit ist es schonmal ausgeschlossen, dass der Fehler in der Typkonvertierung liegt.
Da ich nicht so die Erfahrung mit API usw. habe stehe ich nun ziemlich ratlos da und bin auf Hilfe angewiesen.
Würde es eventuell helfen, wenn ich mal meine beiden Projekte mit einer kleinen Beschreibung hochlade? Sind auch och relativ überschaubar gehalten.
Gruß Dominik!
Ich habe jetzt schon ein wenig herumprobiert und versuche mal die Problematik noch ein wenig näher zu beschreiben:
ComTools ist nichtmal eine Klasse, sodern einfach ein paar Funktionen,die auf API basieren, die es einem relativ leicht ermöglichen die serielle Schnittstelle zu verwenden. Die Funktionen wurden für die Verwendung in einer Win32 Konsolenanwendung geschrieben. Dort funktionieren sie auch wunderbar. Jetzt habe ich ausprobiert in einem Makefileprojekt mit Qt diese Funktionen einzubinden und aufzurufen. Auch ohne Einbinden von windows.h und conio.h gab es nur zwei kleine Fehlermeldungen wegen einer Typkonvertierung von char[] auf LPCSTR. Da habe ich einfach (LPCSTR) verwendet. Dann ließ sich das Programm ohne Fehler kompilieren. Eine Funktion aus ComTools, mit der man alle seriellen Schnittstellen im PC erkennen und deren Status abfragen kann, lauft in der Konsolenanwendung und gibt mir den richtigen Status der COM-Schnittstellen heraus. Die gleiche Funktion in meinem Makefileprojekt mit Qt gibt mir absurde Werte zurück.
Also kann da irgendwas noch nicht so ganz hinhauen. Auf den Verdacht hin, dass es an meiner nachträglich eingebauten Typkonvertierung liegt, habe ich diese Konvertierung ebenfalls in der Konsolenanwendung eingefügt. Diese gibt mir dann immernoch den korrekten Status der Schnittstellen zurück. Damit ist es schonmal ausgeschlossen, dass der Fehler in der Typkonvertierung liegt.
Da ich nicht so die Erfahrung mit API usw. habe stehe ich nun ziemlich ratlos da und bin auf Hilfe angewiesen.
Würde es eventuell helfen, wenn ich mal meine beiden Projekte mit einer kleinen Beschreibung hochlade? Sind auch och relativ überschaubar gehalten.
Gruß Dominik!
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Ok. Hier sind dann die beiden Projekte. Müssten nur nocheinmal neu kompiliert werden.
1. Konsolenprojekt:
Hier werden die serielle Schnittstellen auf ihren Status geprüft und ausgegeben:
Die Ausgabe stimmt mit den Erwartungen überein.
2. Qt Projekt:
Hier öffnet sich ein Widget. Bei Drücken des Buttons wird, wie im Konsolenprojekt, der Status ausgegeben.
Die Ausgabe stimmt nicht.
Bei mir werden vorhandene Coms als nicht vorhanden ausgegeben.
Nicht vorhandene als von anderemProgramm verwendete.
Statusausgabe:
0 = Nicht vorhanden
1 = Vorhanden
2 = Vorhanden und von einem anderen Programm benutzt
Gruß Dom!
1. Konsolenprojekt:
Hier werden die serielle Schnittstellen auf ihren Status geprüft und ausgegeben:
Die Ausgabe stimmt mit den Erwartungen überein.
2. Qt Projekt:
Hier öffnet sich ein Widget. Bei Drücken des Buttons wird, wie im Konsolenprojekt, der Status ausgegeben.
Die Ausgabe stimmt nicht.
Bei mir werden vorhandene Coms als nicht vorhanden ausgegeben.
Nicht vorhandene als von anderemProgramm verwendete.
Statusausgabe:
0 = Nicht vorhanden
1 = Vorhanden
2 = Vorhanden und von einem anderen Programm benutzt
Gruß Dom!
- Dateianhänge
-
- Konsolenprojekt.zip
- (13.65 KiB) 220-mal heruntergeladen
-
- Qt Projekt.zip
- (13.54 KiB) 187-mal heruntergeladen
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Abgesehen davon dass deine Schleife im Qt-Projekt falsch ist, habe ich das Problem gefunden. Schau Dir mal den Unterschiede zwischen CreateFileA und CreateFileW an. Qt ist standardmässig ein Unicode-Projekt. Dein (falscher) cast hilft Dir da auch nicht. Wenn man sowas macht sollte man standardmässig immer 'A' oder 'W' dahinter schreiben um Fehler wie deinen zu vermeiden. Ich würde auf jeden Fall immer die Unicode-Variante bevorzugen.
MfG Christian
'Funktioniert nicht' ist keine Fehlerbeschreibung
'Funktioniert nicht' ist keine Fehlerbeschreibung
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Es gibt immer zwei Funktionen - eine Ansi und eine Unicode-Version. Mach Dich mal schalu was ein Unicode-String ist (WinAPI: Unterschied zwischen char, WCHAR und TCHAR bzw. LPSTR, LPWSTR und LPTSTR).
CreateFileA -> Ansi Version
CreateFileW -> Unicode-Version
Im Grunde musst Du aus CreateFile einfach CreateFileA machen damit es geht.
Oder eben alles in Unciode machen
CreateFileA -> Ansi Version
CreateFileW -> Unicode-Version
Im Grunde musst Du aus CreateFile einfach CreateFileA machen damit es geht.
Oder eben alles in Unciode machen
Code: Alles auswählen
WCHAR cName[]="\\\\.\\COM1";
...
CreateFileW(cname,...)
MfG Christian
'Funktioniert nicht' ist keine Fehlerbeschreibung
'Funktioniert nicht' ist keine Fehlerbeschreibung