Eclipse + QT

C/C++

Tisztelt publikum!

Nem olyan rég kezdtem el foglalkozni a fenti párossal régebben delphit használtam és ott volt néhány kényelmi funkció amit nem találok az eclipse -ben. Nagy érdekelne hogy tudom az alábbiakat megoldani:

Kód kiegészítés formoknál nem megy tapasztalatom szerint.
Ha készítek egy formot amin sok-sok vizuális elem van majd kódból hivatkozni akarok rá akkor nem egészíti ki!
pl.: Ha szeretnék egy ilyen utasítást létrehozni: ui.label1->setText() akkor ui. + -re nem jön fel semmi! (normál változóknál működik)

Hibakeresés változó tartalmának megtekintése nem megy
Van egy QString típusú változóm szeretném a tartalmát megnézni hibakeresés közben, rendben meg áll a törésponton ott a változóm, de csak pointert kapok. Hogyan tudom megnézni a tartalmát ?

Deklaráció -ból hogyan tudok vázat készíteni?
Osztály váz létrehozásában segít az eclipse, de ha azt osztályban új tag függvényt akarok létrehozni headerben megadom a függvény nevet paramétereket akkor van-e rá lehetőség hogy egy gombnyomásra elkészítse a cpp-ben a vázát?

Program verziók:
- Qt: 4.4.0
- Eclipse Version: 3.3.2
Build id: M20080221-1800
- Qt C++ Eclipse Integration Version: 1.4.0
- Platform : Ubuntu linux 8.04

Előre is köszönök minden építő jellegű választ!

  • 1741 megtekintés

( emberk | 2008. 07. 02., sze – 16:49 )

Kdevelop? Nem próbáltad C++ hoz és qt-hez szerintem jobb, bár én eclipset vagy 2-3 éve próbáltam.

( bandix | 2008. 07. 02., sze – 18:02 )

Szerintem a debug funkciókat nem az IDE-nek, hanem a nyelvnek kell(ene) biztosítania, és a Qt ezt biztosítja is.

qDebug(QString) vagy qDebug() << QString a te barátod szerintem.

Ez fordításidőben strippelhető a binárisról.
Ebben az esetben pedig QDevelop cvs változata jó választás lehet IDE-nek.
____________________________________________________________
Slackware 12.1 - linux-2.6.25.6 - KDE 3.5.9

( tr3w v | 2008. 07. 02., sze – 18:08 )

Kódkiegészítés:
A kutya ott van elásva, hogy ha összehuzogatod a form-ot, és lemented, akkor csak egy .ui fájlt kapsz, ami nem C++ kód, tehát a kiegészítés nem tud vele mit kezdeni. A megoldás az, hogy nyomsz egy fordítást, ekkor legenerálódnak a .h fájlok, és ezután (többnyire) működik a kiegészítés.

Hibakeresés:
Sajnos a QString annyira trükkös, hogy a gdb nem tud vele mit kezdeni.
elvileg a "this->d->data" mutat a tartalomra, ami egy short unsigned int*. Ha megnézed a memóriát ahova mutat (ASCII-ben), akkor már látod.

Ennél lényegesen egyszerűbb egy qDebug(qPrintable(str));.

Deklarációból vázat:
Szerintem sehogy... Én kerestem sokat, és nem találtam, igaz a Ganymede, és az új CDT óta nem néztem. Amit ajánlok neked is, hogy telepítsd, valamivel jobb a kódkiegészítés...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Kódkiegészítés:
Amit írsz az így rendben is van én is erre jutottam, de a fejlesztés kényelme szempontjából jó lenne ha ez menne (nem kellene designerben nézni hogy tulajdon kép mi is a grafikus objektumnak a neve majd ha megvan hogy mondjuk ez egy QDateEdit akkor ennek is adná a tagfüggvényeit stb.)
Valószínű azt kellene elérni hogy az ui.ból generált headert valahogy dolgozza fel a kódkiegészítő része az eclipse-nek na de hogyan ?

