 |
Clipper kontra XP
Sziasztok!
Úgy tünik a korábbi Clipperes kérdésekre nem nagyon reagált senki, azért én megpróbálom, hátha felkeltem valakinek az érdeklődését.
Egészen Win98/Me szintig nem volt gondom a Clipperes progik futtatásával. Bezzeg az XP! Nagyot alakitottak!
A következö kérdések mindegyikére két kategóriában keresek választ, Clipper Summer'87 és 5.2.
1. Tud valaki, még müködő, magyar Clipperes levlistáról?
2. A nyomtatással mindjárt két gondom van
2/a.) 200.. |
Szia!
Megköszönném ha a minigui.tvn.hu -ra összeszednél egy
leírást , ott azt gondolom hogy lesz jelentkező.
Azt gondolom,hogy a címlapon kellene egy mit hogyan csinálsz
esetleg leírások linkjei.
ha úgy gondolod akkor esetleg küldheted az anyagoz a
minigui.extra.hu kukac gmail.com -ra.
Lehetséges ,hogy a grafikus griddel ösze lehet "házasítani"!
Köszi!  |
Nem így értettem. Működik rendesen nálam, gondoltam, hátha más is foglalkozik vele és akkor lehet tapasztalatot cserélni.
A dbf-es adatbázisaimat pakoltam át egy FB adatbázisba, magyar rendezési sorrenddel. Az embedded változatot használom, mert azt nem kell telepíteni, csak másolni, de a teljes rendszerrel is hasonlóan egyszerű dolgozni.  |
Szia!
Ezt nézegettem korábban a neten , az xharbour -ra találtam különféle javaslatokat , a harbour -nál is van contrib hozzá,
de ez megrekedt egy szinten, nem nagyon találtam rá példát.
Pedig ,ha a mysql-nek egyszer "betesz" az Oracle(megvette a mysql AB-t) akkor talán szükség lenne rá vagy a postgradesql-re.
De az ámítástechnikában minden nap változik valami
Üdv!
|
| Használja valaki a Harbourhoz a Firebird adatbáziskezelőt? |
Megtaláltam.
Elvileg a harbour.exe-t is lehet így paraméterezni, de ugye azt a make (hbmk2.exe) hívja meg, így macerásabb a paraméterek hozzászerkesztése, de nem is akarom bolygatni a HMG belső dolgait, mert akkor újratelepítésnél kimaradhat.
Környezeti változóként is megadható, de az megint külön beállítás és ráadásul a parancssori kapcsolók felülbírálják.
Viszont megoldható a forrásszövegen belül is erre használható a #pragma direktíva, aminek a használatához van doksi (harbour\doc\pragma.txt)
Ebben le van írva:
#pragma <Expression>[=On/Off] or
#pragma -CompilerFlag[+|-]
-----------------------------------------------
* AUTOMEMVARS =<On/Off> /A<+/->
* DEBUGINFO =<On/Off> /B<+/->
* ENABLEWARNINGS =<On/Off> /W<+/->
* EXITSEVERITY =<nLevel> /E<nLevel>
* FORCEMEMVARS =<On/Off> /V<+/->
* LINEINFO =<On/Off> /L<+/->
* NOSTARTPROC =<On/Off> /N<+/->
* PREPROCESSING =<On/Off> /P<+/->
* WARNINGLEVEL =<nLevel> /W<nLevel>
* SHORTCUTTING =<On/Off> /Z<+/->
Valamiért pont az automemvars-ra hibát ír, de így viszont megy:
Eddig is beállítottam a /w paraméter:
#pragma ENABLEWARNINGS=On
A field sorára:
Warning W0002 Ambiguous reference, assuming memvar '_HMG_SYSDATA'
A mező használatánál:
Warning W0001 Ambiguous reference 'MEZO'
De nem mindenhol. Ha jól látom, akkor az index on esetén nem problémázik, de pl. append-nél igen.
---------------------------
Rájöttem, akkor problémázik, ha a field után csak 1 mező van megadva. Pl.:
Ha vesszővel elválasztva több mező, akkor nincs vele baja:
field mezo, placebo // Hogy a Harbour ne adjon figyelmeztetést
 |
