Hallo Leute,
ich stehe gerade vor der Entscheindung, ob ich für ein Projekt auf das altbewährte, für Masochisten gut geeignete, MFC oder mal etwas 'anderes', QT, einsetze.
Leider habe ich für diesen Entscheidungsprozess nicht viel Zeit und hoffe auf eure (schnellen, kurzen) Auskünfte.
Ich brauche ein Framwork, dass mittels einer kostenlosen IDE entwickelt werden kann. Dabei ist das Drag&Drop der Steuerelemente wichtig, so wie ich es aus VS(6, .Net, 2005) kenne.
Des Weiteren muss die später kompilierte Exe unter Windows 2000/XP/Vista ohne eine zusätzliche Installation von Laufzeitbibliotheken oder Ähnlichem laufen. Sie muss auf jedem Windows von USB-Stick startbar sein, bzw. einfach von einem Server auf jedem Client laufen.
Lediglich auf dem Entwicklungssystem dürfen zusätzliche includes, Libs etc. liegen.
Sind diese Anforderungen durch QT erfüllbar??
mfg
Christian
[gelöst] Allgemeine Frage zum einsatz von QT
[gelöst] Allgemeine Frage zum einsatz von QT
Zuletzt geändert von bw1faeh0 am 11. Oktober 2007 10:06, insgesamt 1-mal geändert.
Ja, wobei Du wenn Du es von überall sofort starten willst, evtl. Qt statisch übersetzen solltest. Sonst musst Du immer die DLLs von Qt mit im selben Verzeichnis wie deine Anwendung mitliefern.
Was ich nicht verstehe ist der Satz:
Was ich nicht verstehe ist der Satz:
einfach von einem Server auf jedem Client laufen
Bitte seid so nett und ändert den Titel von Beiträgen die gelöst wurden, auf [gelöst] Beitragstitel
zu dem nicht verstandenem satz:
du hast im firmennetzwerk einen fileserver. auf dem liegt die exe. nun gehst du von firmenrechner zu firmenrechner und willst von jedem mal die exe starten, die auf dem server liegt
also damit meine ich auch nur, dass ich nicht überall die bibos mit installieren kann
statisch kompilieren geht also? das klingt gut.
habt ihr spontan eine idee für einen GUI-Builder??
VS habe ich in der Version .Net 2003 Prof vorliegen. habe schon an manchen stellen gelesen, dass man damit arbeiten kann. aber beinhaltet das einen GUI-Builder?
mfg
Christian
du hast im firmennetzwerk einen fileserver. auf dem liegt die exe. nun gehst du von firmenrechner zu firmenrechner und willst von jedem mal die exe starten, die auf dem server liegt
also damit meine ich auch nur, dass ich nicht überall die bibos mit installieren kann
statisch kompilieren geht also? das klingt gut.
habt ihr spontan eine idee für einen GUI-Builder??
VS habe ich in der Version .Net 2003 Prof vorliegen. habe schon an manchen stellen gelesen, dass man damit arbeiten kann. aber beinhaltet das einen GUI-Builder?
mfg
Christian
Der GUI Builder nennt sich bei Qt Designer und wenn Du nicht auf eine nahtlose Integration in die IDE bestehst, dann funktioniert der mit allen Entwicklungsumgebungen. Ansonsten gibt's Eclipse mit integriertem PlugIn (hab ich selbst aber noch nie verwendet).
Bitte seid so nett und ändert den Titel von Beiträgen die gelöst wurden, auf [gelöst] Beitragstitel
Qt ist aber nicht umsonst, vergiss das nicht. So lange ihr es nur intern nutzt oder noch besser, bereit seid die Sourcen offen zu legen, ist es ok. Wenn ihr jedoch Software verkaufen wollt wird es teuer.
Die deutsche Schriftsprache ist case-sensitive. Außerdem gibt es eine Interpunktionsnorm. Wenn manch einer seine Programme genauso schlampig schreibt, wie sein Posting hier, dann sollte er es lieber bleiben lassen.
Qt is buggy. Für mich der ausschlaggebende Punkt, dass ich es in
einem neuen Projekt nicht mehr nehmen würde.
Auch in der Version 4.3.2 wurde keiner der Fehler behoben,
die mich in meinem ca. 3MB (reiner C++ Sourcecode) z.Zt. annerven.
Darunter ein ganz fieser, betrifft QMdiArea (hat mehrere BUGS!!!),
der beim Schliessen des 'Area u.U.; selten, daher fies; zum Absturz führt,
weil SubWindows, die geschlossen/gelöscht wurden, als noch aktiv gelistet werden.
PS: Ich musste letztens auch feststellen, dass ein Arbeiten mit den
Nightly Builds überhaupt nicht möglich ist !!! Kommt man keine 2 Meter mit
einem neuen Projekt nicht mehr nehmen würde.
Auch in der Version 4.3.2 wurde keiner der Fehler behoben,
die mich in meinem ca. 3MB (reiner C++ Sourcecode) z.Zt. annerven.
Darunter ein ganz fieser, betrifft QMdiArea (hat mehrere BUGS!!!),
der beim Schliessen des 'Area u.U.; selten, daher fies; zum Absturz führt,
weil SubWindows, die geschlossen/gelöscht wurden, als noch aktiv gelistet werden.
PS: Ich musste letztens auch feststellen, dass ein Arbeiten mit den
Nightly Builds überhaupt nicht möglich ist !!! Kommt man keine 2 Meter mit
Ich habe keinen Bug Report an TrollTech gegeben.
Wie gesagt: In Einzelfällen, deren Ursache ich nicht kenne,
werden gelöschte Widgets nicht aus der internen "SubWindowListe"
des QMdiArea NICHT entfernt.
Beim Schliessen des QMdiArea später kommt es dann logischerweise
zum Crash, da es versucht, MdiSubWindows zu löschen, die gar nicht
mehr da sind:
Anbei die "kritische Stelle" in updateActiveWindow(int removedIndex):
// Check if active window was removed
if (indexToNextWindow - 1 == removedIndex) {
activateWindow(childWindows.at(removedIndex));
} else if (indexToNextWindow == 0 && removedIndex == childWindows.size()) {
"indexToNextWindow" war 0...
Und es sind defintiv noch mehr Bugs drin. Einer davon:
Maximierte Fenster können u.U verschoben werden...
Aber egal, ich habe drumherum gearbeitet. Trotzdem suboptimal
Wie gesagt: In Einzelfällen, deren Ursache ich nicht kenne,
werden gelöschte Widgets nicht aus der internen "SubWindowListe"
des QMdiArea NICHT entfernt.
Beim Schliessen des QMdiArea später kommt es dann logischerweise
zum Crash, da es versucht, MdiSubWindows zu löschen, die gar nicht
mehr da sind:
Anbei die "kritische Stelle" in updateActiveWindow(int removedIndex):
// Check if active window was removed
if (indexToNextWindow - 1 == removedIndex) {
activateWindow(childWindows.at(removedIndex));
} else if (indexToNextWindow == 0 && removedIndex == childWindows.size()) {
"indexToNextWindow" war 0...
Und es sind defintiv noch mehr Bugs drin. Einer davon:
Maximierte Fenster können u.U verschoben werden...
Aber egal, ich habe drumherum gearbeitet. Trotzdem suboptimal
-
Christian81
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Selten so gelacht, was hat denn das eine mit dem anderen zu tun?marcb hat geschrieben:Ich bewege mich im professionellen Bereich, habe mein 1. Programm vor 17 Jahren geschrieben
Mit der kommerziellen Qt-Version, die man im professionellen Bereich meistens hat, hat man einen direkten, sehr guten Draht zum Support und die helfen einem auch. Bisher wurden alle Fehler, die ich gemeldet habe und wenn es denn auch Fehler waren, beseitigt. Melden sollte man sie aber.Die deutsche Schriftsprache ist case-sensitive. Außerdem gibt es eine Interpunktionsnorm. Wenn manch einer seine Programme genauso schlampig schreibt, wie sein Posting hier, dann sollte er es lieber bleiben lassen.
Das "Problem" kennen wir hier auch.werden gelöschte Widgets nicht aus der internen "SubWindowListe"
Das "Problem" ist aber nicht, das die QT da direkt was falsch macht, sondern einfach anders rangeht als man scheinbar von anderen Frameworks gewohnt ist.
Fenster in einer MDI Area werden halt nicht geloescht, sondern nur "unsichtbar" geschalten.
Mit etwas Feinarbeit (abfangen von Events) bekommt man aber auch ein eher windows typisches Verhalten hin, also das Qwidget wird beim Schliesen (x button im fenstermenu). zerstoert und ordnungsgemaess aus allen Listen entfernt. Iss halt bisserl von hinten durch die Brust ins auge.
Die QT Philosophie ist halt eine andere, das widget selber wird gecasht, und muss sich beim aktivieren (oeffnen) jedesmal auch updaten, und im Widget selber hat man keine kontrolle ob man neu aufgerufen wurde oder einfach nur aus der versenkung (cash) wieder hervorgeholt wurde.
Beides hat vorteile und nachteile.
Ciao ...