>> Szerinted mit csinal az a program, ami nem ir/olvas a memoriaba
>> (memoria I/O), nem vezerel kulso egysegeket (port I/O) es nem
>> kommunikal a felhasznaloval (konzol I/O)?

>Az NT szokott ilyeneket csinalni, bar az is elotte kekre festi a
>kepernyot ;-)

Nem kell az ilyen programokat alazni: orom ilyet irni. Rovid, tomor,
atlathato es nem dob fel kiveteleket. Egyebkent az NT ilyenkor is
kommunikal... billentyuzetmegszakitas, ami bizony olvas portot :)

Peter

Szia mindenki,

Osszefutottam (es futok, folyamatosan, egyre idegesebben) egy eleg
kenyelmetlen kulso access violation-nel a BDE DbiDoRestructure()
mezohozzadas kozben. Aki ugy erzi, hogy tud a hiba kijavitasaban
segitkezni, azt megkernem, hogy vegye fel velem a kapcsolatot. (bocs a
privatkodasert: nem akartam egy 200 sor feletti kodot a listara
kuldeni).

Ja igen, mielott meg valaki... nem, az ALTER TABLE nem jo ;-)

Elore is koszonom,

Peter

Hi,

talan egy magasabb felbontasu timer segithetne, ezt lattam valahol
komponensben, sajnos nevet nem tudok, de probalkozz a
www.programmersheaven.com-on.

Egyebkent a Port tomb olvasasa nem tul egeszseges dolog Windows alatt,
sokkal inkabb javasolnek egy third-party komponenst, van is ilyen a
www.borland.hu cimen.

UI.: Nem azert fagyott le a proggy a ciklus kozben, mert nem
hasznaltal Application.ProcessMessages-t, hogy az alkalmazasod is
levegohoz jusson?

Peter

Szia,

Mivel nem volt kizaro az angol nyelv, ezert rogton javallom azt, hogy
a Delphi 3 CD-rol installald fel az MS SDK Help-et, ami egy viszonylag
takaros API leiras.

Tovabba, ha nem sajnalod a penzt, erdemes megvenni a 2000 majusi MSDN
Library-t (ez ha jol sejtem, tobb CD, HTMLHelp), ebben dokumentaciok,
C headerek, gyakorlatilag minden megvan.

Peter

"*******************************************"
Sting Sting írta:
keletkezett: Thursday, June 01, 2000, 11:07:51 AM
Tárgya: "workshop 4.5" volt
"*******************************************"

Eloszor is koszonom a valaszt !

> Mentsd el az eroforrast egy fajlba (Resource|Save resource as...
> menupont) es nezd meg "kezzel"!

