Sziasztok!

Lenne egy kerdesem !

Hogyan lehet megoldani  C-ben azt, hogy a 
registry-ben egy binaris erteket toroljek.

Teljes eleresi utat be kellene epiteni

HKEY_CURRENT_USER/valami/valami/valamilyen binaris ertek 
-et szeretnek torolni.

Valszokat elore is koszi !

Minden jot,
               Ricsi
               mailto:
               Ifjusagi Unio: http://w3.swi.hu/xifu

Haliho!

Miert kellene erre karakterfelismero sw-t irni???
Van ket ugyes Win API fv: ChildWindowFromPoint, WindowFromPoint. A megadott
screen koordinatan levo ablak handlejet adja vissza. A cursor screen
koordinataja pedig a GetCursorPos fv-el kerdezheto le. A visszaadott ablak
handleje alapjan eldontheto, hogy milyen tipusu ablak, es ha szoveges, akkor
GetWndowText el mar meg is kapod a teljes szoveget az ablakban.
Lekerdezheted az ablak koordinatait, aztan a text jellemzok alapjan
kiszamolod epp melyik betu folott volt az a screen koordinata.
Szerintem megoldhato aranylag egyszeruen. Bar meg ilyet nem csinaltam, de
lehet, hogy megirom, ha lesz egy kis idom ra a cegnel...

Udv
STeve

>> > - nincs többszörös öröklődés
>
>A) > Van. (Lasd interfeszek!)
>ooops! ezt nem tudtam. Írnál erről bővebben, különösen arra kitérve, hogy
>ez egyszerűen alkalmazható-e egy user által készített kutya közönséges
>osztályra, vagy sem?
Siman alkalmazhato barmely sajat osztaly eseten is. (A COM osztalyok
eleresehez _szukseges_ az interfeszek hasznalata, de ettol fuggetlenul sajat
osztalyok eseten is _lehetseges_ alkalmazasuk.)
Ha jobban erdekel a dolog akkor olvasd el a helpet, de most mar alaposabban!

>> > - nincsenek templatek! (Gyengék a típusellenőrzési lehetőségek) Ez
>óriási...
>
>B) > Hmmm... Ez eleg erdekes... Szoval szerinted a C tipizaltabb nyelv,
>>mint a Pascal? Na, azt hiszem erre befizetek... ;)))
>Bocs, én C++-ról beszélek. De elismerem, nem fogalmaztam pontosan,
>félreérthető az idézett modat. Azt akartam mondani, hogy anélkül, hogy
>nekiállna újraírni mondjuk a TList osztályt a-z-ig, hogy működjön egy saját
>maga által definiált class-ra (pardon, object-re), akkor csak "void*",
"TObject*" használatával >tudja ezt megtenni! Tehát nincs gyors, egyszerű
módszer típusos objektumokkal >végezhető natív, magasabb szintű műveletekre.
Oszinten szolva nem nagyon ertek a C++-hoz, igy sajnos nem vagyok abban a
helyzetben, hogy megiteljem a dolgot amit a tipusossagrol allitottal.
Ellenben van egy olyan gyanum, hogy te sem vagy tul jaratos a Delphi-ben,
mert veled ellentetben az en velemenyem szerint egyaltalan nem problema egy
barmilyen osztalyt kezelo objektum letrehozasa a TList-bol szarmaztatva. A
TList direkt altalanos celura van tervezve es igy teljesen szabadon
alakitgathato - nem kell ujrairni az egeszet. Igaz, hogy tipizalatlan
pointerekkel dolgozik es igy objektumok/osztalyok aktiv kezelesehez
typecasthoz kell folyamodni, ami ugyan alapvetoen "csunya dolog", de ha csak
a TList-leszarmazott osztalyok belul alkalmazod, akkor szerintem teljesen
elfogadhato megoldas. Lasd "objektumok zartsaga" elv!
Teny, hogy maskent mukodnek a template-ek es a most felvazolt megoldas, de
ettol en nem tekintenem az elozott jobbnak mint az utobbit. Foleg, hogy te
most eppen egy olyan peldat hoztal fel, ahol a specializacio a lenyeg, amire
pont hogy tok alkalmatlanok a template-ek, mert azok azonos mukodesu
osztalyok letrehozasara hasznalhatok. Ha meg nem vegzel muveletet a gyujtott
objektumokkal (nincs specializacio), akkor mi a fenenek ne lehetne magat a
TList-et felhasznalni a maga tipizalatlan pointereivel az
objektum-referenciak tarolasara???

>C) > Sajnos halvany lila gozom sincs, hogy mirol beszelsz itt, de
>kivancsian varnek nehany konkret feladatot erre a halmazos meg az
>interfeszes dologra is, amit konnyebb/egyszerubb/gyorsabb megoldani
>Delphi-ben, mint BCB-ben. Tehat (nyilván úgy akartad írni, hogy amit
>egyszerűbb megoldani BCB-ben:)
Igen.

>- Halmazos
>[...]
Nagyon klassz volt ez a kodreszlet, csak szemely szerint jobban orultem
volna, ha inkabb egy adott feladatot irsz le, amit te BCB-ben 5 sorban
megoldasz, de Delphi-ben - szerinted - 50KB forras beirasa kell hozza... Ez
ugyanis egy konkret implementacio volt, amit ugye tenyleg eleg lenne
Delphi-be konvertalni (level elteroek a nyelvek lehetosegei), de abban mar
nem vagyok biztos, hogy ha egy konkret altalanos (!) problemat vetnel fel,
akkor ne lehetne arra effektiv megoldast talani Delphi-ben is.

>- mélyebb szintre leásás: mi a véleményed mondjuk a WinAPI használatáról,
>amikor pl 0-val lezárt stringekre van szükség, DirectDraw, nyomtatas stb ?
Azert szep volt toled, hogy pont a 0-val lezart stringeket hoztad fel,
amikor mindenki tudja, hogy ez a C egyik legnagyobb hatulutoje (mert piszok
lassuak). De azert megmutatom neked, hogy mennyi Delphi-ben C-stringge
konvertalni egy Pascal stringet: "PChar(S)". Ennyi. A valtozot/kifejezest
nem szamitva 8 karakter. Ez aztan bonyolult muvelet!
A DirectDraw-val meg a nyomtatassal pedig nem tudom mit akarsz. A Delphi-nek
egyikkel sincs problemaja es furcsa lenne ha a BCB barmelyik teren is tobbet
nyujtana, mint a Delphi, amikor o is Delphi VCL-jet hasznalja.

>- külső dologhoz kell interfészt készíteni: külső DLL-ekhez való csatlakozás
>tipikusan C-s adatstruktúrák átadásával, átvételével ? Hardverközeli dolgok,
>kommunikáció, hálózatos feladatok?
>
>Szerintem ez _sokszor_ egyszerűbb C, C++ rendszerrel.
Szerintem pedig max. annyival egyszerubb, hogy az SDK-kat altalaban C-ben
irjak meg (de azert a jobb cegek, mint pl. Novell Delphis interfeszeket is
keszitenek) es igy te azokat kozvetlenul hasznalhatod. Ennek ellenere
azonban a Delphi sem tamatsz semmilyen korlatot a kulso, akar C-ben irt
rutinok felhasznalasaval szemben. Nyilvan barmilyen C-struktura modellezheto
benne, az "cdecl" direktiva hasznalataval C-rutinok kozvetlen hivasara is
kepes (ez is van vagy 5 karakter, szinten piszkosul "bonyolult" es
"nehezkes"). (Mellesleg megjegyzem, hogy a WinAPI pont hogy Pascal-jellegu
hivasi konveciot alkalmazas, igy pont hogy a C az amit jobban kell igazitani
hozza es nem a Pascal-t!) Hardverkozeli dolgot alatt nem tudom mit ertesz,
de szerintem ezek a feladatok ugyanannyira bonyolultak vagy egyszeruek
Delphi-ben, mint BCB-ben. A kommunikacioval es halozatos feladatokkal
szinten nincs semmi baja a Delphi-nek. (Megint szivesen vennek
konkretumokat, mert ezek piszkosul tag teruletek.)

 ... es en meg mindig nem mondtam azt, hogy a Delphi jobb, mint a BCB, csak
azt, hogy egy fikarcnyival sem rosszabb (vannak nyilvanvalo hatranyai az
utobbival szemben, de elonyei is szep szammal akadnak). Max. _mas_...

PS: Ha nem tudsz konkretumokat felmutatni vagy csak tovabb akarod szapulni a
Delphi-t, akkor szerintem most fejezzuk be a vitat, mert erre biztosan nem
tart igenyt a CODER! En magam ezt a levelet is csakis azert kuldom el a
listara is, hogy ne hagyjam tevhitben az esetleges erdeklodoket, mert
szerintem megvan a joguk a korrekt tajekoztatasra. Nem szeretnem ha azert
fosztanak meg magukat egy jo fejlesztoeszkoztol, mert valaki azt mondta,
hogy az egy nagy nulla (kicsit sarkitva a dolgokat). Mindenesetre igerem,
hogy ez az utolso publikus levelem ebben a temaban - maganban vitazhatunk
tovabb...

Gabor

Hi Coders!

    WIN95/Delphi 3 Professional.
    Install Shield-del feltettem egy programot egy "szuz" PC-re. Az
    eredmeny: indulaskor Run time error 217 at xxx. (Ctrl-C ???)

    Volt mar valakinek ilyen problemaja?
    Nekem csak ugy sikerult elharitani, hogy a Delphit is feltettem.

Üdv
Balazs

Sziasztok!

Lenne egy gondom:

VB6.0-ban keszitettem telepito programot egy meglehetosen egyszeru 
alkalmazashoz.
Adatbaziskezelest hasznal, igy a telepitobe belevettem minden drivert, 
amihez csak hozzanyulhat. (Jet, ODBC)
Az en gepemen azt mondja, hogy minden OK, probakeppen meg telepitettem 
magamnal, es minden rendben mukodik. Feltelepit es hasznalhato. (Igaz, hogy 
egy kb. 10 M-es telepitot keszit).
Nomarmost: elvittem egy masik gepre es telepiteni szerettem volna. Egy 
belso hibaval elszall rogton a telepites elejen, szo sem lehet 
telepitesrol.
A hiba cimere most nem emlekszem, segito szandekuaknak utananezek, ha 
szukseges. Mindenesetre valami illegalis muveletet jelez.
Mi a franc van ezzel a VB6-al??
VB5-el mar egy halom szoftot telepitettem, minden gond nelkul.
Az en gepem W98-as, a celgep W95-os. Itt lehet valami gond?
Nem a celgep hibaja. Probaltam WinNT alatt futo gepre is telepiteni, 
eredmeny ugyanaz.
Ha ez mond valamit: Windows Commanderrel ellenoriztem a csomagolt fajl 
epseget. Nalam azt mondja, hogy minden OK, a masik ket gepen azt mondja, 
hogy a .cab fajlban hiba van.
Ja, igen: az SP3 a VB6-hoz telepitve van!

*****************************
Ha valaki egy mukodo megoldast tud mondani, hajlando vagyok egy (nem 
virtualis) sor arat atutalni a szamlajara! (Hottkomoly)
Gyerekek: ideges vagyok....
*****************************

Barmely tovabbi parameterrel rendelkezesre allok
Biro Zsolt
mailto:

> Kedves Koderek !
>
> Lenne egy kerdesem (mino meglepo):
>
> Egy EXCEL munkafuzetbe irnek egy makrot, ami automatikusan elindul, amikor
> megnyitom ezt a munkafuzetet. Hogyan lehet ezt megcsinálni? Talaltam
> utalasokat 4.0-s verzioban nyitaskor_fut, illetve kesobb auto_activate
> nevu makrokra, de nem megy nekem.

A legegyszerubb a kovetkezo:

A munkafuzet ThisWorkbook nevu moduljaba kell az alabbi eljarast beleirni
(termeszetesen kitoltve az altalad kivant koddal.

Private Sub Workbook_Open()
End Sub

Szapi

> Nagy-nagy problemamhoz szeretnek segitseget kerni.
> Szoba kellene allnom delphi-bol az autocad-del. Az autocad help peldai
> mind visual basic-re vonatkoznak, es ezert nem is ertem a kovetkezo
> helyzetet (egy ko:rt szeretnek rajzoltatni):
>
> var w, myc: Variant;
> begin
>   w:= GetActiveOleObject('AutoCAD.Application');
>   w.ActiveDocument.New('Proba!');
>
>   myc:= VarArrayCreate([0,2], varDouble);
>   myc[0]:=2;
>   myc[1]:=4;
>   myc[2]:=0;
>
>   w.ActiveDocument.ModelSpace.AddCircle(myc,10);
> end;
>
> Bar a help azt mondja, hogy a koordinatakat (myc) egy 3, double elemu tomb
> tarolja, erre megis azt valaszolja az autocad, hogy type micsmacska. :)

Nem egeszen pontos, ugyanis a koordinatakat egy Variant tipusu valtozo
tarolja, amiben viszont valoban egy 3 elemu double tomb van. Nem tudom, hogy
a Delphi hogyan hasznalja a Variant tipusokat, de biztosan van benne olyan
gyari eljaras, ami egy tombbol Variantot general.


Szapi

Tisztelt Kollegak !

Clipper 5.2e, Blinker 4.1

Van a programban egy assembly program, amely magara iranyitja az INT17H-t,
azaz a nyomtato megszakitast.
Itt a problema szempontjabol erdektelen konverzio utan kuldi ki a
karaktereket a nyomtatora.
Az atiranyitas szabalyosan INT21H/func35H-val tortenik. A Blinker doksi
szerint a hasznalt megszakitasok a vedett modban transzparensek. Ennek
ellenere a rutin nem mukodik vedett modban, az atiranyitas nem tortenik meg,
a rutin nem kapja meg a vezerlest.
Egy masik assembly rutinban az INT10H display megszakitast hasznalom, az jol
mukodik. A Blinker doksi szerint ez is transzparens, tehat azonos csoport a
fentiekkel.
A progi sima DOS alatt megy, nem halozatos, a problema nem CPU ill.
hardverfuggo.

Erdeklodessel varom az otleteket.

Zahoran Gyorgy

Sziasztok,

Kerdesem lenne C++ Builder, NT4.0/W98 kapcsolatban:
A C++ Builderben megirt program teljesen jol fut, de neha -
teljesen veletlenszeruen - elszall. De a - szamomra 
legalabbis - legfurcsabb az, hogy mindenfele hibauzenet,
vagy nyomonkovetheto esemeny nelkul. ("Access violation..." 
es egyeb uzenetekkel mar talakoztam de hibauzenet 
nelkulivel nem.) Csak a leforditott program szall el, 
amikor meg a C++ Builderben dolgozom, akkor soha. Van, 
amikor fel orai hasznalat utan sem szall el, de olyan is 
van, hogy ket perc utan. A jelenseg mar tobb programnal is
elofordult.

Talakozott-e mar valaki ilyennel?

Sziasztok, ZooLee voltam

Hi,

én eléggé elítélhető módon csak szeretnék egy részletet kiragadni a
leveledből:

--- cite ---
- mélyebb szintre leásás: mi a véleményed mondjuk a WinAPI használatáról,
amikor pl 0-val lezárt stringekre van szükség, DirectDraw, nyomtatas stb ?
- külso dologhoz kell interfészt készíteni: külso DLL-ekhez való csatlakozás
tipikusan C-s adatstruktúrák átadásával, átvételével ? Hardverközeli dolgok,
kommunikáció, hálózatos feladatok?
--- end of cite ----

A jó hír az (legalábbis a Delphi programozóknak), hogy a Delphi
csuklóból kezeli a null-terminated stringeket, sőt, a WideString,
PWideString és mindenféle unicode stringeket és ezeket szépen tudja is
konvertálni. Ugyanúgy karakteres tömböt is használhatok akár
PChar(tomb)-stílusban. Nos, ez persze alapelvárás.

A továbbiakban pedig úgy néz ki, sikerült kitapintanod a Delphi
leggyengébb pontját: a C header-fordítások *számának* elégtelenségét.
A helyzet az, hogy a WinAPI alapjában véve C-orientált és hiába jön ki
nekem valamelyik MSDN CD-n mondjuk a setupapi.h, ha azt a szolid
130kb-os headert nekem kellene átfordítgatnom ObjectPascal-ra.
Ehelyett, ha a srácok a Borland-nál nem tették meg, lehet rohangálni a
neten, hogy keressem a Delphi-s fordítását az adott header-nek, ha
ugyan van olyan. Ez valóban kényelmetlen a Delphiben és el tudnám
fogadni, ha a Borland terméktámogatásaként mondjuk legalább évente egy
CD féláron megrendelhető lenne a fordított headerekkel.

> - külso dologhoz kell interfészt készíteni: külso DLL-ekhez való
> csatlakozás
Ez azt hiszem, nem azért van, mert a C jobb. Egyszerűen C nyelven
jönnek ki a headerek.

Abban viszont nem tudok neked igazat adni, hogy a "tipikus C-s
adatstruktúrák átadása, átvétele" vagy éppen a külső DLL external-ok
importja bonyolult lenne Delphiben. A winAPI nem tartalmaz (legalábbis
én még nem találkoztam vele) határozottan C-specifikus paramétereket
(pl. halmazokat). A Delphi segítségével egyszerűen elkészíthetők ezek
a típusok és többnyire egyszerűbb őket használni, mint C-ből.

Az emlegetett hálózati programozás témáját kiragadva, attól még, hogy
Delphi-ben nem winsock.h a fejlécfile neve, hanem winsock.pas, még nem
lesz bonyolultabb programozni.

Summázatként még annyit, hogy habár mind a C-t, mind a Pascal-t
általános célú programozási nyelvként emlegetik, én mégis inkább
kidomborítanám a C rendszerközeli mivoltát. A Delphi már határozottan
túllépett a standard Pascal keretein, lényegesen bővültek lehetőségei,
de továbbra sem az a titkolt-nem titkolt célja, hogy alázza a C-t.
IMHO a két nyelv nagyon távol áll egymástól módszerei tekintetében is,
habár valóban nem olyan markáns a különbség, mint mondjuk a Perl és a
C esetében.

A Delphi takaros, jól kidolgozott, szép nyelv. A Kylix megjelenésével
valószínűleg a linuxos C-guruknak is érdemes lesz vele megismerkedni.

regards,

Péter