qtforum.de

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

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:

einfach von einem Server auf jedem Client laufen

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

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).

Hallo!

also scheinbar sieht es um QT gut aus. Ich werde mich nun zwei Tage lange mit QT beschäftigen und werde dann meinem Vorgesetztem Alternativen zu MFC vorstellen. QT scheint derzeit auf dem obersten Platz zu stehen

mfg


Christian

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.

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

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.

Ich kann dazu im Task-Tracker nichts finden. Welchen Fehler meinst du?

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

Ich habe keinen Bug Report an TrollTech gegeben.

Hast du überhaupt schon mal einen Bug Report an TrollTech geschrieben?

Wie gesagt: In Einzelfällen, deren Ursache ich nicht kenne,

Ach, und deswegen ist jetzt Qt daran schuld.

Qt is buggy

Auf jeden Fall ein Interessanter Zusammenhang...

Na gut, ich werde zu diesen völlig unsachlichen Posts nichts weiter sagen.

Ich bewege mich im professionellen Bereich, habe mein 1. Programm vor 17 Jahren geschrieben und glaube den Unterschied zwischen selber verursachten Fehlern und den anderen zu kennen.

Schönen Abend!

@marcb: macman hat Recht - wenn man nichts an qt-bugs schreibt kann auch nichts gefixt werden. Meine Bugs wurden bis jetzt immer gefixt...

marcb hat geschrieben:Ich bewege mich im professionellen Bereich, habe mein 1. Programm vor 17 Jahren geschrieben

Selten so gelacht, was hat denn das eine mit dem anderen zu tun? 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.

werden gelöschte Widgets nicht aus der internen "SubWindowListe"

Das "Problem" kennen wir hier auch.
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 ...

Also wir wollen keinerleier der Software kommerziell nutzen. Ein Kunde wird die Produkte nie zu sehen bekommen.
Zusätzlich dazu nutzen wir die Open Source Lizenz und stellen die Software unter GPL. Sie wird ja unser Haus eh nie verlassen