Megtettem, de a kov. kaptam vissza:
4 TEXT
{
 '40 77 41 72 40 36 37 3D 3C 3A 5C AF 72 32 7A 3A'
 '40 77 41 72 40 36 37 DE D7 DB B7 3C 9D D3 0C 6F'
 'E1 4B 96 B6 E1 C1 5C 91 80 21 EC CA D5 AB BE 3E'

stb.

Es ezzel nem mentem sokra :(

-- 
Szevasz,
    Ricsi                   
        mailto:
        Ifjusagi Unio: http://w3.swi.hu/xifu
Ha nem érdekel, hogy hol vagy, akkor nem tévedsz el.

Sziasztok!

Valaki meg tudná mondani magánba, hogy honnan lehetne letölteni Win
API függvények leírását? Angolul is jöhet.

Köszönettel: Varga Krisztián

>>Van egy veletlenszeruen feltoltott tombom
>>elemmerete: 4 byte (pl: +egesz szam)
>>elemszam: 2 millio (esetleg tobb)
>
>Tobben javasoltak a quicksort-ot, de szerintem az eredeti quicksort
>nem lesz jo.
>Javitsatok ki ha tevednek, ekkora elemszamnal nem lehet rekurziv
>rendezest csinalni mert telenyomja a stack-et es leall az egesz stack
>oveflow-al.
1. nyugodtan elvan meg egy csak par 10K-s veremben is a quicksort
ekkor tomb eseten, ti. a rekurzio melyseget eseteben az elemszam 2-es
alapu logaritmusa adja meg, ami 2millio elem eseten 20,93, tehat
gyakorlatilag max. 21 rutin melysegu rekurzio jon letre ekkora tomb
quicksorttal torteno rendezes soran. 1K lokalis vermet feltelezve
(amiben joval tobb minden elfer mint ami a rendezeshez szukseges, mert
az kb. 15-20 bajtbol kijon) ez osszesen meg mindig csak ~21K vermet
eszik, tehat siman elvan egy 16-bites forditval is. Arrol mar nem is
beszelek, hogy 32 bites forditok eseten a verem merete megnagyobb
lehet (pl. win32 alatt akar 1MB is).

>At kell irni a quicksortot hogy ne rekurziv legyen hanem ciklusokkal
>megoldani.
Ha tortenetesen tenyleg problemat jelentene a veremmeret, ezzel akkor
sem oldanal meg nagyon semmit, mert a rutin helyes mukodesehez
tovabbra is ugyanannyi hivasi menetenkent szeparalt teruletre lenne
szukseg, tehat valojaban memoriat nem sporolnal a dologgal, csak eppen
neked magadnak kellene a verem mukodeset szoftverbol emulalni.
(Gondold csak vegig!)

>Javaslom meg hogy ne irj a ciklusokba tul sok fuggvenyhivast (pl az
>adatok osszehasonlitasahoz stb) mert nagyon lassitjak a vegrehajtast,
>inkabb hasznalj makrokat.
Ez viszont valoban jo otlet es tenyleg erdemes alkalmazni minden
nagylepesszamu ciklus eseten.

Gabor

>Irok 1 programot, amibe olyan stoppert kell tennem, amit az lpt
>portra adott jel tud inditani es leallitani.
>Probaltam a ttimer-re akasztani a portkiolvasast, de ez nem felel
>meg, ha nagyon rovid a jel!
>A masik megoldas amire gondoltam az a "while port[$379]<>... stb "
>ciklus , de ez egyaltalan nem lenne egeszseges megoldas,mert kozben
>fagy a win. Szerintetek hogy probalkozzak? Hogy oldjam meg azt, hogy
>induljon es lealljon az ora?
>Delphi 1-ben irom, mert 486-os gepre lesz, 3.1-es win ala.
A fagyast a Yield() vagy a GetMessage()/PeekMessage() periodikus
hivogatasaval tudod elkerulni. A baj csak az, hogy mivel a Win3.1 nem
preemptiv, igy semmi garancia nincs arra, hogy adott idon belul
visszakapja a vezerlest a programod, tehat igy meg ugyanugy lehet,
hogy lemaradsz az esemenyrol, mint ha ugyanezt a dolgot a timer-ra
biznad. A legkorrektebb talan az lenne, ha racsucsulnel az LPT port
megszakitasara (ez akkor valtodik ki, ha valtozik az LPT-port
status-vezetei kozul valamelyik) es igy biztosan azonnal ertesulnel a
valtozasokrol. Hogy hogyan lehet ilyesmit Win3.1 alatt megcsinalni,
azt viszont sajnos nem tudom...


Gabor

>Lenne egy kerdesem a subj. beli programmal kacsolatban. Van egy exe
>fajl, amit beolvasok. Kul dolgokat talat: bitmap, icon, es text
>tipusokat. Az elso kettovel semmi gond. Szepen megmutatja a kepeket.
>Azonban a text-nel azt irja ki, hogy "Resource is too large to view
>as text"
>
>Hogyan tudnam megis megnezni a szoveget ?
Mentsd el az eroforrast egy fajlba (Resource|Save resource as...
menupont) es nezd meg "kezzel"!

Gabor

>> Mentsd el az eroforrast egy fajlba (Resource|Save resource as...
>> menupont) es nezd meg "kezzel"!
>
>Megtettem, de a kov. kaptam vissza:
>4 TEXT
>{
>'40 77 41 72 40 36 37 3D 3C 3A 5C AF 72 32 7A 3A'
>'40 77 41 72 40 36 37 DE D7 DB B7 3C 9D D3 0C 6F'
>'E1 4B 96 B6 E1 C1 5C 91 80 21 EC CA D5 AB BE 3E'
>
>stb.
>
>Es ezzel nem mentem sokra :(
Ez azert van, mert .RC formatumban mentetted el. Valasz ki inkabb a
"user resource type"-ot (ha van ilyen) vagy a .RES formatumot. Ezek
mind binarisan mentik el az eroforrast es igy maris olvashato lesz az
eredmeny...

Gabor

Csao!

A quicksort védelmében:

- nem rossz az algoritmus, főleg, ha azt a trükköt alkalmazod, hogy
amikor egy részhalmaz utolsó három elemét rendezed, azt csak
összehasonlítod, nem pedig re kurziót alkalmazol rá. Ez a megoldás
minden komolyabb quicksort implementációban benne van, tudtommal pl a
Turbo Pascal RTL forrásában is, mivel erősen csökke nti a rekurziók
számát. Ha tehát ezt megszerzed valahol, jó quicksortod lesz fo
rrásban.

- Igaz, hogy nem feltétlenül kell rekurzió, mert át lehet alakítani
ciklussá. K érdés, hogy megéri-e? Az adatokat ilyenkor ugyanis nem a
rendszer stack, hanem a user veremnek kell befogadni. A nyereség nem
biztos hogy számottevő, a kód vi szont sokkal bonyolultabb. Szvsz 1-2
millió rekord 32 bites programoknál erre e gyáltalán nem korlát (C++
Builderben lazán elmegy), ha ügyelsz rá, hogy a rekurzív
függvényhívás minél kevesebb paramétert nyomjon be a stack-be (ami fix
para méter, globális változóba kell tenni - persze ha nem
multithreaded kódról van s zó).

- Ha nagyok a rekordjaid, vagy lassú a másolásuk, lehet hogy sokkal
gyorsabb le sz a megoldás, ha a rekordokat beteszed egy tömbbe,
készítesz egy másik tömböt, amiben integerek vannak (C-seknek
pointerek, hurrá:) - ezek az egyes rekordok indexei, majd ezeket az
integereket rendezed, és végül az általuk mutatott sorrendben írod ki
a rekordokat a kimenetre. Ez azért jó, mert - az esetleg nagy méretű
- rekordok ide-oda másolása lassú lehet, szemben a gyors integer
másolással.

- Ha tárterület korlátod van, akkor nem memóriában levő rendezésre
kell felkész ülni, és érdemesebb I/O műveletre optimalizálni: pl
többmenetes összefésülő ren dezést kell alkalmazni. Ez igen jó, ha meg
tudod mondani, mennyi memóriád is áll rendelkezésre, és ebbe hány
rekord fér be (szinte mindig igaz). Ez már ipari szintű megoldás, ami
nem fog elhasalni 10-szer ennyi rekordnál sem. Megoldás -> Knuth
könyv. Egyszer meg is csináltam az algoritmust, és tényleg viszonylag
gy orsan működött néhány tíz millió rekordra. Itt a kulcs az, hogy a
quicksort lef oglalna annyi memóriát, amennyi fizikailag nincs is a
gépedben, és egymástól tá voli elemeket olvasna ki belőle, ezért
állandó swap-pelésre késztetné a rendszert, ami egyáltalán nem
optimális. Az összefésülő rendezés annyi adatmennyiséget rendez
egyszerre, amennyi a memóriába belefér (vagy amennyit megmondasz
neki), majd párhuzamosan olvas be több rendezett részhalmazt, és
elemeiket megfelelő sorrendben kiírja. Elvileg ezt szalagra találták
ki, de azt hiszem, diszkre is kielégítően működik. Azt kellett csak
belőni, hogy
   Szumma(input pufferek mérete) = Szumma(output pufferek mérete)
mert így lett optimális sebességű.

Javítsatok ki, ha sok hülyeség volt benne...
-- 
Józsi

Szasztok!

>>>>  The Font Creator Program 2.2  <<<<
 ----- ez egy nagyon  szupi kis program!   Mindent tud amit kell,
tudsz új betűkészleteket csinálni  ill. szerkeszthetsz meglévőket...
OS:            WIn98 , NT , Win 2000 
Program:    fcp2.exe   ----- méret:   1,13 MB (1 193 522 bájt)
contact :    
          http://www.high-logic.com/
----csak megjegyzem:  ha vége van a 30 napos trial idődnek->
regedit----- töröld a bejegyzést...nocsak újból +30 nap...:-)))----

< tsa: Mike >

Sziasztok!

HC> Felado :  [Hungary]
HC> MFC alatt szeretnem megcsinalni azt, hogy egy tobbsoros, nem
HC> editalhato CEdit-ben ha belefer az editboxba a szoveg akkor
HC> letiltom az emiatt kulonben felesleges scrollbarokat. Igy helyet
HC> takaritok meg es nem lesz olyan baromi ronda a ket szukre
HC> scrollbar miatt. Ehhez GetClientRect-tel lekerdeztem a window
HC> meretet es CDC::GetTextExtent()-tel meg a szoveg meretet. Sajnos
HC> elegge
Erre a CDC::DrawText-et kell hasznalni, a DT_CALCRECT flaggel. Vagy
CEdit eseten a GeLineCount()-tal beszorozni a GetTextExtent() altal
visszaadott egysoros magassagot.

:-))))))))

Udv.
 Pisti                            mailto:

Hellosztok coderek,

Volna egy problemam. Win2k alatt probaltam programozni protected
modeban, de ugye ertheto okokbol nem engedelyezett sokat (mondhatni
semmit) a win2k. watcom v11-el forditom a programjaim es most
egyenlore kulon particion hasznalok win98-at hogy hasznalhassam a
WCIDE+UltraEdit32 combot, de orulnek ha egyaltalan nem lenne szuksegem
a win98-ra munkahoz, csak jatekhoz (az meg minek? ;)

A masik kerdesem, hogy jol veszem-e ki hogy egyaltalan nem elterjedt a
watcom? En nagyon szeretem, de irc-n kerdezoskodve ) az
emberek a szot se ismertek hogy wc :)

Szoval varom az (epito) valaszokat. Koszi!

Rev

> Javitsatok ki ha tevednek, ekkora elemszamnal nem lehet rekurziv
> rendezest csinalni mert telenyomja a stack-et es leall az egesz
> stack oveflow-al.
Ugy is megoldhato, hogy akkora reszeket kell egyszerre rendezni
rekurzivan, aminek a rekurziv hivasai meg elfernek a stack-on, ezutan
ezeket a kulon-kulon rendezett csomagokat kettesevel osszefuzni.
Persze ekkora halmaz mindenkeppen kulon kodolast es vegiggondolast
igenyel (es esetleg nehany sebessegi kiserletet).

Udv: Szabolcs

Sziasztok!

Az lenne a kerdesem, hogy letezik e olyan DBGrid komponens, amely
lehetove teszi adott oszlop szerinti rendezest (csokkeno/novekvo), de
ugy, hogy nem kell hozza pl. egy sql- es lekerdezest keszitenem.
Ha van ilyen akkor mi a neve es hol lehet letolteni.

Koszonom, sziasztok

Sziasztok!

> Lenne egy kerdesem a subj. beli programmal kacsolatban. Van egy exe
> fajl, amit beolvasok. Kul dolgokat talat: bitmap, icon, es text
> tipusokat. Az elso kettovel semmi gond. Szepen megmutatja a kepeket.
> Azonban a text-nel azt irja ki, hogy "Resource is too large to view
> as text"
>
> Hogyan tudnam megis megnezni a szoveget ?

Probald meg elmenteni RC fajlkent. Ha sikerul, akkor akar a WordPad
is alkalmas a megnezesere.

--
Udv.:
Joco

Sziasztok!

Elnezest, ha off topic a keresem.
Keresnek valakit, aki gyakorlott a C++ Builderben, komponens
keszitesben, es hajlando lenne, termeszetesen penzert, kvazi tanfolyamot
tartani nekem. Nehany napon at, konkret problemak megoldasat szeretnem
megtanulni a segitsegevel.

Udv.:
Joco