Ez magyarázza, miért van a látszólagos különbség.
A harbour-nak is van -a kapcsolója. Azt nem tudom, hogyan kell a hmg-ben beállítani, de biztosan van rá lehetőség. |
Bocs. Kifelejtettem, hogy én -a -val fordítok. 
Ez megoldható Harbour alatt? |
Jó, a sorrend tényleg mindegy, úgy látszik belekavarodtam a sok próbába.
De ez a kód clipper alatt ugyanúgy elszáll, mint harbourban:
//test1
proc main
private alma[10]
use valami
afill(alma, 1)
A memvar deklaráció pedig fölösleges (kellene, hogy legyen), mivel a private is deklaráció.
Ha deklaráció is lenne, akkor a -a kapcsoló lenne felesleges.
Deklarátor a field, local, memvar, static, illetve a függvény paraméterei a zárójelek között. A public, private, parameters csak létrehozza a változókat, de ha -a-val fordítod, akkor deklarálja is.
1. memvar deklarációt nem előzheti meg private,
Viszont a memvar az adott blokkon belül, vagy modul szinten globálisan, megelőzheti a private-ot, és ekkor az adott név egyértelműen memvar lesz:
//test2
proc main
memvar alma
private alma[10]
use valami
afill(alma, 1)
//test3
memvar alma
proc main
private alma[10]
use valami
afill(alma, 1)
2. ugyanazt a változót nem lehet memvar-ral és private-tal is deklarálni.
Lehet, sőt kell(ene) is, hogy a -w esetén nem legyen warning. Hibát akkor okoz, ha -a-val fordítod és explicite deklarálod is (kivéve a modul szintű memvar-t). A test2 kód -a-val nem fordítható!
A fenti kódokat clipper és xharbour-ral lefordítva nem látok különbséget. Automatikus vagy explicite memvar deklaráció esetén az afill felhívásakor PUSHM(clipper)/HB_P_PUSHMEMVAR(xhb), anélkül a PUSHV/HB_P_PUSHVARIABLE pszeudokódot generálják.
Kipróbáltam clipper 5.01a és 5.2e-vel is. |
Clipperben lényegtelen, hogy mikor nyitod az adatbázist, mindig a memóriaváltozót fogja visszaadni.
A memvar deklaráció pedig fölösleges (kellene, hogy legyen), mivel a private is deklaráció.
Szerintem hibázás elkerülés szempontjából a Clipperes megoldás a jó, mert alias-> előtaggal mindig adatbázismezőre, míg anélkül memóriaváltozóra szoktunk hivatkozni.
Ja, és a fenti példáidat próbáld ki Clipperben vagy Harbour-ban, mert hibásak.
1. memvar deklarációt nem előzheti meg private,
2. ugyanazt a változót nem lehet memvar-ral és private-tal is deklarálni. |
Időközben rájöttem, mi a különbség a clipper és a harbour között.
Clipperben, ha nincs memvar deklaráció, akkor ha a dbf nyitás után van a private definíció, akkor a private változót fogja előbb megtalálni, fordítva az adatbázis mezőt. A harbour ezzel szemben deklaráció nélkül mindig az adatbázis mezőt találja meg. Én ezt inkább a clipper (nem egyedüli) hibájának tartom, amit kijavítottak a harbour-ban, igaz, ezzel picit sérül a kompatibilitás. |
| A problémát meg tudtam kerülni (átneveztem a kritikus változókat), de mint írtam, ez nem a megoldás. A megoldás az lenne, ha lett volna kapcsoló a helyes (Clipper azonos) működéshez. Mivel nincs, így hibás a HMG. De megszoktam, hogy a hibákat meg kell kerülni, ha máshogy nem megy. Azért köszi a segítséget. |
Még egy kicsit vizsgálódtam. Az alábbi kód clipper és xharbour alatt teljesen egyformán viselkedik:
// memvar alma
proc main()
private alma[10]
fn(alma)
? "main: valtype(alma)", valtype(alma)
? "main: type('ALMA')", type("ALMA")
use valami
fn(alma)
? "main: valtype(alma)", valtype(alma)
? "main: type('ALMA')", type("ALMA")
afill(alma, 1)
? "afill() OK"
function fn(v)
? "fn: valtype(v)", valtype(v)
? "fn: valtype(alma)", valtype(alma)
? "fn: type('ALMA')", type("ALMA")
return NIL
-a kapcsoló nélkül az összes ALMA hivatkozásra warning-ot dob, és hibás lesz.
Ha a memvar-t berakom, akkor mindegy hogyan fordítom, jó lesz az eredmény.
|
Hát erre csak annyit tudok mondani, hogy nagyjából hasonló project minimális ilyen jellegű zavarral simán átment xharbour alá. Egy modulban voltak public változók, másutt csak local/static, a közös dolgok paraméterként utaztak. Az is igaz, hogy a clipper'87 kód a clipper 5-re eleve így lett átírva, de az sem tegnap történt, hanem majd 20 éve.
Amúgy ez tényleg eltérő viselkedésnek tűnik, jelenteni kellene a fejlesztőknek.
Dolgoztam egy kicsit a problémádon:
a private után, meg mindenhol, ahol használni akarod a változót írd be a memvar deklarációt is.
proc main()
private alma[10]
memvar alma
fn(alma)
? type("ALMA")
use valami
fn(alma)
? type("ALMA")
afill(alma, 1)
return
function fn(v)
memvar alma
? valtype(v)
? valtype(alma)
return NIL
Xharbour alatt működik. |
A private nem helyettesíthető sem a static sem a local deklarációval.
Ha olyan változóra van szükségem, ami a létrehozó függvényben és az összes ebből hívott függvényben elérhető kell legyen, akkor csak ezt használhatom. Nincs gondom a változó deklarációkkal és azok hatókörével. A gond, mint írtam a HMG Clippertől eltérő működésével van. A HMG nem ugyanúgy működik, mint a Clipper. Ez hiba függetlenül attól, milyen változókat használok. A problémát meg lehet kerülni, de az nem "a megoldás".
Egy 140.000 soros programban nem olyan egyszerű a HMG hibái miatti foltozgatás. De eddig megoldottam. Várom a következő problémát. |
Ne használj feleslegesen public/private/parameters változókat. Rossz gyakorlat.
A függvényen belül local, modulon belül static változókkal ugyanazt elérheted. Csak a ténylegesen globális változók legyenek public-ok.
Ha a példádban a sorszam változó local, akkor úgy működik, ahogy elvárod.
De ha ragaszkodsz a private-hoz, akkor használd így:
proc main()
private alma[10]
use valami // van benne alma mező
afill(m->alma, 1)
|
| Köszi, már rájöttem, ne fáradjatok. |
Szerintem félreérted.
A Clipperben mindig a memóriaváltozó élvez elsőbbséget, mivel az adatbázismezőkre, ahogy írod, alias->mező formában illik hivatkozni. Ez a HMG-ben is így van, kivéve ha tömbváltozót függvény paraméterként használok. Például ha a következő programrész alatt nyitva van egy adatbázis amiben van sorszam nevű mező, akkor kiakad a program.:
private sorszam[10]
afill(sorszam,3)
És hiába írod be a memvar-t, akkor is kiakad, mivel az adatbázismezőt adja át az AFILL()-nek |
Sziasztok!
Meg tudnátok mondani, hogy xharbour-ben a GetOpenFileName parancsba milyen paramétert kell beküldenem és a file nevét kapom vissza válaszként?
Köszi: Zorró |
Szerintem ez nem hiba, ha nincs megmondva egyértelműen, hogy egy név mögött mit keressen, akkor először az aktuális munkaterületen keres egy adott nevő mezőt, utána keres a public/private változók között.
Ha -w-vel fordítanál, akkor látnád, hol nem egyértelmű a változó hivatkozás.
Nagyon rossz gyakorlat, hogy lustaságból csak a nevével történik hivatkozás a mezőre, mikor már a dbaseiii-ban is lehetett alias->mezo formában használni. Ha így használod mindenhol, és nem használsz feleslegesen public/private/parameters memória változókat, hanem ahol lehet static/local-okat, valamint a -w fordításkor nem ad warningot, akkor ilyen probléma nem nagyon fordulhat elő.
Egyébként már a clipper'87-ben is meg lehetett adni, hogy a memória változók között keressen, M->nev formában. Ez a harbour-ban sem tilos. A deklarációs részben is elő lehet írni:
static function fn(_par1, _par2)
memvar publictomb
...
afill(publictomb, ...)
...
return NIL
|
| Kísérleteztem vele és ha adatbázismezővel azonos nevű tömb is létezik, akkor függvényparaméterként használva nem a tömböt adja át, hanem az adatbázis-mező-t. Azért ez gáz. |
Köszönöm az eddigi segítséget.
Még arra keresek megoldást, hogy a Clipperrel ellentétben a HMG a memória változó helyett az adatbázis mezőt éri el, ha azonos a nevük az AFILL() fv-ben. Így a tömb helyett az adatbázismezőt akarja feltölteni értékkel, persze mivel az nem tömb, kiakad (szerencsére).
Ezt valamilyen beállítással ki lehet küszöbölni? Mert ez szerintem hibás működés a HMG-ben. Akkor is, ha programozásilag sem helyes.
Köszi előre is. |
| inline_c.prg |
Köszönöm a fáradozásod. A Harbourba be lehet szúrni C++ forráskódot? Mert külső fordítást és hozzászerkesztést elkerülném, ha lehet. A Harbour saját könyvtáraiba sem akarok belepiszkálni.
Viszont, elindultam az alapján, amit írtál, és találtam egy FileStats() fv-t, amivel meg tudtam oldani. A Harbour-project oldaláról egy mintapélda: LOCAL cFileName := "FILESTATS.PRG"
LOCAL cFileAttr , nFileSize
LOCAL dCreateDate, nCreateTime
LOCAL dChangeDate, nChangeTime
? FileStats( cFileName, @cFileAttr , @nFileSize , ;
@dCreateDate, @nCreateTime, ;
@dChangeDate, @nChangeTime )
? "File statistiscs"
? "File Name :", cFileName
? "Attributes:", cFileAttr
? "File Size :", nFileSize
? "Created :", dCreateDate, TString( nCreateTime )
? "Changed :", dChangeDate, TSTring( nChangeTime )
|
Az igazat megvallva, én az xharbour forrásokat néztem, a harbour egy kicsit bonyolultabb, de azon is el lehet menni, csak követni kell a _hb_fileStart, hb_fsFindFirst vonalat. A vége a winapi FindFirstFile/FindNextFile/FindClose lesz.
A dátum lekérdezés kódja:
HANDLE h;
WIN32_FIND_DATA ff;
FILETIME ft_utc, ft_local;
SYSTEMTIME st;
char dates[9];
h = FindFirstFile(hb_parc(1), &ff);
ft_utc = (ff.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) ? ff.ftCreationTime : ff.ftLastWriteTime;
FileTimeToLocalFileTime(&ft_utc, &ft_local);
FileTimeToSystemTime(&ft_local, &st);
snprintf(dates, sizeof(dates), "%04d%02d%02d", st.wYear, st.wMonth, st.wDay);
FindClose(h);
hb_retds(dates);
Az idő ez alapján már csak menni fog. |
Köszönöm a segítséget, de nem sikerült megoldást találni.
Ennyi a fv. kódja:
HB_FUNC( FILETIME )
{
PHB_FFIND ffind = _hb_fileStart( FALSE, HB_FA_ALL );
hb_retc( ffind ? ffind->szTime : NULL );
}
Egy Win32 API-s fv. hívás lehet, hogy jobb lenne. |
Lehúzod a harbour forrását, megkeresed benne a filetime() függvényt (files.c) és vagy megmódosítod és újtafordítod a lib-et, vagy az alapján írsz egy saját függvényt, pl xfiletime() néven.
Egyébként ahogy elnézem, van legalább két bug abban az egy piciny függvényben. |
A fentieket megoldottam. Úgy látszik a HMG több ponton nem kompatibilis a Cliperrel.
A következő problémám a FILETIME() függvény, ami állományok esetén az állomány utolsó módosításának idejét adta vissza, viszont könyvtárak esetén (pl. FILETIME("C:\Windows",16)
Tudtok olyan megoldást, függvényt, amivel egy könyvtár létrehozási dátumát és idejét le lehet kérdezni?
PS: A HB_FGETDATETIME() fv. nem működik könyvtárakra.
A HMG-ben Win32 API hívásokat hogyan lehet megoldani? |
Újabb problémába ütköztem: A get-ek bekérésénél a mező háttérszínét változtatgatja A háttérszín, fekete és az eredeti piros között.
Saját get kezelőm van, ami a "fókuszban" lévő get mezőt világosabb pirossal rakja ki.
Mi lehet a megoldás?
Köszi előre is. |
Ezt is megtaláltam:
#ifdef __HARBOUR__
? "Harbour"
#else
? "Clipper"
#endif
inkey(0)
Ja, bocs, nem figyeltem, hogy már jött megoldás. Köszönöm szépen. |
__HARBOUR__
__XHARBOUR__
|
|
| |
| RSS források |
 | - | Hírek | | - | Cikkek | | - | Fórumok | | - | Állás/munka |
|
| Top pontgyűjtők |
| » | Micu | 1.030 | | » | Interlock | 280 | | » | mezofi | 150 | | » | Pitta_ | 100 | | » | Frostech0 | 100 | | » | szbzs.2 | 100 | | » | Hack | 100 | | » | Riha | 60 | | » | Akhiles | 50 | | » | mrchandra | 50 | | | |
|
| Top wikieditorok |
| » | Sting | | » | Doi | | » | FlamingClaw | | » | Argathron | | » | Csaboka2 | | » | Vodka | | » | Joexy | | » | Ivn | | » | Balucinho | | » | Kelemzol | | | | » ugrás a wikire |
|
|