Hibakeresés:
qDebug-os megoldást használom jelenleg, de valljuk meg őszintén nem ez a hatékony megoldás.
A QString helyet mondhattam volna mondjuk egy QSqlQuery típusú változót (vagy bármit más objektumot) sokszor jó volna tényleg a debug módban látni az objektum értékét.
Lehet hogy másképp kell felraknom a kérdést: Debug módban hogyan lehet a "castol"-ni úgy a változót hogy lássam az értékét

pelz -nek : qDebug használata 


#include <QDebug>

//majd a kódban:
qDebug() << VALTOZO;

A qDebug fv-es formáját én jobban szeretem, mert nem kell plusz include, és olyan mint a printf.

qDebug("%s %d %x %03f",qPrintable(str),3,0x12,0.03);

A qPrintable a localnak megfelelő kódolásra konvertálja a QStringet...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Kódkiegészítés:
Látom nem érted.
"A megoldás az, hogy nyomsz egy fordítást, ekkor legenerálódnak a .h fájlok, és ezután (többnyire) működik a kiegészítés."

Azaz, ha létrehozod a form-ot, lemented, majd fordítasz egyet, onnantól létezik a .h fájl, amit az eclipse be is indexel magától, és ekkortól működik a kódkiegészítés.

Hibakeresés:
Megszokás kérdése. Én csak legvégső esetben használom a debug-ot, főleg, mert többszálú programnál szinte teljesen értelmetlen...

"Debug módban hogyan lehet a "castol"-ni úgy a változót hogy lássam az értékét"
???

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Kódkiegészítés:
Közben rá jöttem a megfejtésre!
Létrehozom az ui -t, fordítás létrejönnek a headerek (ui_*.h)
A gond az ott volt hogy a létrejövő ui_*.h -k nem abban az alkönyvtárba generálódnak mint az *.ui-k voltak
Megoldása az ui hoz tartozó class headeréjben az include hivatkozást át kell írni hogy lássa a ui_*.h header-t
esetemben "../" beszúrása!
(Még megoldás lehet az is hogy az ui_*.h kat ugyan abba az alkönyvtárba generálja mint a *.ui-k vannak, ezt a pro állományban lehet kérni UI_HEADERS_DIR -megadásával (nem próbáltam ki) !

Hibakeresés:
Sajnos ez a qDebug() -os módszer elég kényelmetlen mert ha egy változó értekére kíváncsi vagyok akkor módosítanom kell a forrás-t újrafordítani stb. Szóval macerás.
gdb konzoljába írva valami "bűvös szavakat" nem lehet elérni hogy beszedés legyen a változó tartalma?

Nekem ugyanoda hozza létre... Tehát nem kell semmit átírnom.
Egyébként ha nem írod át, akkor is elérhető kell legyen, különben a gcc hogyan fordítaná le?
Ne irogass át semmit, inkább mond meg az eclipse-nek, hogy abban a könyvtárban is nézze a .h-kat...

Szerintem nincsenek bűvös szavak, a gdb ennyit tud (nem tudom más tud-e többet)...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( Rinyu | 2008. 07. 03., cs – 15:52 )

Kodkiegeszites: Kezzel rakod ossze a form-ot/dialog-ot es nem Designer-rel. Nem lesznek UI-k. Aztan abbol orokolsz. Igy mindig lesz kiegeszitesed es nem kell varni egy forditast. Mellesleg jobban megerted a layout-ok mukodeset is.

Csináltam én kézzel is, designerrel is.
Egyszer érdekes szőrözni kézzel, hogy megértsd a dolgokat, de utána nem éri meg, annyival gyorsabb a designer. A kódkiegészítés is működik, sőt, működik az autoconnect is. Rengeteg időt megspórolsz.

Persze van, hogy a designer kevés, akkor lehet kézzel. De ez elég ritka...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o