Keresés

Végülis megírtam a GAMBAS2-ben már vagy 1200 sort, működik is az adatbevitel MYSQL szerverrel (localhost).

Elég jól elboldogultam, eddig az elég szegényes dokumentáció mellett is.
Néhány "kész" widgetet újra kellett implementálnom elemi alkotókból a hiányzó event-ek miatt, valamint a bugos table control dataentry miatt is újfajta adatbevitelt kreálnom, de most nagyon hiányzik egy event, hogy ne csak tákolmánynak tűnjön a programom. (databrowser.gridview nem ad eventet, ha kijelölök egy rekordot, pedig nagyon kéne, hogy updatelni tudjam az általam "kézzel" kapcsolt table controlokat. érdekes, hogy a databrowser saját kapcsolt combói és mezői frissülnek klikkre...)
...
valami ötlet esetleg?

Nézd meg az UniPaas-t, látsz csodát. Kicsit egyéni a koncepció, de már több mint 20 éve tartja magát.

Mi "kaptuk" a stuffot, igazából passz, hogy mivel készült, de látszott rajta, hogy generált kód... Mindegy, régen volt, azóta tán ezek a cuccok is okosodtak.

Én igazából csak a M$ query generátorát ismerem. Az nem sokat önállóskodik, azt generálja amit megtervezel. Persze van pár dolog amit nem tud megcsinálni, azt bizony kézzel kell.

Nem a formok forrásán kéziztünk, hanem nagynevű nagytudású cég querydegenerátoránank produktumán.

A query generátor centire olyan query-t generál amit grafikusan megtervezel vele (már legalábbis a normálisak). Ha nem tudod hogy mi mit csinál benne az persze más kérdés. Ugyanez igaz az elterjedtebb form designerekre is (Visual Studió, Delphi). De még ha szart csinálna is - egy szarul legenerált form kód akár 1 mikroszekundumot is lassít a rendszereden. Ezért aztán megéri fél napot kézimunkázni egy-két formon :-)

Ahogy a query-tervezők is bírnak (tisztelet a kivételnek) gyalázatos kódot kiböffenteni magukból, úgy a felhasználói felület vizuális összelapátolására készült eszközök sem minden esetben az optimált kód mintapéldáit generálják le. Gyakorlatilag mindkettő egy struktúrából generál forráskódot, és ez a kódgenerátor rész az, amivel kapcsolatban vannak kellemetlen tapasztalataim.

A programot soha nem fogja megírni helyetted. Query-t segíthet tervezni, esetleg osztálystruktúrát és függvényeket is (akár ORM tetején akár csak sima class diagram szerkesztőként), és persze felületet, reportokat. Ami közte van azt bizony neked kell megcsinálni.

Egy RAD eszköz nem csak felület összedobálására való, legalábbis szerintem...

Mióta generál egy form designer queryket ? A query designer pedig (Pl. a Visual Studióban) olyan query-t generál amilyet mondasz neki. Azt nem mondom hogy utána nem kell hozzányúlni az SQL-hez, de legalább nem kell a táblákból az összes mezőnevet kézzel bepötyögni.

Azért nem ilyen egyszerű a dolog... Láttam ilyen "összekattingatott" sz@rt (alkalmazásnak nem nevezném...), amit alá kellett vetni némi kézi gatyába rázásnak, hogy hozza az elvárt performaciát, mert alaphelyzetben gyalázatosan tré query-ket (de)generált az eszköz...

Na most, nem holtmindegy hogy milyen az a kód amit a cucc gyárt ? Nem neked kell nézni hanem a fordítóprogramnak, annak meg nincsenek esztétikai fenntartásai.

Nem arra készült, ez az egyik. A másik, hogy a sok önjelölt zseni Java-ban hegeszti, ezért kell neki Java futtatókörnyezet. Ilyen összerángatós fosch-okat láttam párat... A nem szép, de csúnya tipikus esete a kód, amit kiböffentenek magukból, úgyhogy maradtam a kézi kódhegggggggesztésnél TOAD-dal...

Alapjaiban rossz az egész. Kezdve azzal hogy nem tusz normális formokat csinálni benne, hogy van vagy 8 féle komponens, se tree, se tabbed notebook, stb. A report generátor vagy nagyon primitív (én erre tippelek) vagy nagyon antiintuitív, de a legprimitívebb lekérdezéseken kívül nem tudom hogy hogyan lehet csinálni vele bármit is (Pl. csoportonkénti összesítések és más alap feature-ök amik egy reportgenerátorban benne vannak). Az egész alatt pedig bézik.
Ja, és mi a búbánatnak ehhez JRE ?

