Zaslal: po 20. březen, 2006 13:55 Předmět: movable database
Zdravim vsechny PALMOS developery!
Mam dotaz k Data Manageru..
Jsou .pdb, popr. jednotlive zaznamy, premistitelne bloky (automaticky systemem)?
Jinak receno, muze mi system pod rukama (pokud neni record samozrejme locknutej) presunout dany zaznam v pdb na jinou adresu?
Mam teorii, ze sice ano, protoze maji MemHandle a pri DmRecordResize to system presouva. Je ale otazka, jestli to dela i behem behu me aplikace, ktera ma dany .pdb otevreny a nic neresizuju (tzn. nenutim ho k tomu primo, ale pouze novymi naroky na MemHandleNew()).
Jenze v praxi se to asi nedeje, protoze napr. moje MHD (sem ted zjistil ) zcela suverene nasmeruje pointery (H1=SysFormPointerArrayToStrings(...)) na locknuty zaznamy, pak unlockne ten record v db (ten H1 necha locklej) a pak s tim pracuje a nikomu se to nehrouti ... pritom ten H1 ma jen ukazatele na zacatky tech zaznamu v db
Taaakze .. otazka je - je to tak cisty? protoze jinak bych musel po dobu otevrenyho Form jeste drzet vsechny handly tech db zaznamu ..
To presouvani se sice nedela zbytecne ale pokud je nedostatek pameti tak se to urcite stane. Na starsich palmech (OS<5.4) kdyz je nedostatek pameti a pamet je fragmentovana funkce na alokaci pameti automaticky zkouseji volat MemHeapCompact pokud se alokace napoprve nepovede. Na novejsich palmech (>=5.4) je to jeste pravdepodobnejsi diky tomu ze dbcache je mala a neni-li misto, nezamcene zaznamy se proste z pameti odstrani. Pokud bezi jenom jeden program nemusi se to v praxi stavat casto, ale palmos je interne multitaskovy takze podle toho co clovek dela (mp3 na pozadi, pripojeni k internetu) se to klidne stat muze i kdyz tvuj program nic primo nealokuje. Nemluve o tom ze jakakoliv operace v GUI (otevreni menu napriklad) nejakou pamet stejne potrebuje.
Jina vec ale je pokud handle nastavis nekam ve formu, to je treba precist dokumentaci jestli si ten handle palmos sam zamkne a stara se o nej od te chvile sam nebo ne. Vetsinou asi jo.
a ty pdb jsou taky ulozeny v heapu? v tom samym, kde beru volny chunky pro memhandlenew? a nepresunujou se prioritne prave tyhle "maly" kousky nez cele .pdb fajly? _________________ III -> m130 -> m505 -> m515 -> Tungsten T2 -> Treo 650 -> Treo 750
tyjo, fakt ze pri scramble se ten List rozsypal .. to je fakt .. dobre, melo by to byl lockly, ale pokud nezavolam scramble, ci jiny presuny, tak by to tam melo byt, ne? ja to potrebuju mit stale aspon po dobu zobrazeni jednoho formu .. _________________ III -> m130 -> m505 -> m515 -> Tungsten T2 -> Treo 650 -> Treo 750
a ty pdb jsou taky ulozeny v heapu? v tom samym, kde beru volny chunky pro memhandlenew? a nepresunujou se prioritne prave tyhle "maly" kousky nez cele .pdb fajly?
V tom samem ne, databaze jsou v heapu cislo 1 (storage heap) spolecne s bloky alokovane pomoci FtrPtrNew. Heap 0 je dynamicky heap pro MemHandleNew a MemPtrNew.
Cele pdb fajly jsou jenom na karte, v pameti nejsou zadne pdb fajly ale kazdy zaznam jako handle. pdb je jenom format pro ukladani na disk
pxcz napsal:
pokud nezavolam scramble, ci jiny presuny, tak by to tam melo byt, ne? ja to potrebuju mit stale aspon po dobu zobrazeni jednoho formu ..
ciste to proste neni, driv nebo pozdeji to nekomu kvuli tomu spadne. Kdyz uz, tak je vsechy pozamykej a nechej tak, pri ukonceni programu se vsechna pamet alokovana programem automaticky uvolni (pokud nepouzijes MemHandleSetOwner). To je aspon o neco mensi 'prasarna' nez to co delas
oki .. necham to lockly .. nicmene k tomu uvolnovani - to tam fakt funguje? na me vzdycky simulator rve, ze sem za sebou nechal neuvolneny chunky .. to je jen warning? v realu mi to nicemu neuskodi? je lepsi se o ne postarat nebo opravdu muzu verit operacnimu systemu? _________________ III -> m130 -> m505 -> m515 -> Tungsten T2 -> Treo 650 -> Treo 750
I kdyz ted me napada, ze si radsi budu hrat s uvolnovanim pri kazdym CloseEventu sam, protoze co Form, to novy alokace v OpenEvent, takze pri delsim pouzivani programu by taky ta pamet mohla dojit uplne _________________ III -> m130 -> m505 -> m515 -> Tungsten T2 -> Treo 650 -> Treo 750
oki .. necham to lockly .. nicmene k tomu uvolnovani - to tam fakt funguje? na me vzdycky simulator rve, ze sem za sebou nechal neuvolneny chunky .. to je jen warning? v realu mi to nicemu neuskodi? je lepsi se o ne postarat nebo opravdu muzu verit operacnimu systemu?
Jo, to je warning. Vadi to akorat tvoji aplikaci pokud alokujes dal a dal a pak jeste simulatoru Verit mu asi muzes, ale urcite to neni dobra programatorska technika a nekteri lidi ti to treba budou hlasit jako chybu.
Tak sem po chvili rozsirovani funkci stejne dopad tak, ze ty zaznamy z db kopiruju do novych memhandlu, protoze sem udelal interni prevod znakovych sad, takze do dat musim i zapisovat
Zajimavy je, ze Simulator celkem spokojene do tech zamcenych (otevrenych db jako read-only) handlu psal (po ukonceni aplikace ale data nechal v puvodnim stavu - neboli tak jak sem potreboval), zatimco Treo slo (spravne) okamzite do resetu
Jeste jedna podotazka - nevi nekdo, jak udelat BORDER kolem TABLE?
Tak, jak je to v Preferences - Formats - Preset to ... - Set Location.
Soucasti resource editoru takova moznost neni ... nebo to snad mam kreslit pres WinDrawLine? _________________ III -> m130 -> m505 -> m515 -> Tungsten T2 -> Treo 650 -> Treo 750
hm, tak uz nic, ono to neni zas tak slozity to tam "dokreslit"
FrmGetObjectBounds(form, FrmGetObjectIndex(form, kZastavkyFormZastavkyTable), &rp);
WinDrawRectangleFrame(simpleFrame, &rp); _________________ III -> m130 -> m505 -> m515 -> Tungsten T2 -> Treo 650 -> Treo 750
Nemůžete odesílat nové téma do tohoto fóra. Nemůžete odpovídat na témata v tomto fóru. Nemůžete upravovat své příspěvky v tomto fóru. Nemůžete mazat své příspěvky v tomto fóru. Nemůžete hlasovat v tomto fóru.