Kedves Lista!

Sajnos az eredeti kerdesemre nem jott valasz. Megprobalom egy kicsit
atfogalmazni...

Hogyan lehet egy VB osztalyt mas munkafuzetek makroi szamara is
elerhetove tenni?

Megprobaltam xla-ba tenni, de csak a modulban levo fuggvenyek lettek a
worksheet-eken elerhetok. A xla class modul-jaban levo osztalyaimat
nem latta. Hogyan tudnam rabeszelni az EXCEL-t, hogy ne kelljen minden
workbook- ba bemasolnom a class definiciokat?

EIK && udv From:, a zart osztaly

Hello Akos!

>Az altalatok ajanlott kodban hogyan oldanatok meg pl. a valtozo szamu
>(es tipusu) parameterek atadasat (pl. tegyuk fel, hogy a printf
>fuggvenyt tudom megcsapolni, de a sajat kod utan valtozatlanul meg
>kellene hivnom az eredeti printf-et).
>Ezen kivul keves eroforras (pl. stackmeret) eseten es tobbszor
>meghivott nagy parameterszamu fuggvenynel konnyen tulcsordulhat a
>stack.

En meg csak most lattam Deme megoldasat, a struktura otlet miatt az a
teljesebb. (Gyanus hasonlosag oka, hogy o is miskolci :-o) Mivel a
parametereknel nem magukat a parametereket adod at, hanem csak egy -
az adatokat tartalmazo strukturara mutato - pointert, "bazi" sokszor
meg lehet hivni stack overflow nelkul.

A tipusokat illetoen Deme kodjat kiegeszitheted mas tipusokkal is:

typedef struct {
        int a,b,c,d;
//..
        char *e;
        long f;        ...
                       } paramtyp;

Be kell valljam ferfiasan, ezt a printf-es dolgot nem ertem teljesen.
Az a problema, hogy a fgv. torzsen belul atirod a valtozok erteket? Ha
igen, akkor hasznalj lokalis "paramtyp" tipusu valtozot!

Remelem segitettem.

Udvozlettel:
___________________________________________________Molnar Sandor____
 , 
http://mazsola.iit.uni-miskolc.hu/~molnars

>  [Hungary])
>
> >Delphi4 alatt hogyan tudnam megoldani, hogy ha egyszerre tobb
> >billentyut nyomok le, akkor ne csak az utoljara lenyomott
> billentyut >erzekelje a progim?
>
> Az OnKeyDown()-ban minden egyes billentyu lenyomasakor egy kulon
> esemenyt kell kapnod. (Gondolom az OnKeyPress()-t hasznalod.)

Játékokhoz a legjobb a megfelelő API tábla kiolvasása, amivel minden
billentyűzet jelenlegi "pillanatképét" megkaphatod. Erről a Deplhi4-es
Win32 API Reference-ben részletes leírást kaphatsz.
Ekkor nem neked kell könyvelned a billentyűket. Az eseményvezéreltség
ilyenkor egyébként sem kifizetődő, mert leterheltség esetén
elveszhetnek. Az OnKeyDown hibája, hogy csak a _te ablakodra
vonatkozó_ eseményeket kapod meg, ezért terhelt helyzetben megtehető,
hogy a programnak lenyomod a "k" betűt, majd egy másik ablaknak küldve
engeded el. Így a programod teljesen összezavarodik.

A WinAPI nagy hibája pedig az, hogy nem csak a te ablakodnak jövő
billentyűket kapod el, mert (1) figyelned kell, hogy az applikációd
aktív-e (2) leleshetőek a jelszavak. Én készítettem is ilyen
láthatatlan programot, nagyon jól műxik.

Ha ennél fejlettebb billentyűzet-kezelés kell, használj DirectX-et (de
ez nem túl stabil -> ne vezéreljen bankot, de játékokhoz jó)

Az OnKeyPress másik hibája (???, legalábbis ebből a szempontból), hogy
csak a szövegkaraktereket érzékeli, a vezérlőknél nem jó. (Viszont a
SHIFT-et kezeli helyettünk...) Az OnKeyDown azt hiszem, minden
billentyűre működik, kivéve, amit a Windows elszív (pl. ALT+F4). A
WinAPI-s dolog itt is működik.

Sanya

>>Keszitettem egy horgot a SetWindowsHookEx fuggveny segitsegevel. Az
>>alakalmazasban van (nem DLL-ben) a callback fuggveny, amit bizonyos
>>uzenetek hatasara meghiv a Windows. [...]
>
>Kicsit utana neztem a dolgoknak es az irodalom azt ajanlja, hogy a
>callback fuggveny az DLL - ben legyen megvalositva, valamint hogy a
>leheto legrovidebb legyen a futasa. [...]
Nem tudom hol olvastad ezt, de szerintem felreertettel valamit. Az,
hogy DLL-ben van -e a hook vagy sem szerintem nem befolyasolja a
futasi sebesseget (merhetoen).
Ellenben egy masik szempontbol fontos, hogy hol helyezkedik el az
adott rutin. Nevezetesen arrol van szo, hogy un. globalis hookot (ami
barmelyik ablak uzenetsorat monitorozni tudja) csakis DLL-bol lehet
installalni, mert csak ez eseten tudja a rendszert azt a mindekori
aktualis processz cimteruletere (address space) bemappelni. Ha a hook
rutin egy .EXE-ben van, akkor az csakis lookalis hook lehet, magyarul:
csakis az adatt alkalmazas altal letrehozott ablakokat tudja
monitorozni.

Az eredetileg emlitett problemat tehat szerintem nem ez okozza, hanem
az, hogy a callback fuggvenyt a rendszer egy - bizonyos szempontbol -
definialatlan kontextusbol hivja meg. Ez alatt az ertem, hogy a
fuggveny hivasanak pillanataban pl. a DS regiszter nem feltetlenul az
adatszegmensre mutat, tehat nem ervenyesulnek azok a feltetlek
amelyekre a Delphi altal generalt kod epit. Ez a dolog onmagaban meg
korrigalhato lenne (bar eleg korulmenyesen, a szegmensregiszterek
megfelelo ertekekkel torteno feltoltesevel assembler betetbol), de az
aszinkronites problemaja miatt mas megoldast erdemes keresni.
(Nevezetesen itt az a baj, hogy az adott callback rutin _barmikor_
meghivasra kerulhet, ami miatt szinkronizalni kellene az altala, es a
program tobbi resze altal eszkozol eroforras-hozzafereseket.) A
megoldast a filemapping szolgaltatja, aminek segitsegevel akar
processzek kozotti kommunikaciora is alkalmas memoriaterulet
alakithato ki. (Globalis hookok eseten egyebkent is mindenkeppen ezt
kell hasznalni, mert a globalis, DLL-ben elhelyezkedo hookok ugyanis
hiaba irnak sajat adatteruletukre, mert az adott logikai cimhez
tartozo fizikai cim a kulonbozo processzek cimteruletei kozti valtas
soran kulonbozo fizikai cimekre kepezodnek le, igy nem alkalmasak pl.
globalis gyujtoterulet kialakitasara.)
A filemapping kialakitasa es hasznalata vegett nezd meg a win32.hlp
CreateFileMapping() cimszavat ill. a kapcsolod topicokat!

Gabor

Hi,

 Irtam ma egy programot ami azt a celt szolgalja, hogy titkosit egy
 file-t. Nem tul bonyolult a lenyege, hogy menden egyes byte-bol
 csinal 2-t. Tehat a kodolt file merete 3-szor akkora mint az
 eredetie. Ezt megcsinalta nehezen tomoritheto fileoknal (pl: JPG,MP3
 stb) es betomoritettem mind a kettot. Az eredmeny kicsit
 megdobbentett mert a kodolt file becsomagolva alig nagyobb az
 eredetinel.
 Az lenne a kerdesem hogy:
 -meg lehetne oldani, hogy a kodolt filet kissebbre csomagolja be mind
 az eredetit, ugy hogy helytakarekosabba teszem a progit???

 -Esetleg ugy, hogy kif. erre a celra irt tomorito progival tomoritem?
 (A benne szereplo byte-ok erteke mindig #40 es #79 kozott van.

Bocs ha nagy baromsagot kerdezek, de engem erdekel ez a dolog.

Udv.