Szvsz nézz meg egy normális fejlesztői környezetet (Delphi, Visual Studio, stb) és akkor nem kérdezel olyat hogy hogy miért szar ez.

Láttam, azért kérdem, hogy milyen feature request-et kellene megereszteni a fejlesztők felé (vagy akár te is megírhatod a neked hiányzó részeket...).

Láttad már ? Persze ha a házi DVD-id nyilvántartását kell megcsinálni arra tökéletes. De ha ügyviteli szoftvert kellene fejlesztenem benne akkor a kardomba dőlnék.

Mi a problémád az OOo Base-zel?

Köszi mindenkinek a segítőkész hozzászólását. A Gambas2-t választottam.

A Kexi ezeket nem/sem tudja (nem lehet adatot bevinni pl. csak táblánként). Ezen az alapon fikázom. Szerintem jogosan.

Így van. megnézem azt is. Ami nekem kell: child form (table control) egy formon, kaszkádolt törlés és frissítés. lehetőleg nem nulláról, mert akkor ugye azt akármilyen programnyelven meg lehet írni...

Hát, szerintem hagyjuk ennyiben, nem hiszem, hogy ebben egyet tudnánk érteni...

PS. Mindenesetre jár neked a pont: megtetted, amit a (45)-ben kértem.

Pl. wikipedia: A magas szintű elnevezés sokkal inkább arra utal, hogy a nagyobb mértékű az elvonatkoztatotás (absztrakció) a gépi kódtól.

Na most, a pointerezgetés a gépi kód (illetve az assemly) egyik kulcseleme.

> Nem, a C nem ettől alacsony(abb) szintű. Hanem attól hogy egy átlag C-s progiban minden harmadik sorban pointerezel.

Nem bánnám, ha hoznál valami webes referenciát arról, hogy vannak mások is, akik szerint ez lenne az alacsony/magas szintű programozási nyelv definíciója...

Ez igaz. Végül is, miért ne szívjon más is ;-)

Értem, hogy te nem tartod annak, de ugye te nem a topiknyitó vagy? Akkor hagyni kéne, hogy ő döntse el. Szerintem.

Kérdés hogy mit értesz access-pótlón ? Szvsz a topicnyitó valami könnyen tanulható és használható programozási környeztet keresett linuxra, mint windowson az access. Nos, a pgaccess-t én nem nevezném ilyennek.

Nem az a baj, hogy nem értem, hogy te miért tartod rossznak. Nyilván én sem fejlesztenék pgaccess-ben, de a topiknyitó keresett egy access pótlót linuxon. Ha neki ez a mániája és hajlandó a TCL-t megtanulni és használni az ügy érdekében, akkor miért zárod ki feltétlenül? Nekem csak ennyi a bajom ezzel a hozzáállással. De már baromira nem érdekel, hogy mit fog használni a topiknyitó, csak mint elméleti problémát vetettem fel :D

Nem, a C nem ettől alacsony(abb) szintű. Hanem attól hogy egy átlag C-s progiban minden harmadik sorban pointerezel. Pl. azért mert nincs string típusod. És a C nagyon támogatja is a pointerekkel való játékot, nekem legalábbis sokkal inkább kézreáll mint anno Pascal-ban, pedig végül is abban is meg lehetett oldani minden ilyesmit, de a C egyenesen erre termett. De valójában nincs annyira éles átmenet, gépi kód -> assembly->makrók->C->C++->java vagy C# között. Meg lehet húzni különböző helyeken a határt hogy innentől kezdve magas szintű a dolog, de valójában ez elég képlékeny.

Mielőtt valaki belekötne: én is látom, hülyén fogalmaztam. Nem azt akartam mondani hogy az assemblyvel jobban haladsz mint a sima C-vel :-)

Nos, a magasszintű dolog nem feltétlenül definíciója a használhatóságnak. Tény hogy lehet kurva jó magas szintű dolgokat csinálni amivel sokkal jobban haladhatsz mint egy C++-szal vagy egy assemblyvel (a sima C-ről nem is szólva) de pont a TCL az a nyelv ami nagyon bizonyíték erre. Sokkal nehézkesebb mint akár a mezei C. Nem véletlen hogy a pgaccess-en kívül csak néhány alkalmazás van rá linuxon (valami Visual TCL-re emlékszem meg pár TCL/TK-s toolra még a korai redhatokban).

Utálni persze bármit lehet. Én a Qt-t nem utálom, csak nem tartom megfelelőnek az ár/érték arányt. De ha a Nokia ingyen utánavágná az embernek és pont olyan feladatom lenne amihez ez az ideális akkor vidáman használnám. De az az igazság hogy amire a Qt jó arra jó a wxWidgets is, és az legalább ingyen van.