writes:

> Hi Coderek!
>   C++ -ban kellene lekerdeznem egy file-nak a nagysagat, de sehogy se
> talalom a fugvenyt hozza.

filestream.seekg(0, ios::end);
int filesize=filestream.tellg();

> A C++-ben hogyan seek-elhetek. Megtalaltam a seekg-t, de csak ez van? Mi az
> az ios::beg

 aka SEEK_END

Yo.

 Nem talalkozott meg vki azzal az erdekes esettel, hogy createwindow-val
csinal egy progressbar gyerekablakot, majd ha mar nem kell
destroywindow-val eldobja. Ekkor szepen el is tunik, de ha atvaltasz masik
taszkra majd vissza, megint ott van, de olyan "felig-zombi" modban, mert
aktivva tenni mar nem lehet, de a RECT-jet ujrarajzolgatja a windows!!!

 Aron
 http://www.vein.hu/~gombasa  (downloadable sources!)

>Hali!Van valakinek otlete, hogy delphi3 alatt hogyan lehet egy ablakon
>eltuntettni vagy az ablak terulete folul kimozgatni (nem kezzel :) az
>egerkurzort, es hogyan lehet egy .cur fileben levot egy adott
>ablaknakmegadni. 
>(A helpben levo pelda nekem nem akart mukodni) 
A mozgatasoz hasznald a kovetkezo fuggvenyt: 
setCursorPos(x,y:integer):LongBool; 
Az x es y a kepernyo kordinatai LongBool meg false ha nem elvegezheto a
muvelet 
Az eltunteteshez: 
Screen.cursor:=crNone; 
+ az illeto form cursor-jat is kell szettelni amennyiben TWinControl
szarmazasu 
komponensek van rajta(Pl.TEdit) 
Visszaterites : 
Screen.cursor:=crDefault;+lasd feljebb

Gyula MATYAS

Hali!

A kovetkezo lenne a problemam. Sakkprogramot irok, es a tablat egy
unsigned char tipusu, 144 hosszu karakterlancban tarolom. (Azert kell
nagyobb belso tabla, hogy rendesen lehessen a lepeseket vizsgalni.)
Ugyebar 144=12*12, es ennek en a belso 8x8-os reszeben tarolom magukat
a babokat, amelyeknek helyet hexadecimalisan jelolom. (0x01 a vilagos
gyalog, 0x02 a huszar...stb.. 0x81 a sotet gyalog, 0x82 a sotet
huszar, stb.) Namarmost, egy fuggveny parameterkent megkap egy ilyen
tombot, amibe beleirja a figurak alaphelyzetet a megfelelo helyekre.
Ezek utan az alaphelyzetes tablat megkapja egy masik fuggveny, ami a
8x8-as tablat a megfelelo sorreszek vegigpasztazasaval (es a megfelelo
helyekre megfelelo szimbolumok beszurasaval) kiirja. Es itt
jon a hiba: a kiirott tablan rajta van a ket ellenfel alaphelyzete
teljesen jol, csakhogy a kozottuk levo 6 soron nehany helyen olyan
karakterek jelennek meg, amiket en nem irtam oda, viszont ezek a
karakterek csak azokbol a tipusokbol szarmaznak, amiket hasznaltam a
figurak abrazolasara. Ezenkivul, olyan is volt, hogy lefuttattam a
progamot, kiirta a tablat, es amiutan megint lefuttattam, a
"szennyezo" karakterek mar mashol voltak. Harmadszori futtatasra mar
nem mozdultak el helyukrol. Ja, es az egesz karakterlanc maradt, ugy,
ahogy volt (vagyis csak azokat a mezoket valtoztattam, amikre
figurakat akartam tenni, a tobbi mezo maradt 0.)

Remelem viszonylag erthetoen leirtam. Maganba irjatok, mert nem vagyok
fent a listan.

Ja, es meg valami: a karakterlancokat unsigned char tipusu mutatokat
varo fuggvenyeknek adom at.

Kosz:Balint

ui: ha esetleg nem volt ertheto, akkor kicsit altalanosabban: egy
karakterlanc bizonyos elemeinek (de nem az osszesnek) erteket adok.
amikor ezt a karakterlancot egy fuggveny kiirja, olyan helyeken
jelennek meg karakterek, amelyeknek nem is adtam erteket.

Szevasz/tok!

>Felado :  [International]
>  C++ -ban kellene lekerdeznem egy file-nak a nagysagat, de sehogy se
>talalom a fugvenyt hozza.
>A C++-ben hogyan seek-elhetek.

Nem irtad, hogy melyik C++-ban, de tegyuk fel, hogy Borland-ban. Vagy
mindegyik forditoban vannak ugyanolyan fuggvenyek? Ugye nem.

fseek(); a seek fuggvenye, es altalaban a file kezelok f-fel kezdodnek, ott
keresd oket.
ftell(); a file aktualis helyere mutat. Ha a file vegere seek-elsz es ott
ftell, akkor megkapod a hosszat.

Pl:
    if ((l_pFileInput = fopen(p_ubaFilenameInput, EV_FILE_READ_BIN)) != NULL)
      {
      if (fseek(l_pFileInput, 0L, SEEK_END) != 0)
        vFatalError(IDS_FILE_SEEK_ERROR, "flgFileCopyWithProcess");
              // ez erdektelen most
      else
        l_lFileLength = ftell(l_pFileInput);

      // file close ide kell
      }

(Kuldtem listara es maganba is.)
(::-)> Torma Istvan, TOR, 
A valaszokat ide a listara kerem, mert olvasom es mert mast is erdekelhet

>>Megtudna valaki mondani, hogy hogyan lehet kezelni delphiben a
>>StringGrid, vagyis a tablazat sorait. Tehat hogy kell az egyes soroknak
>>erteket adni, es hogy kell a tablazat fejlecet megcimezni. Valaszokat
>
>Nekem is ezzel lenne gondom. Merthogy a TStringGrid.RowCount az longint,
>de a Rows[], Cols[], Cells[] -ben mar csak integer szerepel indexkent.
>Es ahogy kell, 32768-nal el is szall a program.

Hanyas Delphi-t hasznalsz? A 32-bites Delphi-kben (2,3,4,5) ugyanis
integer=longint, magyarul ez onmagaban nem lehet problema (ha 16-bites,
Delphi 1.0-t hasznalod akkor amugy is ideje valtanod).
Ha pedig nem range-checkkel hal meg, akkor pedin nem veletlenul van a
limit - valoszinuleg csak ennyit tamogat valamelyik winapi fuggveny.

>Van valami otletetek ez ellen? Nekem 100000 sorra lenne szuksegem (+1
>fejlec). Es egyszerre mindre.
Nezz korul valamelyik ismert komponens-lelohelyen (pl. DSP) . Ugye nem
tablazatkezelot akarsz csinalni?

Gabor

On  9 Sep 99 at 14:48,  > wrote:

> az 1..n tartomanyban minden szam pontosan 1x fordul elo? Ha igen, akkor n
> tomb az n elem i-edik permutacioja. Nem lehetne ezt mindossze ket ertekkel
> reprezentalni: n es i? Vagy nem jol gondolom?

De, jol gondolod. Nekem is volt ilyen otletem eredetileg, de aztan
nem gondoltam bele igazan (ezert nem is irtam), mert 'megremultem'
attol, hogy milyen lassan lehetne kodolni/dekodolni ezt a
kompresszalast (n elemnek n! (n faktorialis) fele permutacioja
lehet, es n! marha gyorsan megszalad. n^n nagysagrendben.)

Viszont ha mar elohoztad, kicsit belegondoltam: (bocs, kicsit hosszu)

Szoval eloszor a kodolas/dekodolas sebessege: Mindkettohoz az kell,
hogy eloallitsuk az osszes lehetseges permutaciot, es abban
megkeressuk (illetve visszafele megindexeljuk) valamelyiket. n=10
eseten 10! = 3628800 (>3millio) fele permutacio lehetseges, es a 10
meg azt hiszem, nagyon pici szam, hisz szavas szamabrazolasrol is
volt szo. A negyjegyu fuggvenytablaban csak 20-ig vannak meg a
faktorialis ertekek (20! = 19jegyu szam), de Python-ban irt pici
progival megneztem meg parat (a Python-nak van korlatlan pontossagu
aritmetikaja is): pl. 256! = 1677 jegyu szam, 4096! = 43244 jegyu
szam. Meg akartam nezni 65536! szamjegyeinek a szamat is, de fel ora
alatt meg sehova se jutott a program (igaz, hogy regi 486-os gepem
van itthon).

Akkor most kompresszalas: Ha az ido nem szamit, akkor mennyire lehet
osszenyomni igy a file-t? Az egyszeruseg kedveert szamoljunk 2
hatvanyu n szamokkal. Ha az 1..n=2^k szamok permutacioja a bejovo
rekord, akkor ez n*k bit hosszusaga (egy szam k bites, es van belole
n darab. Szoval mar az eredeti 1 byte/adat illetve 1 szo/adat
szamabrazolasbol a felesleges felso tuti nulla biteket lehagytam,
hisz az egy termeszetes kompresszalas. Es persze a szamnal 1-gyel
kisebbet erdemes berakni, igy 2^k is befer k bitbe). Ebbol a
permutacio indexet adjuk ki egyetlen szamkent, ez olyan hosszu, amibe
belefer barmelyik lehetseges index. Nezzuk csak:

n=32, be=32*5 bit, 32! = 118 jegyu binaris szam, tehat 118 bitre van
szuksegunk az index abrazolasahoz, tehat 118 bitre kompresszaltuk.
  160->118, 26% nyereseg.
n=64, be=64*6 bit, 64! = 296 binaris jegyu, 384->296, 23% nyereseg
n=128, be=128*7 bit, 128! = 717 binaris jegyu, 896->717, 20% nyereseg 
n=256, be=256*8 bit, 256! = 1684 binaris jegyu, 2048->1684, 18%
n=512, be=512*9 bit, 512! = 3876 binaris jegyu, 4608->3876, 16%
n=1024, be=1024*10 bit, 1024! = 8770 binaris jegyu, 10240->8770, 14%
n=2048, be=2048*11 bit, 2048! = 19581 jegyu, 22528->19581, 13%
n=4096, be=4096*12 bit, 4096! = 43251 jegyu, 49152->43251, 12%

No, azert nem rosszak ezek a 10..30 szazalekos nyeresegek. Meg az is
lehet, hogy ennel jobbat a gyakorlatban nem lehet massal se elerni.
A tegnapelotti substring-keresgelos algoritmus pl. (ami egyetlen
permutacion belul termeszetesen egyaltalan nem mukodik) akkor tud
kompresszalni, ha sok permutacio van, es azokban a permutacio
sorrendje nem tokeletesen veletlenszeru, hanem viszonylag gyakoriak
a hosszabb-rovidebb sorozat ismetlesek.

No, meg visszaterve erre a permutacio-indexre: Ahogy meggondoltam a
kodolas lassusagat, elkezdtem gondolkodni azon, hatha lehetne valami
trukkel gyorsabbat is kihozni. Azt nem sikerult, de kitalaltam
valami masmilyen algoritmust:

Van tehat n darab szamunk, ami egy permutacio eredmenye. Megint 2
hatvanyokkal szamoljunk az egyszeruseg kedveert, n=2^k. Ezeket a
szamokat tehat kapasbol eleg egyenkent k biten abrazolni.

Induljunk ki egy n elemu listabol, amit 1..n-re inicialunk. Vegyuk
egymas utan a kodolando szamokat, es adjuk ki a listabeli indexuket k
biten, aztan toroljuk a szamot a listabol (es tomoritsuk a listat).
Amikor n/2 szamot kiadtunk, utana mar csak masik n/2 fele szam kozul
valaszthatunk, a listaban is csak ennyi van, ehhez tehat elegendo 1
bittel rovidebben, k-1 biten kiadni az inexeket. Amikor eljutunk
n/2+n/4-ig (vagyis n/4 darab szam marad a listaban), akkor
raterhetunk k-2 bitre, stb., teljesen a vegeig, ahol az utolso elotti
szam indexehez (lista 2 elemu) mar csak 1 bit kell, az utolszo szamot
meg el is felejthetjuk, hisz az mar egyertelmu: ami maradt.

A dekodolas azt hiszem, konnyen adodik: Ugyanolyan teljes listabol
kell kiindulni, eleinte k bitet kell beolvasni, es beleindexelve a
listaba kapjuk a dekodolt szamot (a listabol ezt toroljuk). Aztan
egyre rovidebb bithosszon jonnek az indexek, vegul amikor egyetlen
szam maradt a listaban, ahhoz mar nem jon 1 bit sem, az lesz az
utolso dekodolt szam.

Tetszetos algoritmus, meg persze gyors is, de sajnos nem elegge
hatekony: n=2^k eseten kijon a kodolasbol 2^(k-1) darab k bit,
2^(k-2) darab k-1 bit, ..., 2^2 darab 3 bit, 2 darab 2 bit, 1 darab 1
bit (es 1 darab 0 bit :) A nyereseg ahhoz kepest, hogy eredetileg
lenne 2^k darab k bit, a kovetkezo: 2^(k-1)+2^(k-2)+...+2^2+2+1 = 
2^k - 1, vagyis n-1 bit. Mennyire jo ez:

n=32, be=32*5 bit, nyereseg=31 bit, 19%
n=64, be=64*6 bit, nyereseg=63 bit, 16%
   minel nagyobb az n, a nyereseg annal inkabb 1/k ( =1/log2(n) )
Vagyis n=128 -> 14%, n=256 -> 12%, n=512 -> 11%, n=1024 -> 10%,
stb., n=65536 -> 1/16=6%

Azert ez is kiadja a permutacioindex algoritmus nyeresegenek
ketharmadat. Meg persze a gyakorlatban, a tegnapelotti
substringkeresos algoritmushoz hasonlokkal valo osszehasonlitaskor
figyelembe kell venni azt is, hogy pl. 1..64 erteku szamok eseten az
eredeti 8 bit/adatrol (vagyis egy permutacio rekord = 64 byterol)
tortenik a kodolas, es a kijovo 41 byte (321 bit) 36%-os
kompresszalast fog adni, nem csupan a fentebbi elvi 16 szazalekot.
(Ugyanez vonatkozik a permutacioindexes kodolasra is termeszetesen.)

 ... Most, hogy leirtam mindezt, ugy erzem, a ketfele kodolast 
(valtozo bithossz + permutacioindex) ossze lehetne megiscsak 
hazasitani, hogy gyorsan lehessen a permutacioindexet kiszamitani...

No, jol van, most mar bedugulok, sziasztok :)

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

Udv

Megoldast keresek arra , hogy megtalaljak egy file-t. 
Semmi egyebb nincs meg  csak annyi , hogy mi a file neve . 
Delphiben kene a megoldas
A FindFirst FindFile fugvenyek pont nem ernek semmit, mivel , konyvtarat
kell megadni.

Koszi