Aktív témák
-
lao ce
aktív tag
ha esetleg Alan erre jar, kis update:
szepen alakulgatnak a dolgok. lassan elkeszul a program, a tree jol beilleszkedett a helyere, es lassan en is megertem hogy mirol is van szo :)
a legjobb erzes, hogy futas kozben, az adatbazis tablat megvaltoztatom, egy refresh, es maris editalhato az uj mezo szorostul-borostul.
meg sok aprosag van hatra, de azert mar erezni az oroszlankormoket... -
lao ce
aktív tag
itt a meghivasok sorrendje (nehany kerdojellel) a processmessages nelkul:
1-InitNode (root)
2-InitChildren
3-InitNode (gyerekre, feltoltes, aztan detailrecordset.next)
4-GetText, column=-1 (???)
5-GetText, col=0, root
6-GetText, col=0, root (masodik hivas...miert vajon???)
7-GetText col=1, root (jobb oldal, ami ugye ures)
8-GetText col=1, root (masodik?)
9-InitNode, gyerek oldal. itt felkapja a 2. recordot, es tovabblep a harmadikra!
10,11- GetText col0, gyerek
12, 13- GetText col1, gyerek
14 InitNode, gyerek oldal
15,16- GetText col0, gyerek
17,18- GetText col1, gyerek
19- GetText. most szepen jon az elso record. Column 0, gyerek
20- GetText a szokasos ismetles Col0, gyerek
21,22- GetText Col1, gyerek
23 InitNode, root
es innen ugyanaz.
....
bammeg... a teremto vezeti a kezemet. most, hogy nem volt processmessages, kikapcsoltam (a default true) a treeoptionban a toAutoScrollOnExpand -ot.
most jol jelenik meg minden.
...
utananeztem a helpben, senki nem emliti ezzel kapcs. a toAutoScrollOnExpand-ot.
...
hat ez erdekes volt. :( -
lao ce
aktív tag
igen, a DOA, azaz :)
en is berzenkedtem az oracletol. 99-ben kellett kezdeni irni egy rendszert oracle-lel, hatterben delphi, juzernek asp weboldalak. (azota is gyakolatilag ezt irom, de a delphis resz annyira mukodik hogy tk 2001 ota nem delphizek csak kis hibajavitasok meg hasonlok)
betettem az oraclebe a tablakat, indexeket primary keyeket, ami muszaj volt. aztan kezdtem egyre nagyobb es nagyobb adagokat tomni az oracle-re, hogy lassak mar valami hmm... hatast -mondjuk sebesseg csokkenesben-, meg persze, hogy tanuljak. mostmar tobb mint 30e sor van az oracleben, es azt kell mondjam, hogy mindenfele hiszteria nelkul futkosnak ezek a sorok. persze ettol nem szeretem, de keves fogast talalnek rajta egy vitaban.
Virtual Tree
letoltottem a legujabb verziojat a treenek (a site nem mukodott idaig), es felszenvedtem. most eppen a wordwrappal molyolok, azt hiszem multiline lesz belole es hard coded enterek (tapasztalatod van ezzel kapcsolatban? allitolag nem mukodik win9X-en). latni meg nincs mit, en csak valami core-t akarok irni a kollegamnak. de aztan majd a csicsara ujra hozzam kerulnek a dolgok.
a mai napra van betervezve az, hogy megcsinalom az editalhatosagot a jobb oldalra (meg nem kell az adatbazis mentes), es ha van ido akkor megcsinalom hogy a global.pas-omba bepakolom ami oda tartozik. holnap delelott jon a kollegam, szoval addig el illene keszulni. kesobb lehet meg finomitani a kodon.
ProcessMessages
- en nem ijedek meg, csak akkor most mi a rosseb van itt. egyedul nekem a vilagon szarakodik ez? a google group-okhoz engedelyt kertem, hogy nezhessem oket, majd talan a human resources csapata kegyes lesz hozzam es megadja. ennyit a cegrol ahol dolgozok :) ) -
Alan
aktív tag
Direct Oracle Access, ugye? Én is jókat hallottam róla. Szerencsére nekem egyelőre nem kell Oracle-lel érintkeznem.
Ne ijedj meg, de tényleg nem javaslom a ProcessMessages() használatát, most is valószínűleg csak azért működik tőle a programod, mert belehív egy másik eseménykezelődbe, ami szintén mozgatja a detail dataset kurzorát (persze így látatlanban nehéz megmondani, mitől hibás egy kód). Ettől viszont egy másik példányban is belelépsz a saját kódodba, és vagy tényleg reentráns az egész programod, vagy előbb-utóbb baj lesz. Próbáld ki pl.., hogy nagyon nagy táblákból töltöd fel a VT-t, úgy, hogy a feltöltés több másodpercig tartson, és eközben nyomkodj vadul a felhasználói felületen, lehetőleg a VT komponenst érintő dolgot csinálj. Szinte garantált a lefagyás vagy az AV.
Szerintem inkább csináld azt, hogy feltöltés után lerendezed az adott master node-ok alatti detail node-okat (ha az AutoSort nem működik, bár nálam ment az is). Ehhez a master és a detail node-okban is tárold el az elsődleges kulcsot az adott táblából. Hacsak nem lesz több ezer detail node egymás alatt, ez nem fogja érzékelhetően lerontani a teljesítményt - ha meg igen, akkor felhasználói szempontból úgyis használhatatlan lesz a program, mert egy egy szinten több ezer elemű tulajdonságfa kezelhetetlen.
Ha nem sértelek meg vele, ideírom neked a létező leggyorsabb rendezést (csak hogy ne kelljen annyit körmölnöd) :) :
[code]
procedure QuickSort(L, R: integer);
var
I, J: Integer;
T: TLaoCeTombocske;
begin
repeat
I := L;
J := R;
while LaoCeForrasTombocske < LaoCeForrasTombocske[(L + R) shr 1] do
Inc(I);
while LaoCeForrasTombocske[J]> LaoCeForrasTombocske[(L + R) shr 1] do
Dec(J);
repeat
if I <= J then
begin
T := LaoCeForrasTombocske;
LaoCeForrasTombocske := LaoCeForrasTombocske[J];
LaoCeForrasTombocske[J] := T;
Inc(I);
Dec(J);
end;
until I > J;
if L < J then
QuickSort(L, J);
L := I;
until I >= R;
end;
[/code]
Az L, R paraméterek a két szélső elem, a közöttük elhelyezkedő elemeket rendezi a rutin. Ha mindet akarod, akkor n elemű LaoCeForrasTombocske esetén így hívd meg: QuickSort(0, n-1); -
lao ce
aktív tag
speciel az oraclehez egy komponenst hasznalok (direct access vagy mi a neve -allround a ceg neve), nagyon jol muzsikal. oszinten soha semmilyen bajom nem volt vele -bar nem is hasznalom tul melyen.
''jön a váratlan, debugolhatatlan, időzítéstől/egérpozíciótól stb. függő, hajkitépető access violation''
hat, ezzel megnyugtattal, mondhatom. most epitsek ra vagy ne. sajnos nekem kell dontenem. de ha befurdunk vele... akkor en csobbanok a legnagyobbat :) -
Alan
aktív tag
A jó híreknek nagyon örülök, főleg annak, hogy a lelkesedésed visszatért. Tudom, milyen érzés, amikor folyton az unalmas vackokat gyártod és nincs időd az érdekes dolgokra.
Helyi, egyedi felhasználáshoz, megosztani nem kívánt Access adatbázishoz teljesen jó lesz az ADO. Azért azt tudd, hogy az ADO komponensek a legbugosabbak az összes adatbázis-kezelőelem közül, de szerintem azért bőven használhatók. A hiba, amit tapasztaltál ADO tábláknál, erősen komponenshiba-gyanús egyébként, főleg, ha Oracle táblákkal (tehát, gondolom BDE-n vagy dbExpress-en keresztül nincs gond). Én nem dolgozom ADO komponensekkel, de a helyedben rákeresnék a groups.google.com-on, hogy másvalaki nem látott-e hasonlót (master-detail, lekérdezés sorrendje nem mindig jó).
Jól felépített programba elvileg sosem kell ''kézi'' ProcessMessages(). A legtöbbször, amikor ez valami hibát ''kijavít'', akkor csak elleplezi és más helyzetben visszajön. Sőt, ettől a hívástól az eseménykezelők újrahívódhatnak, miközben egy előző eseményt kezelsz - ergo a teljes programnak reentránsnak kell lennie (mintha többszálú lenne: globális elemeknél be kell, hogy játsszanak a kritikus szakaszok, mutexek és társaik), mert különben jön a váratlan, debugolhatatlan, időzítéstől/egérpozíciótól stb. függő, hajkitépető access violation.
Küldhetnél egy képernyőfotót, hogy lássam a cuccodat működés közben :) -
lao ce
aktív tag
nos, tapasztalat is van, jo hir is - meg rossz is. :)
tapasztalat: nem szabad bekapcsolni az autosort-ot.
neha az egesz meghulyul nalam megmondom oszinten. az initnode-initchildren-gettext hivasi sorrend felborul es osszevissza sorrendben irja ki a dolgokat a treebe. szombaton ugy sikerult vegre eletet lehelnem bele hogy uj projectet csinaltam aztan event-rol event-re atkopiztam a dolgokat. de ez lehet hogy visszavezetheto az autosortra vagy mas parameterekre.
a jo hir, hogy sokkalta kozelebb jarok a hasznalathoz, gyakorlatilag megjelennek azok amiket akarok az adatbazisbol, oda kerulnek ahova kell. van mar hatterszinezes (adatbazis dictionary tablaban lehet letarolni a kivant szineket a nodeokhoz), incremental search meg hasonlok... jojo, mas meg nincs :) a legjobb hir, hogy VEGRE olyasmibe kezdtem bele amit mar ezer eve akartam es vegre ujra lelkesedek valamiert.
viszont van egy par bosszusag is. az egyik hhh... eleg rohejes. de iszonyu bosszanto. a children nodoknal, az elso elem (sor) lekerul az utolso sornak. ugy ertem, hogy ami az elso childrennek kellene lennie, az lesz az utolso egy root nodeon belul. a tobbi children rendesen van rendezve ugy, ahogy a lekerdezes mondja. erdekes modon, mikor oracle-lel kotom ossze, akkor jo, ha az access tablakat kerdezem akkor nem jo. arra gyanakszom, hogy a gettext meghivasa megint nem az igazi, de sajna itt az uj project sem segitett. megprobaltam ado helyett sima tablakat hasznalni, az eredmeny ugyanez.
(ahhh tenyleg: szerinted ado-t hasznalni jo otlet accesshez, lokalis adatbazis, 1 usernyi felhasznalo egy idoben, lehet hogy oregecske gepecske, win95 es attol felfele???)
nomost, en queryzek, nem tablazok. tehat, egy master es egy detail query-m van, a detail felepitve es elinditva az initnode-ban:
if ParentNode = nil then
...// root node
...root column feltoltes
...detail query epites, where DetailID = MasterID ; order by position_column(<-!)
...open query
...master query.next
...ivsHasChildren
else
...//children column
...children column feltoltes
...detail query.next
end
elment ra 4 oram, de meglett a megoldas -bar tisztara osztonosen, en nem tudom hogy bizhatok-e ebben. a detailquery.next sor elé beszurtam egy application.processmessages-t. hirtelen tenyleg a jo sorrendbe kerulnek a children node-ok es az elso nem lesz az utolso.
szeretnem hallani a velemenyed, hogy lattal-e mar ilyesmit, es hogy mit gondolsz errol a processmessages-rol. -
Alan
aktív tag
Remek, szuper :)
Nálam remekül megy a program, gondolhatod, hogy nem küldöm el kipróbálatlanul. Elindítás után a master tartalmát látod, sok pluszjellel, amiket ha lenyitogatsz, jönnek a 2-4. oszlopokban a detail mezők gyönyörűen. Lehet, hogy használtam valami specialitást (merthogy nálam már átdolgozott advanced Alan-féle VirtualTree megy ám), amire nem is figyeltem, vagy az is lehet, hogy Neked valami régebbi verzió van meg és azért nem működött elsőre
De a végső lényeg persze az, hogy a Te programod menjen jól. Majd jelentkezz, kíváncsi vagyok :) -
-
Alan
aktív tag
Hát, nem mondhatnám, hogy az élvezetek tengere ez a hétvége, de azért messze nem katasztrófa.
Gyorsan összeütöttem neked egy Virtual Treeview példaprogramot, amit el is küldök levélben. A szokásos BDE demó adatbázisokkal megcsinálja, amit akartál. Ha még van valami gond, nyugodtan szólj, ha tudok, segítek :) -
lao ce
aktív tag
megprobalom nagyjabol leirni mi van a programban.
az initnode-ban:
if ParentNode = nil then
begin
...mastertabla feltoltese recordsetbol
...InitialStates := InitialStates + [ivsHasChildren, ivsExpanded];
...MasterDataSet.next;
end;
InitChildren:
MyMasterRec := PMyMasterRec( VST.GetNodeData(Node));
recordset selectje (ID alapjan)
ChildCount := DetailDataSet.RecordCount;
if DetailDataSet.RecordCount > 0 then
begin
...while not(DetailDataSet.Eof) do
...begin
......feltoltese a Detail record tomb mezoinek feltoltese [i]
......inc(i);
...end;
end;
a feltoltesnel ki is irom egy memoba, es ugy nez ki, hogy minden adat szepen a helyen van, szoval szerintem a kovetkezokben lesz az ami nem mukodik (mar hogyha nem az egesz ugy ahogy van hasznalhatatlan)
GetText:
if TextType = ttNormal then
begin
...case Column of
...0:
......if Node.Parent = Sender.RootNode then
......begin
.........MyMastRec := Sender.GetNodeData(Node);
.........Text := MyMastRec.NameCol;
......end
......else
......begin
.........MyMastRec := Sender.GetNodeData(Node);
.........Text := MyMastRec.MyDetRec[Node.Index].FirstColumnToWrite;
......end;
stb
nomost, ez mar nem akar mukodni. a Node.Parent = Sender.RootNode reszen megkapom a kivan ertekeket, de a detail recordnal ures minden. -
lao ce
aktív tag
''Érdemes amúgy elolvasgatni a súgóját (Virtual Tree.chm), van pár jó példa benne.''
hat, ezaz, hogy 'par' jo pelda az egy oldalnyi (igaz, gorgetni kell :) ). A little code repository... nojo, a getting started is, de megvallom oszinten mikor elkezd a figura filozofalgatni a streamekrol meg indirekten ismert osztalyokrol, akkor en elveszitem a fonalat.
''a többit meg elintézed a fenti OnInitNode eseménykezelőben. ''
(megj: sajna nyitva kell tartani az osszes - vagy akarhany- nodeot)
no, ezaz. az adatstruktura. meg a 'tobbi' amit el kell intezni. pont ez a kulcs.
tudom, hogy marha nehez valaszolni ugy, hogy nem teszek fel ertelmes kerdest. szoval van ez a ket tabla. kell hozza egy struktura.
te azt javasolod (vagy esetleg ezt 'kell' tennem (ez a megoldas es az elvaras a tree reszerol?)), hogy egyetlen record struktura legyen? ahh, latom ez nem is tree problema.
(pelda: aruhazak -< beerkezett aruk)
PAruhazak = ^TAruhazak;
TAruhazak = packed record
...AruhazID: integer;
...AruhazNev: string;
...NumOfBeerkezettAruk: integer;
...BeerkezettAruk array of strings; // <- ?????
end;
szoval lehet betenni egy dinamikus array-t?
vagy inkabb a BeerkezettAruk legyen egy record (mivel hogy kulonbozo tipusu mezok vannak) es arra legyen egy dinamikus tomb?
szoval 2 recordos struktura (?):
PBeerkezettAruk = ^TBeerkezettAruk;
TBeerkezettAruk = packed record
...BeerkezettAruID:integer;
...BeerkezettAruNeve: string;
...BeerkezettAruErteke:integer;
end;
type DinArrBeerkezettAruk = array of TBeerkezettAruk;
PAruhazak = ^TAruhazak;
TAruhazak = packed record
...AruhazID: integer;
...AruhazNev: string;
...NumOfBeerkezettAruk: integer;
...BeerkezettAruk array of DinArrBeerkezettAruk; // <- ?????
end;
most kellene kerdeznem valamit? :(
ok. ertelmes ez igy? tulbonyolitott? -
Alan
aktív tag
valamiert vegtelen ciklusba kerult, ha az InitChildren-ben queryt futtattam (lehet hogy en voltam bena, de az olasz srac is panaszkodott erre).
Ennek elvileg nem szabadna így lennie, ez az esemény direkt ilyen célra van. Talán a kódodban van valami hiba, ami miatt kiváltódik még egyszer ez az esemény (vagy egy másik, ami közvetve újra kiváltja ezt).
nem biztos hogy van children minden root node-hoz ugye. szoval akkor nem allithatom be az InitialStates -t maskent, csak ha tudom mar elore, hogy lesz-e gyereke.
OK, de először próbáld ki úgy, hogy mindegyiknél beállítod, mintha lenne, aztán ha mégsincs (OnInitChildren), akkor lenyitáskor törlöd a kis pluszjelet. Nem a legszebb, de a leggyorsabb megoldás, főleg mivel...
ezert gondoltam, hogy mar a root select (a rootnodehoz) kellene tartalmazza hogy melyik rekordnak hany gyereke van (count+group by), es itt, az InitNodeban egy selecttel rovidebb lenne a kod.
...különben be kell nyelned az egész adatbázist (de legalábbis minden subselect RecordCount-ját) már a legelején, így komolyabb adatbázisokhoz nem lesz használható a program. -
lao ce
aktív tag
valami ilyesmit csinaltam, leegyszerusitve:
InitNode:
if ParentNode = nil then
begin
...DataSet_sub.SQL.Clear;
...DataSet_sub.SQL.Add(' select .-. where MYID=' +DataSet_root.'MYID');
...DataSet_sub.Open;
...if DataSet_sub.RecordCount > 0 then
...begin
......InitialStates := InitialStates + [ivsHasChildren, ivsExpanded];
...end
...end;
...globalChildCount := DataSet_sub.RecordCount;
...DataSet_sub.Close;
end;
azert itt, mert valamiert vegtelen ciklusba kerult, ha az InitChildren-ben queryt futtattam (lehet hogy en voltam bena, de az olasz srac is panaszkodott erre).
a masik, hogy nem biztos hogy van children minden root node-hoz ugye. szoval akkor nem allithatom be az InitialStates -t maskent, csak ha tudom mar elore, hogy lesz-e gyereke.
ezert gondoltam, hogy mar a root select (a rootnodehoz) kellene tartalmazza hogy melyik rekordnak hany gyereke van (count+group by), es itt, az InitNodeban egy selecttel rovidebb lenne a kod.
most olvaslak tovabb... -
Alan
aktív tag
Még egy apróság: az AddChild, InsertNode és hasonlók csak azért vannak benne a VT-ben, hogy ne ijedjen el mindenki első látásra, de ezek lerontják a teljesítményt, csak a TTreeView-ra már ''rászokott'' felhasználók kedvéért, kompatibilitási okból van benne és egy idő múlva Mike Lischke valószínűleg ki fogja venni a komponensből. Szóval ezeket inkább ne használd.
Érdemes amúgy elolvasgatni a súgóját (Virtual Tree.chm), van pár jó példa benne. -
Alan
aktív tag
Hát, nem biztos, hogy akkora mázli, mert így az első két olvasás után attól tartok, rossz híreim vannak.
A VT működését jól értelmezed, valóban ezért villámgyors, de adatbáziskezeléshez nyers formában nem a legoptimálisabb, mert azon alapul, hogy a memóriában lévő adatstruktúrádból Te magad veszed majd elő neki az adatot (OnGetText) jó gyorsan, így nem kell az adatokat neki még egyszer letárolnia valahol (mint azt a ''klasszikus'' TTreeView teszi). Ha az OnGetText eseménykezelőben Te adatbázishoz fordulsz, akkor akár el is mehetsz vacsorázni közben (ahogyan láttad is).
Azért nem reménytelen a helyzet, de mindenképpen létre kell hoznod valami gyorsítótárat a memóriában, különben használhatatlan lesz a programod. Arra gondoltam, hogy először is definiálsz egy struktúrát, mondjuk egy rekordot, amiben a tulajdonságfa egy csomópontjának adatai teljesen beleférnek (olyasmi lesz ez, mint egy adatbázisrekord). Az első select alapján beállítod a RootNodeCount tulajdonságot, erre elkezdenek áramlani az OnInitNode események. Ezekben a gyökérelemeknél nem csinálsz mást, csak megjegyzed, hogy melyik eredménysorhoz melyik node tartozik, és beállítod, hogy van neki gyermeke, valahogy így:
[CODE]
procedure TLaoCeForm.VSTInitNode(...);
var Data: TLaoCeNodeData;
begin
if ParentNode = nil // ezek a root node-ok
then
InitialStates := InitialStates + [ivsHasChildren]
else begin // ezek meg a subselectek-hez tartozó node-ok lesznek
Data := Sender.GetNodeData(Node);
{itt kitöltöd a cuccaiddal az adatstruktúrát}
end;
end;
[/CODE]
Ezek után az a lényeg, hogy az OnInitChildren eseménykezelőben lefuttathatsz egy-egy subselect-et az aktuális node-hoz eltárolt paraméter alapján, és beállíthatod, hogy hány eredménysora van (erre megint beindulnak az OnInitNode-ok, de már a gyermekelemekre), a többit meg elintézed a fenti OnInitNode eseménykezelőben. Az általam TLaoCeNodeData-nak nevezett struktúrát tehát jól találd ki.
Ezzel a megoldással megúszod a teljes adatbázis letárolását a memóriában, de a jó teljesítményhez annyit muszáj megtenned, hogy a képernyőn látható (a megnyitott node-okhoz tartozó) adatok a memóriában legyenek.
Bedobhatsz egy olyan trükköt is, hogy egyszerre csak egy root node-ot lehessen lenyitni, a második lenyitásakor a korábban már lenyitottat felcsukod, így a hozzá tartozó gyermekelemeknek a memóriáját (TLaoCeNodeData csomagjait) klasszul újra felhasználhatod az aktuálisan lenyitott node-hoz.
Végső soron tény, hogy nem kifejezetten DataSet típusú működéshez találták ki ezt a komponenst - de annál szebb a kihívás, nemde? :)
(Ha nagyon sz**sz vele, tudok küldeni kisebb példakódokat, de szerintem ez alapján már minden OK lesz.) -
lao ce
aktív tag
igen, hahhh, ez az igazi mazli!!!! :)
nnno... (kezdorzsoles)
nyugodtan korrektald ha hulyeseget irok, bar azt hiszem ilyesmit irtal a 'virtualis komponens reszben':
en ugy ertelmezem magamban a mukodeset, hogy ez a joszag azert gyors es rugalmas mert nem tárol le semmit, hanem 'csak' megjelenit, es kulonbozo flagek es status valtozok altal koveti nyomon hogy mi a fene is tortent azelott. szoval a sebesseg nem a treetol fugg, hanem attol hogy milyen gyorsan tudja etetni adatokkal a korulotte levo program.
megneztem a demokat. ha emlekszel ra, van egy advanced, amiben van egy property editor nevezetu oldal. osszesen ket rootnode, azok alatt az elso oszlopban a property neve, a jobb oldalon meg az ertek, amit lehet editalni (datetime, edit, combo stb). azt hiszem meg ha nem is emlekszel ra, elkepzelheto. ebben van az incremental search is egyebkent. a kodot nezve, szepen felepitik az objetumokat (joooo, recordok), be van varrva a ket root node es a jobb oldalhoz a combo ertekek, tombokben vannak tarolva a sorok amiket a node-ok ala tesznek.
nomost, nekem ez kellene pontosan, dehat persze adatbazist olvasva. gyonyoruen letarolni a hagyomanyos dolgokat, mellebiggyeszteni azt, hogy ez edit/combo(+lookup table)/date/time, aztan editalhato/mentheto szepen minden. nagy otlet, gondolom ez mar mindenkinek eszebe jutott. csakhogy, sajnos semmifele helpet nem talaltam ezzel kapcsolatban a helyeken amiket ajanlanak helpre (newsgroup meg a ket forum). egyedul egy olasz srac kerdezett valamit ezzel kapcsolatban (ugyanazt akarta csinalja mint en), erre valaki ugy megorult a foldijenek hogy olaszul valaszolt neki. basszuskulcs :)
amit tettem
nekem a rootnodeok adatbazis selectbol jonnek. attol fuggoen, hogy mi az aktualis 'ID', subselectek vannak megjeleniteni a childreneket. beleeroltettem a GetText eventbe (csakhogy lassam) ezeket a subselecteket. khm. kb olyan sebessegu volt mint mikor a matrixban neo hajol el a golyobisok elol.
vannak sejteseim a valaszokra, de kellene iranymutatas, mert meg sok es nagy homalyok vannak a fejemben:
K1) szoval -ahogy sejtem- nekem eloszor fel kell epitenem azt, ami mar egyszer az adatbazisban van (struktura), aztan letarolni a kliens gep memoriajaban -tombokben es recordokban- az ertekeket amik az adatbazisban vannak, hogy ki tudjam szolgalni a tree-t?
K2) ha el tudod kepzelni a szituaciot, hogy mit probalok csinalni:
- egy... o... egy record/tomb (vagy maradjon a select?) paros legyen es szekvencialisan rakjam be a ket tabla hm... szorzatat? esetleg 'csaljak', es hagyjam uresen azokat a cellakat amik ugye nem lesznek kirajzolva a childoknal mert a rootnodehoz tartoznak az informaciok? vagy ezeket hasznalja a tree csak nem mutatja? (InitNode: if ParentNode <> nil then 'csinald a childreneket')
- vagy legyen egy record a rootnodehoz es egy tomb a childhoz (mint a demoban), es... es a child-tomb (mar bocsanat a szoert) egyik dimenzioja legyen a rootnode id-ja es search -keresgeljek benne attol fuggoen hol jar a rootnode kirajzolasa, vagy a root node recordjaba kellene bepasszintani hogy a child-tombnek hany eleme (kell a InitChildren eventhez!) lesz es akkor a child-tombbol lehet olvasni siman a pozicio alapjan?
K3) hasznaljam az InitChild eventet, vagy AddChild / InsertNode funkciokat (ezeket ki se probaltam meg)?
K4) kicsit nem fulik a fogam ahhoz, hogy letaroljam ami mar egyszer le van tarolva szepen az adatbazisba. ugy ertem ezert tartom az adatbazist. szoval nyitott vagyok barmilyen otletre, ha ez a tombozes bena dolog.
meg egy megjegyzes:
a konkret feladatban nincs szo hatalmas adatmennyisegekrol (parszaz/parezer rekord), de szeretnem ugy csinalni, mintha szamitana, mert az a tervem hogy ezt a komponenst hasznalnam mas dolgokra is. -
Alan
aktív tag
Ha a Mike Lischke-féle Virtual Treeview-ra gondolsz (a bonyolultság miatt úgy sejtem, ez lehet az), akkor szerencséd van, csináltam már vele programokat. Mit akarsz tudni?
Alapvetően virtuális komponens, tehát az a működés lényege, hogy megmondod neki, hány sora legyen, majd a cellák tartalmát magadnak kell feltölteni egy-egy esemény meghívódásakor (feltéve, hogy adatrács céljára kell). Persze inkább nem untatlak ilyenekkel, biztos komplexebb kérdéseid vannak :) -
lao ce
aktív tag
valaki dolgozik esetleg (az egyebkent kivalo) VirtualTree nevezetu komponenssel? esetleg valamelyik tovabbfejlesztett/atdolgozott valtozataval?
adatbazissal valo osszekotessel kapcsolatban jol jonne egy kis gondolatcsere, mert sokmindent lehet mondani a VirtualTree-re, de hogy egyszeru, azt nem :)
mindossze egy par napja kezdtem tapogatodzni ez ugyben, mondjuk ugy, hogy mersekelt sikerrel. van par homalyos pont, es van par dolog ami mar vilagos. inkabb iranyelvek erdekelnek, nem konkret kodreszletek. hetfoig kell professionalnak lennem benne :) -
Alan
aktív tag
Nem, a memóriakezelés ebből a szempontból teljesen más, mint a folyamat- meg szálkezelés és általános válaszok itt nagyon ritkán adhatók pontatlanul megfogalmazott kérdésekre. Szerintem ha tényleg érdekel, olvass ennek utána az msdn.microsoft.com-on, ott rengeteg hasznos cikket találsz.
A legjobb forrás emellett az Inside Windows 2000 c. könyv Mark Russinovich és Dave Solomon tollából. Igazi guruk ők, volt szerencsém találkozni is velük, és a könyvben nulla a marketing, csak hasznos és színvonalas, mélyszintű infók vannak. A rossz hír, hogy negyven-ötven dolcsiba kerül (viszont van hozzá CD, rajta egy halom kernel-hackelő segédeszközzel).
Igazi operációs rendszernek a Windows NT/2000/XP/2003 tekinthető, a 95/98/ME sajnos csak kísérletezgetés volt a Microsoft részéről. Természetes, hogy lefagynak benne a (rossz) programok, és sajnos az is, hogy magukkal rántják a rendszert, mert ott a kernel memóriaterülete nincs (teljesen) védve a programoktól.
Az NT-alapú rendszereket egyetlen módon, rossz (vagy rosszindulatú) eszközmeghajtókkal, vagyis driverekkel lehet ''kék halálba'' rántani (ezt a problémát viszont egyelőre nem lehet elvben sem kikerülni - ha az eszközmeghajtókat sem engedjük a hardverhez nyúlni, vagy nem engedjük, hogy a kernel címterében is dolgozzanak, azt a teljesítmény nagyon megsínyli).
Persze néha előfordul, hogy találnak emellett egy-egy kernelhibát, ami miatt szintén elkékül a képernyő, de ez nagyon ritka és általában csak extrém körülmények között fordul elő. A biztonsági problémák nem tartoznak ide, az sajnos egy egész más asztal. -
Alan
aktív tag
válasz
Auslander
#62
üzenetére
Gratulálok, Ausländer, és örülök, hogy ilyen klassz munkád van! Meg annak is, hogy Delphiben csinálod, bár ez szigorúan magánvélemény (remélem, nem jön el az az idő, amikor már csak Visual Studio X meg Visual Studio Y közül lehet választani) :) Sok sikert meg további érdekes munkákat kívánok Neked!
-
amargo
addikt
igy világosabb a dolog, viszont akkor miért van az, hogy kisebb programok kékhalállal elszálnak? vagy teszam azt memoria túlcsordulással? gondolom a memoria kezelésnél is piorítási alapokon mennek a foglalások és hogy kivel mikor foglalkoznak. vagy nem igy lenne? most álltalánósítva windowsról kérdezek, mert eddig linux alatt ilyen problemám sose volt.. vagy csak éppen. de win alat már jópárszor találkoztam ilyennel. 98 alatt rengetegszer elő fordult, de 2000alat eddig eccer sem(gondolom itt már kijavították a hibát).. de erről esetleg tudtsz vmit?
csak kiváncsiság képpen érdeklődöm, ha tudsz mutatni vmi oldalt azt is elolvasom, ne keljen annyit körmölnöd :)
igázából ezek a dolgok azért is érdekelnének, mert nekem is telt már meg a gépem programozás alatt ez kicsit idegesített.. bár hamar megoldottam egy memoria felszabadítóval.. viszont a programba is eztkéne beépíteni, mert eléggé félkészszaga van igy.. még csak most tanulom a programozást.. csak sajnos a tanárunk nem sok mindent árúl el ezzel kapcsolatban :(
köszönöm a válaszod előre is!
amargo -
Auslander
tag
<off>
Amúgy Németországban fejlesztesz, ezért lettél ''külföldi''? Miben dolgozol, meg milyen projekteken (ha itt is érdekes és elmondható)?
</off>
OFF
Igen, Németországban dolgozom. Egy DMS rendszeren dolgozunk, aminek szeptember 30-án volt a Release 1 bejelentése. Szóval nincs még igazán tesztelve:) Ez tulajdonképpen egy már meglévő rendszerünk frissítése. Ugyanis már tizenegynéhány éve a piacon van a régi termék, aminek ugyan kicsit szűkösek a lehetőségei, de ennek ellenére itt németországban piacvezetőnek számít. A lényeg, hogy az adott dokumentumhoz (ami lehet akár fax, e-mail, elektronikus dokumentum, bármi) attribútumokat lehet rendelni arhiváláskor, ami alapján a dokumentum újra elérhető, módosítható, stb... Az attributumok egy adott mask (form) segítségével adhatók meg, mind arhiváláskor, mind kereséskor. Természetesen ezek a form-ok Visual Basic-ben script-elhetők. A tape-library (hardver) szinten a cég terméke :)
A rendszer teljes egészében C++ -ban íródott, amíg én meg nem érkeztem (2001), és COM alapokra van helyezve. Az adminisztációs/rendszergazda program az én kezem által kelt életre. Segítségével menedzselhetők az arhiváló formok, kereső formok, jogosultságok, csoportok, felhasználók, meg minden. No ez teljes egészében Delphi-ben íródott. Nem kis időbe telt rávenni az okosokat, hogy hadd csináljam ebben. (No persze előtte rengeteg más feladatom volt, ami C++ -ban lett implementálva). Ebben a tool-ban egyébként a kedvencem a form-designer, ami (jobb hijján) a Delphi designerére hasonlít. Rendest Object Inspectorral, meg minden. Jó sokáig szöszmötöltem vele :)
No röviden ennyi. A Namespace extension is azért kell majd, hogy ne csak célprogrammal lehessen egy adott dokumentumot elérni, hanem direkt pl. a Word-ből is meg lehessen nyitni azokat, vagy az explorerből keresést indítani, vagy sorolhatnám még. Ámbár valószínű erre az idén már nem kerül sor.
Remélem nem leszek kihajítva a moderátor által.
ON
Köszi a linket rögtön megnézem,
Üdv:
Ausländer -
Alan
aktív tag
Nem olyan irgalmatlanul sok az.
Egyrészt ha a Task Manager-ben a Processes fülön a Mem Usage oszlopot nézed, észrevehető, hogy bár külön-külön nem annyira vészesek a memóruiafoglalások, a sok kicsi végül sokra megy. Másrészt pedig mivel a memória egy részének a lapozófájlban foglal helyet, nem annyira veszélyes a helyzet, mint azt a ''nagy zöld csík'' a Performance fülön sejtetné. Harmadrészt pedig egy csomó dolgot gyorsítótáraz a memóriában, azért is fogy látszólag gyorsan a fizikai memória (Performance fül, Physical Memory csoport, Total és Available mezők) - ha viszont másnak szüksége van ezekre a területekre, akkor simán megkaphatja, elég, ha viszonylag rövid időre viszonylag magas laphibagyakoriságot produkál.
Nagyon érdekes egyébként, hogy a programok (futtatható fájlok) betöltése is így, ''belaphibázással'' történik, tulajdonképpen be sem tölt semmit a rendszer, hanem foglal a programnak egy kis virtuális memóriát a minimális munkakészlettel, elindítja a programot, aztán a többit rábízza a memóriakezelőre. Ha jön befelé a tizenegy megás winword.exe, előbb-utóbb a kis munkakészlet miatt tömegesen fog laphibázni (inkább előbb...), és akkor úgyis kap majd még memóriát. Végül pont annyi fizikai memóriát foglal majd el, amennyi ténylegesen kell neki az induláshoz - tehát szinte biztos, hogy jobban jár a felhasználó, mintha az elején automatikusan lefoglalta volna a Windows mind a tizenegy megát a fizikai memóriából és betöltötte volna az egészet, majd aztán később lapozgatná kifelé a nem kellő darabokat.
''Lustaság fél egészség'', ez a loader mottója :) -
Alan
aktív tag
válasz
Auslander
#57
üzenetére
Csatlakozom, habár én azért hozzávenném a Digital Alpha processzorait is, míg ki nem nyírták őket.
Így van, az Alpha processzorok előtt is fejet hajtunk. Csodálatos sorozat volt, remek teljesítménnyel és gyönyörű architektúrával, én is sajnálom, hogy véget vetettek neki.
1. Ha én adom vissza, akkor új memória foglalásakor ezt igy érintetlenül nem kaphatom vissza. Ebben az esetben elvár(ha)tom, hogy nullázva legyen.
Ha te szabadítasz fel egy memóriaterületet és megint te kapod vissza, akkor szerintem előfordulhat, hogy optimalizál és nem nullázza ki, hanem már a szabad lapok listájáról kiadja. De ezen nem fogunk összeveszni :)
És amit igazából akartál kérdezni, arra sajnos csak azt tudom mondani, hogy namespace extension-ök írásában abszolút amatőr vagyok, de a [L]http://www.whirlingdervishes.com/nselib/[/L] oldalon láttam egy jónak tűnő keretrendszert, ami alapján legalábbis feltételezem, hogy protokoll típusú NE-re is van driver nélküli megoldás. Sajnos ebben más kell, hogy segítsen neked.
<off>
Amúgy Németországban fejlesztesz, ezért lettél ''külföldi''? Miben dolgozol, meg milyen projekteken (ha itt is érdekes és elmondható)?
</off> -
amargo
addikt
elolvastam Alan írását a lapozó területről, ami nagyon érdekes volt! viszont egy részét én másképpen ismerem.. volt egy rész ahol azt írtad, hogy a Windows memoria kezelése demokratikus én ezt jkicsit megcáfolnám.. mivel mindig elönyben részesití a saját programjait amivel nincs is gond mind addig amig a más kicsiny programok elöl halássza el a lapozó területet.. vagy a mutatít fogja és felül írja a kénye kedve szerint. és ilyenkor lőn ''kék halál'' és windows kolléga még elsem gondolkozik, hogy tette azt, hogy elszete a kicsi programocska elöl azta kis cimkét.
egy írás én is tudnék mutatni a memoria kezelésről :[L]http://www.microsoft.com/hun/technet/Memo.asp[/L]
bár amit Alan leírt az teljessen bemutatta a működését, de ez is érdekes olvasmány :) -
Auslander
tag
Szia,
Izlések és pofonok, szerintem kifejezetten jópofa megoldás, hogy ha kernel vagy, minden folyamat címterében ugyanott találod a cuccaidat
Ez ugyanúgy fennáll a másik megoldásnál is. No mindegy, túl sok jelentősége nincs.
Mihez kell neked nem lapozható memória? Drivert írsz? Olyasfélét is kell nem soká. NO azért ezzel kapcsolatban lesz majd kérdésem, ami inkább Windows specifikus, mintsem Delphi, de valószínű nagy érdeklődésre fog számot tatrtani mások részéről is :)
...Egyébként mindig kinullázott memóriát kapsz,...
Igen, most néztem az MSDN-ben, és valóban, a VirtualAlloc kinullázott memóriát ad vissza. Jó ezt tudni.
...ha saját magad által korábban használt lapot kapsz vissza, az nem biztos, hogy ki lesz nullázva (de ez nem is biztonsági rés).
1. Ha én adom vissza, akkor új memória foglalásakor ezt igy érintetlenül nem kaphatom vissza. Ebben az esetben elvár(ha)tom, hogy nullázva legyen. A VirtualAlloc ebből a szempontból rendben is van.
2. Ha rendszer vette le a working set -emből, és laphiba miatt kapom vissza, akkor viszont nyilván nem lesz kinullázva. Logikus.
Tíz másodperces néma főhajtás a Motorola 680x0 sorozat emlékére. A legjobb processzorok voltak.
Csatlakozom, habár én azért hozzávenném a Digital Alpha processzorait is, míg ki nem nyírták őket.
No akkor most jövök:
A problema a következő. Adott egy Namespace Extension (NE), ami valahonnan produkálja az infót a shell-nek, ami által pl az explorer meg tudja jelniteni a directory szerkezetét az NE-nek. Nomármost ez ugye csak egy virtuális adatszerkezet, fizikai megjelenése nincs. Viszont azt szeretnem, hogy amikor pl. a felhasználó Word-ből akar megnyitni egy állományt, ami az én NE-ben található, akkor én azt ad-hoc produkálni tudjam neki mondjuk egy adatbázisból, vagy akárhonnan máshonnan. Ezidáig ezt egy Filter Driver-el többé-kevésbé sikeresen implementáltam, de nem vagyok maradéktalanul elégedett vele. Többek közt azért sem, mert egy ügyes programozó simán átnyulhat felette, vagy mittoménmi. De legalább sikerült a Word-nek odaadni azt amit kért. Végül is járható út, de nekem nem szimpatikus, mert nem szeretnék minden Windows verzióra új driver-t írni. Arról nem is beszélve, hogy a NuMega 2.5 DDK is hagy bőven kívánnivalót maga után. Pár hetem elment vele, míg megírtam a hiányzó class-okat, és az sem biztos, hogy mind jó :F
Kérdés:
1. Van erre más megoldás a Device Driver írásán kívül?
2. Ez a 'protokol' kérdés hogyan működik? Szereném az adataimat a következő URL minta alapján definiálni: AUSLANDER://gipsz/jakab/proba.doc
(Valaki már említette a nevét, de rég volt, és elfelejtettem)
3. És ha ez működik, akkor ez könnyen beépíthető-e egy NE-be?
Egyébként a probléma nem teljesen független a Delphi-től, mivel a DeviceDriver kivételével minden Delphiben készült.
Előre is köszi:
Ausländer -
Alan
aktív tag
válasz
Auslander
#53
üzenetére
Szia Ausländer! Köszi szépen az elismerést :)
Hát persze, nyilvánvaló, hogy szinte semmit sem az ujjukból szopnak a fejlesztők, mindennek van előzménye. A VMS-t én annyira nem ismerem, bár azt az egyet tudtam, hogy a munkakészlet onnan ''származott át''.
Nem vagyok biztos benne, hogy a flat modell előnyösebb lenne a szegmentáltnál. Utóbbinál pl. viszonylag egyszerűen lehetne memóriamegosztást biztosítani két process között. Ez flat modellnél nem egyszerű. (jojo, használhatom a kernel memory space-et, de ez nem szép))
Ízlések és pofonok, szerintem kifejezetten jópofa megoldás, hogy ha kernel vagy, minden folyamat címterében ugyanott találod a cuccaidat :)
Memóriamegosztáshoz nem is kell a kernel címtere, erre ott vannak a prototípus-laptáblabejegyzések, amikkel hatékonyan, 4K-nként lehet megosztani a memóriát.
Én egyébként korábban Motorola processzorokat programoztam, és a szegmentálástól a mai napig kiráz a hideg... A szegmentálás és a lapozás együttes használatánál valószínűleg sokkal lassabb lenne a címleképzés TLB miss esetén, de egyéb más okát nem tudom, miért nem használja a Windows (sem). De ennek speciel örülök, sosem firtattam mélyebben a dolgot :).
Hogy kell Non Pagable memóriát allokálni Windowsban? És lehet-e kérni, hogy ez ki legyen már nullázva? VMS alatt ez működött. Erős a gyanúm, hogy Windows alatt is mennie kell valahogyan. Jó lenne, ha nem nekem kellene ezzel foglalkozni. A rendszernek van elég ideje, hogy nullázgassa a lapokat.
VirtualAlloc() vagy VirtualAllocEx(), majd VirtualLock(). Az egy folyamatnak biztosított non-paged pool alapértelmezésben nagyon kicsi (~30 lap), ezzel a fajta foglalással vigyázni kell, nem biztos, hogy sikerül. Mihez kell neked nem lapozható memória? Drivert írsz?
Egyébként mindig kinullázott memóriát kapsz, bármit is csinálsz (ez C2-es biztonsági követelmény), kivéve, ha saját magad által korábban használt lapot kapsz vissza, az nem biztos, hogy ki lesz nullázva (de ez nem is biztonsági rés).
Az Intel adottságai miatt ez lehetne akár 4MB-os page is. No jó, csak a 386-osoktól kezdődően
Hm, élvezetes is lenne végigülni egy-két egészséges belapozást 4 megás lapoknál :D Egyébként AMD Athlonnál lehet 2MB-os lapokat is kérni, de ez a gyakorlat tudtommal nem nagyon terjedt el. Tudom, a Windowsnál lehet kérni, hogy a kernel egy részét tegye 1 db nem lapozható 4 MB-os lapra, fejből már nem emlékszem, hogyan, de a registry-ben külön kézzel kell beállítani. A SlotA Athlonok ezen a téren pont hibásak voltak és ezt nem volt szabad rajtuk bekapcsolni, különben jött a kék halál.
Ja, és annak idején a Motorola 68030-nál 0,5 és 32 KB között lehetett állítani a lapméretet.
Tíz másodperces néma főhajtás a Motorola 680x0 sorozat emlékére. A legjobb processzorok voltak.
Az e-mail címemre küldhetsz kérdést, persze, de jobban örülnék, ha itt a fórumon megbeszélnénk az érdekesebbeket. -
Auslander
tag
Szia,
...csak az erdekesseg kedveert ossze kellene vetni mas oprendszerek megoldasaval...
Rendben, igaz én csak egyhez tudom hasonlítani, és ez a VMS/OpenVMS. Mivel a Windows NT fejlesztésében (leginkabb kernel) anno a DEC-től elcsábított/megvett fejlesztőmérnökök igen erős szerepet játszottak, ezért igen nagyfokú hasonlóság fedezhető fel a két rendszer memória/task kezelésében. A terminológia is közel azonos mindkét rendszer esetén. Azonos elvek a working-set-eknél, minkét rendszer pagefile.sys-nek hívja a lapozófájlt; a process által visszajuttatott memória a VMS-ben is először egy listára kerül, amit a processz visszakap, ha kell neki, ha még nem került vissza a rendszer listára, stb. Mindkét oprendszer flat-model-t használ. (Nem vagyok biztos benne, hogy a flat modell előnyösebb lenne a szegmentáltnál. Utóbbinál pl. viszonylag egyszerűen lehetne memóriamegosztást biztosítani két process között. Ez flat modellnél nem egyszerű. (jojo, használhatom a kernel memory space-et, de ez nem szép)). Azt, hogy most a VMS, vagy a Windows verzió a jobb azt nem tudhatom már, mivel a VMS-ről több mindent már nem tudok, mióta a Compaq(bérenc) megvette a Digitált. Brrrrrrrr.
Alan
Ha már így összefutottunk...
Hogy kell Non Pagable memóriát allokálni Windowsban? És lehet-e kérni, hogy ez ki legyen már nullázva? VMS alatt ez működött. Erős a gyanúm, hogy Windows alatt is mennie kell valahogyan. Jó lenne, ha nem nekem kellene ezzel foglalkozni. A rendszernek van elég ideje, hogy nullázgassa a lapokat.
...Intel hardver adottságai miatt 4KB-os blokkokban intézi a virtuálismemória-foglalásokat...
Az Intel adottságai miatt ez lehetne akár 4MB-os page is. No jó, csak a 386-osoktól kezdődően :)
Egyébként tetszik amit írsz. Tömör, lényegretörő, érthető.
Ha lenne Windows-al kapcsolatos kérdésem, azt a megadott e-mail címedre küldhetem?
Üdv:
Ausländer -
lao ce
aktív tag
mostmar egeszen eles ez a kep memoriakezelesrol.
lehet hogy azert, mert nincs alternativa mellette, de eleg jol hangzik ez az egesz, bolondbiztosnak es nagyon atgondoltnak.
csak az erdekesseg kedveert ossze kellene vetni mas oprendszerek megoldasaval, mert az az igazsag hogy szidom magamban en is a windowst, de mikor a kozelebe kerulok melyebben, azert valahogy mindig tiszteletremelotnak hat amit csinal. es ilyenkor ezek a mindennapi vitak hogy mit nem tud meg igy ugy biztonsagos vagy nem, eleg felszinesekke valnak.
a nagybitmappel kapcsolatban...
az az igazsag, hogy almodozasom arrol szol, hogy szeretnek irni (haha) egy hmm... emulaciot. o... eletter + novenyek, plusz allatok. nehany dolgot osszeolvastam az utobbi par evben az allatok viselkedeserol meg ilyesmi es azt kell mondjam, hogy egy programozo szemevel ezek rettentoen algoritmizalhatoak. megdobbentoen mukodokepes am ugyanakkor egyszeru (tenyleg) az egesz. persze bizonyos melysegben mar nem, de oda nem is kell menni, mert a modellezesnel ugyi nem a reszletesseg a lenyeg. -
Alan
aktív tag
biztos bena kerdes, de mit jelent pontosabban az, hogy a program tenylegesen hozzafer (hasznalatba veszi) az adott teruletet a gyakorlatban?
Azt, hogy olvas róla vagy ráír. Egy elvi pszeudokóddal illusztrálva,
ptr = malloc(8192); <= foglalás (allocation, 8K)
ptr++; <= nem történik semmi
ptr[30] = 0x64; <= első lap kommitálása (commit, 4K)
ptr += 5000; <= nem történik semmi
ptr[50] = 0x80; <= második lap kommitálása (commit, 4K)
ha atszinezem egy pixelet pirosrol zoldre az mar hasznalata az egesz kepnek vagy ez is 4k-s blokkonkent ertendo es csak azt a kis reszt vettem hasznalatba?
Az előző példából is láthatod, hogy laponként történik a tényleges használatba vétel.
A teljes igazság egyébként, hogy egy-egy lap utólagos kommitálásakor (tehát belapozáskor, ha már korábban bent volt a lap, csak valamiért, pl. a munkakészlet maximumának elérése miatt ezután valamikor a Windows kilapozta) nem egyesével hozza vissza a kért lapokat, hanem előreolvas 4-5 lapot és ''mögéolvas'' 2-t.
Magyarán ha Te az n. lapra hivatkozol és nincs bent a fizikai memóriában, akkor az n-2, n-1, n, n+1...n+5 lapokat mind behozza egy ''lökettel''. Hogy miért, azt biztosan könnyedén kitalálod :)
bizonyos almodozasaimban (programozasos - tudod, a 'ha lenne idom meg penzem' kezdetuek) szo van arrol hogy hatalmas true/high color kepet hasznalnek bizonyos nem kepi informaciok letarolasahoz.
Arar gondolsz, hogy a legkisebb helyiértékű biteket elrontod (mert úgysem látszik), és oda bevarrod az információkat? Jó kis trükk :), tudom, van valami neve is, valamilyen 'gráfia lesz ez is.
Ismerem ezeket az álmodozásokat, nálam halomban állnak a félkész freeware projektek... de azért egy szép napon, ha jön egy jóságos szponzor, mindet befejezem :) -
lao ce
aktív tag
''Első lépésben megnézi, hogy van-e még a kívánt méretben szabad hely a progrma (folyamat) címterében, ha van, akkor bejegyez egy foglalást egy táblázatba (virtual address descriptor table), de semmi mást nem csinál, nulla fizikai memóriát ad és laptáblákat sem készít az új memóriaterülethez (ezt hívják allokációs fázisnak). Csak vár. Arra, hogy a program ténylegesen hozzá is férjen az adott területhez. ''
es
''memóriát akkor rendel hozzá, ha ténylegesen használatba is veszi a program a kért területet ''
biztos bena kerdes, de mit jelent pontosabban az, hogy a program tenylegesen hozzafer (hasznalatba veszi) az adott teruletet a gyakorlatban? mondjuk ha betoltok egy bazi nagy kepet (loadfromfile :) - a delphi ugyi megnyitja a fajlt streamkent, beolvassa aztan a streamet felszabaditja), akkor az mar hasznalatba vetel? akkor az en nagy bitmapem bent van vagy nincs bent? ha atszinezem egy pixelet pirosrol zoldre az mar hasznalata az egesz kepnek vagy ez is 4k-s blokkonkent ertendo es csak azt a kis reszt vettem hasznalatba? (nem kell a peldahoz ragaszkodni ha valaszolsz)
bizonyos almodozasaimban (programozasos - tudod, a 'ha lenne idom meg penzem' kezdetuek) szo van arrol hogy hatalmas true/high color kepet hasznalnek bizonyos nem kepi informaciok letarolasahoz. -
Alan
aktív tag
Köszi, kedves tőled :)
A válaszok:
- te ezt tanitod valahol?
- Igen, de inkognitómat nem fedhetem fel csak úgy :)
- a woking set-et lehet latni a task managerben (a kozepso oldalon a processeknel)?
- Igen. Próbáld ki, hogy megnézed egy program munkakészletét, aztán leminimalizálod. Rögtön leugrik 1-2000 K-ra a munkakészlete, ha nem kevesebbre. Másik jópofa kísérlet: ha már úgyis Delphiben programozol, tölts be egy nagyobb projektet, fordítsd le, nyisd meg az összes formját, majd nézd meg a munkakészletet. Minimalizáld a Delphi-t. Nyiss meg egy csomó másik izmos programot (pl. Photoshop), működj bennük, hadd teljen a fizikai memória. Most pedig állítsd vissza a Delphi-t normál méretre. Két dolog történik: egyrészt a munkakészlete nem áll vissza teljesen (ezt már az eddigiek alapján is sejtettük), másrészt jó sokáig bevilágítja a szobát a merevlemez piros LED-je és szemmel láthatóan lassan rajzolódnak ki a Delphi ablakai. Miért? Mert közben a tevékenység hiánya miatt laphibákat sem nagyon generált, ezért a Windows fokozatosan elvette tőle majdnem az összes fizikai memóriát, így visszaállításkor a lapozófájlból jön vissza mind a 40-100 megabyte, amit addig elfoglalt.
- working set ujra: ''Ennek a méretét a rendszer maga szabályozza'' ez azt jelenti hogy novelheti es csokkentheti is, mivel szabalyozni probalja a page faultok masodpercenkenti szamat, ugye?
- Igen, pontosan így van. Azért van egy abszolút minimum, ami alá sosem viszi le, nehogy baj legyen, de ez csak pár száz KB. És természetesen van abszolút maximum is, a kettő között azonban elég nagy a Windows játéktere. -
lao ce
aktív tag
eloszor is nagyszeru iras, nagyon koszonom. vilagos es ertheto. minden elismeresem.
:)
- a foglalasnal a program egyertelmuen megmondja, mennyit akar maganak. ez nem tarolodik el valahol? hiszen ez az amit 'lefoglal', meg akkor is ha nem kapja meg.
- a woking set-et lehet latni a task managerben (a kozepso oldalon a processeknel)?
- working set ujra: ''Ennek a méretét a rendszer maga szabályozza'' ez azt jelenti hogy novelheti es csokkentheti is, mivel szabalyozni probalja a page faultok masodpercenkenti szamat, ugye?
az a helyzet, hogy kihuztam egy csomo kerdest, mert mire leirtam, rajottem hogy benne van az iromanydban a valasz. -
Alan
aktív tag
Lao ce, hát nekem is öröm, ha normális emberekkel társaloghatok, ráadásul egyre ritkábban adatik meg ez egy fórumon.
A Delphi telepítésénél meg lehet(ett) adni, hogy kéred-e a Win32 API súgóját, és ha kérted, akkor a Start -> (All) Programs -> Borland Delphi 6 -> Help -> MS SDK Help Files menüben találod az összes hozzá tartozó fájlt. Amire valószínűleg gondolsz, az a Win32 Programmer's Reference (win32.hlp), vigyázz, sok hasonló nevű van.
A délelőtt ma elég borongós, aludni nem sokat sikerült, úgy hogy minden feltétel adott egy jó kis Windows eszmefuttatáshoz :) ). -
lao ce
aktív tag
koszonet hogy visszaneztel :)
memproof letoltve.
dehogy haragszok, orulok hogy legalabb van aki erti az ilyesmit, es raadasul erre kolbaszol. termeszetesen erdekel (esetleg mast is), viszont ha tenyleg hosszu, akkor nincs szivem ilyesmire kerni teged. ha ugy erzed egyszer, hogy tul borongos a delutan, es az ujjaid faznak... nos, akkor esetleg... de nem surgos, mert az eddigi segitseggel amit kaptam toled mar tul tudom magam tenni ezen a feltetelezett probleman.
nem tudom egyebkent milyen delphit hasznalsz, en most tettem fel a hatost: teljesen kihagytak a win32 api helpet belole, vagy csak az en standard verziomnak nem resze? az otosomben benne volt - igaz csak 95/98/nt, de azert jobb volt mint a semmi. -
Alan
aktív tag
Van egy jó kis ingyenes szoftver, MemProof a neve, a [L]http://www.automatedqa.com/downloads/memproof.asp[/L] címről letöltheted. Nagyon szigorú, biztos megtalálod majd vele a szivárgást (debug infóval fordítsd a programot, különben nem tudja követni az erőforrásokat).
A másik részére elég hosszú a válasz, ugye nem haragszol meg, ha most éjjel nem pötyögök be sok ezer karaktert :) Igazad van egyébként, minimalizálásnál a Windows automatikusan nagymértékben lecsökkenti az adott program munkakészletét, feltételezve, hogy a minimalizált programmal nem fogsz interakciót kezdeményezni. Amikor pedig visszaveszed a programot normál méretre, nem kapja automatikusan vissza a korábbi mennyiségű memóriát, csak egy részét, ha szüksége van rá, ''visszafaultolja'' magának, tehát laphibákat fog okozni és ennek hatására kapja vissza a fizikai memóriát fokozatosan. Ha tényleg érdekel, szólj és akkor később leírom, miért meg hogy van mindez :) -
lao ce
aktív tag
koszonet a hm-ert, kiprobaltam, nem is tudtam rola, azt hiszem eletemben nem inditottam el a delphit parameterrel. kicsit fura nezni az ot es het jegyu szam valtozasat -ugy ertem vizualisan kicsit nehez kovetni, de majd megszokom.
Alan, nem tudsz nekem ajanlani valami helyet ahol ilyen van, vagy kodreszletet amivel ki lehetne irni mekkora memoriat is fogyaszt a programom? en valahogy azt hittem (arrol almodoztam) hogy van valahol egy api. de sehogyse hogy a szemem ele keruljon, szoval attol tartok ilyen nincs. neked van valami modszered / olvasmanyod / segedprogramod arra az esetre hogyha memory leakek utan nyomozol? (leszamitva a hm-et)
a bitmap olvasas utan megnovekszik a t/m altal mutatott memoria, aranyosan a beolvasott bitmappel, szoval novekedni azt tud. csak csokkenni nem. aztan mar higgadtabban atgondoltam, es rajottem hogy valami remlik errol -csak mikor errol olvastam akkor epp nem erdekelt-, hogy a windows a memoriat tenylegesen csak kesobb, ha szukseg van ra vagy valami, akkor szabaditja fel.
szoval, megprobaltam varni de semmi, mas alkalmazasok hasznalatanal valtozott az en prgom memoria foglalasa, de nem egeszen ertettem mikor es miert. vegul ugy nez ki, ha a minimalizalom a programomat es utana restore, akkor mindig es egyertelmuen megvaltozik (lecsokken) a taskmanagerben mutatott memoria hasznalat. vagyis nem a memoria hasznalat, hanem a memoria hasznalatra utalo szamok. :) -
Alan
aktív tag
Annyit egyébként még megtehetsz a Task Manager-ben is, hogy a Performance fülön a Commit Charge csoportban a Total mezőt figyeled, bár ez nem tökéletes, mert a teljes rendszerre vonatkozó aktuális virtuálismemória-foglalást írja ki (amiben nemcsak a Te programod változásai lesznek benne), de ha elég nagy blokkokat foglalsz és szabadítasz fel, akkor itt láthatod, hogy ''ugrál'' a memóriafoglalás, ha nem is pont annyival, amennyit Te foglalsz vagy felszabadítasz.
-
Alan
aktív tag
Sajnos a Windows memóriakezelése jóval bonyolultabb annál, hogy alloc/release és rögtön visszanövekszik a szabad memória.
Röviden legyen elég annyi, hogy a Task Manager-ben sehol nem láthatod, hogy a Te programod konkrétan mekkora részt foglalt le a saját 2GB-os virtuális címteréből (mert Te erre lennél kíváncsi, itt szabadul fel a FreeAndNil(WorkBitmap) után a virtuális memória). Csak a program munkakészletét, azaz a neki adott fizikai memória méretét látod, amit viszont a Windows maga szabályoz.
Egyébként egyszerű ''memory leak debugging'' kiválóan megvalósítható úgy is, hogy a Delphi-t a -hm paraméterrel indítod, így a címsorban folyamatosan frissített memóriainformációk lesznek az éppen futtatott programodra is (persze csak ha F9-cel futtatod). -
rdi
veterán
Na én se ma programoztam utóljára, lehet, hogy nem is értek hozzá, de a memória felszabadítása nem azt jelentené, hogy onnantól írhat rá bármelyik progi?
Vagyis a felszabadítással bennmarad a memóriaszemét??
Tehát ahhoz, hogy szabadnak lássék, kellene egy memóri resetelő program? -
lao ce
aktív tag
kezdem azt hinni, hogy valamit alapvetoen nem ertek. ennyi ev utan.
1) elinditom a task managert, raallok a kis programomra
2) van egy gombom megnyomni, erre betoltodik egy bitmap a memoriaba filebol. (loadfromfile)
3) megno a memoria fogyasztas
4) eleresztem (probaltam .free-vel es freeandnil-lel is)
5) nezem a taskmanager... a nagy fenet eresztodik el, ott terpeszkedik a diszno
D5 es D6 kiprobalva. elgepeles ki van zarva.
ja, a legerdekesebb ez a resz:
finally
FreeAndNil(WorkBitmap);
//WorkBitmap.Free;
Application.ProcessMessages;
end;
ha beteszem ezt a sort application.ProcessMessages, akkor a memoria megnovekszik! no, ezt mar vegkepp nem ertem.
esetleg valaki elmagyarazna nekem hogy hogyan is lehet kitakaritani a memoriabol valamit? en azt hittem hogy evek ota rendesen csinalom... aztan tessek. -
-
Edem
senior tag
off
MODERÁTOR? Gartula! :)
on
OK, köszönöm, megvan. Bár csúnya módon kikopiztam egy másik forrásból (kicsit gagyi, mert pl. a 20 nem mint konstans szerepel, de ezt már bárki megcsinálja).
type
TForm1 = class(TForm)
private
procedure WMWindowPosChanging(var Msg : TWMWindowPosChanging); message WM_WINDOWPOSCHANGING;
end;
procedure TForm1.WMWindowPosChanging(var Msg : TWMWindowPosChanging);
var
Desktop : TRect;
begin
Inherited;
if SystemParametersInfo(SPI_GETWORKAREA, 0, @Desktop, 0) <> True then
begin
Desktop.Left := 0;
Desktop.Top := 0;
Desktop.Right := GetSystemMetrics(SM_CXSCREEN);
Desktop.Bottom := GetSystemMetrics(SM_CYSCREEN);
end;
if (Msg.WindowPos.x >= Desktop.Left - 20) and
(Msg.WindowPos.x <= Desktop.Left + 20) then
begin
Msg.WindowPos.x := Desktop.Left;
end;
if (Msg.WindowPos.x + Width >= Desktop.Right - 20) and
(Msg.WindowPos.x + Width <= Desktop.Right + 20) then
begin
Msg.WindowPos.x := Desktop.Right - Width;
end;
if (Msg.WindowPos.y >= Desktop.Top - 20) and
(Msg.WindowPos.y <= Desktop.Top + 20) then
begin
Msg.WindowPos.y := Desktop.Top;
end;
if (Msg.WindowPos.y + Height >= Desktop.Bottom - 20) and
(Msg.WindowPos.y + Height <= Desktop.Bottom + 20) then
begin
Msg.WindowPos.y := Desktop.Bottom - Height;
end;
end; -
#25
Alan
aktív tag
CsendPenge
#24
Alan
aktív tag
válasz
CsendPenge
#24
üzenetére
Félreértesz. Csak a fejlesztőrendszerhez kell NT alapú operációs rendszer, a ''késztermék'' már utána elmegy bármin (persze ha memóriát szivárogtatnak a fejlesztők, akkor nyilván nem :))
A fejlesztéshez iszonyúan sok Windows resource kell általában, hiszen a fejlesztőrendszer betöltése után az éppen fejlesztett programhoz általában nyitva tart az ember legalább 20-25 ablakot, sokszor az összes formot, néha több nyelvű változatban, rajtuk az összes komponenssel, vezérlővel és kezelőszervvel... nem is beszélve arról, ha munka közben hibás verziók születnek, amik trutymót hagynak maguk után a memóriában (természetes velejárója a munkának).
Szóval programozás közben hamar elfogy az a pár ezer ablakkezelő Windows 9x alatt, erre gondoltam. -
#22
Alan
aktív tag
CsendPenge
#20
Alan
aktív tag
válasz
CsendPenge
#20
üzenetére
Igen, az 1. eset is könnyen elképzelhető. De még ha nincs is semmi hiba, a Windows 9x előbb-utóbb úgyis probléma lesz.
Ha viszont NT alapú rendszeren fejleszt a topicindító, akkor nagyon valószínű, hogy fején találtad a szöget. -
-
#20
CsendPenge
őstag
HEBI
#1
CsendPenge
őstag
Két lehetőséget tudok elképzelni.
1.
Szerintem a felszabadításnál lesz a hiba. Nem szabadítod fel az összes használt erőforrást, vagy nem megfelelően szabadítod fel. Itt gondolok arra, amikor egy olyan műveletet végzel, ami automatikusan foglal, viszont neked manuálisan kell felszabadítanod az erőforrást. (pl. FindFirst/FindClose )
2.
A másik lehetőség, hogy valami bug szívat. Persze nem feltétlenül ebbe a kategóriába tartozhat ez a gond. Valami olyasmira gondolok, mint amikor pl. külön szálat indítasz, asszem várakozó állapotban, és utána nem kerül futásra, hanem felszabadítod, (kinyírod) akkor az memóriaszivárgást okoz, mert valami leírót nem semmisít meg automatikusan a windows (és állítólag te sem tudod, persze /biztos? :D/ lehet, hogy csak én/te/ő vagyunk kevesek)
Bocsi, de konkrét megoldást nem tudok, de ez hátha segít. -
Alan
aktív tag
...az eredeti felvetésre pedig valószínűleg az a válasz, hogy Windows 9x rendszert nem érdemes fejlesztésre használni, mert fixen rögzített benne bizonyos erőforrások (pl. ablakkezelők) maximális száma, függetlenül a memória méretétől. (És a Windows-nál szinte *minden* ablak: a gomb, a kép, a menü, a menüpont, az ikon, az eszközsor, a panel stb.) Ezért mindegy, mennyi RAM-ot vesz az ember, a Windows 9x úgyis beakaszt.
-
Edem
senior tag
Hali,
Akkor álljon itt a megoldás:
1. Stop Delphi
2. Run Regedit
My Computer / HKEY_USERS /
/ S-1-5-21-1111581266-668016370-827027905-1000 /
/ Software /
/ Borland /
/ Delphi /
/ 6.0 /
/ Editor /
/ Options /
Itt hozzál létre egy új String Value-t. (Name:=NoCtrlAltKeys, Value:=1)
3. Start Delphi
4. Tools / Editor Options... / General / Editor SpeedSetting := Default;
5. OK, és már kész is. :)
Edem -
#14
Edem
senior tag
TheVeryGuest
#13
Edem
senior tag
válasz
TheVeryGuest
#13
üzenetére
Most úgy néz ki, hogy nincs más megoldás, át kell állítani.
-
Ice Hawk
csendes tag
Sziasztok!
Lenne egy kis gondom. Thread-eket szeretnék használni. Ezzel nincs is semmi gondom addíg, amíg Win 9x-en, vagy NT-n dolgozom. De amint áttérek 2k-ra, vagy XP-re a programjaim rögtön lefagynak. Illetve attól függ, hogy hány Thread-et használok lefagynak, vagy csak iszonyatosan megnőnek a válaszidők.
A szinkronizációval lehet gond? Hova kell szinkronizálni?
De az a helyzet, hogy ha Delphi könyvjöz kapott CD-n lévő progival is játszok, azzal is ugyan ez a jelenség.
Please Help! -
HEBI
senior tag
Sziasztok!
A progimban van egy komolyabb méretű image, ami egy framen csücsül. Erre rajzolgatok. De egy idő után a progi azt mondja : Nincs elég erőforrás. Nem rajzolgatás közben mondja, hanem mielőtt újra létrehozom és megjelenítem a formot amin a frame van. Miután bezárom a formot mindig felszabítom a memóriát, mert sokat eszik.
Nincs benne semmi logika mikor és milyen helyzetben produkálja a hibát.
A legszebb az egészben, hogy nem segít rajta, ha kilépek a progiból, sőt még a delphiből is, amíg nem indítom újra a gépet addig nem hajlandó megjeleníteni a progim egyetlen imaget sem. Újraindítás után ugyanaz az image simán megjelenik egy darabig.
Hozzátartozik az igazsághoz, hogy a háttérben egy másik formon szintén van egy image.
Hol lehetne ezeken a szükős erőforrásokon állítani?
A memória nem fogy el, van 250 MB (fizikai) üres... :O
Aktív témák
Hirdetés
- Nyíregyháza és környéke adok-veszek-beszélgetek
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Ubiquiti hálózati eszközök
- Vicces képek
- Medence topik
- One otthoni szolgáltatások (TV, internet, telefon)
- iPhone topik
- Ingatlanos topic!
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- További aktív témák...
- Easun iSolar SMW 11kW Twin Hibrid inverter // Dupla MPPT // BMS // WiFi
- GAMER PC : RYZEN 7 5700G/// 32 GB DDR4 /// RX 6700 XT 12 GB /// 512 GB NVME
- GAMER MSI LAPTOP : 15,6" 144 HZ /// i5 12450H /// 16GB DDR4/// RTX 4050 6GB/// 1TB NVME
- Manfrotto 055 magnézium fotó-videófej Q5 gyorskioldóval
- Sony ECM-W2BT
- Telefon felváráslás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Új! Targus - USB-C Dual HDMI 4K HUB - 2 HDMI-vel. Saját töltő nélkül 2 monitorral (120Hz)
- BESZÁMÍTÁS! MSI B450M R5 5600 32GB DDR4 512GB SSD RTX 3060 12GB THERMALTAKE Core V21 Enermax 650W
- Eladó szép állapotban levő Huawei P30 Pro kék 6/128GB 12 hónap jótállással!
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest