PCPROG.5

05 Jan 1995 - 02 Oct 1995

Messages - fox

fox.210 max.headroom,
Bre, ovaj Report Writer na Fox-u 2.0 mi deluje sve kilavije, kako ja dobijam potrebu da pišem aplikacije za matrične štampače :) Zna li neko (NDragane?) neku dobru zamenu za njega, ili bar gde se može naći neki prerađeni & usavršeni GENPD, bar one PDSETUP-e da uradim kako treba? Onaj čisto softverski deo je dobro urađen, ali mi, bre, ona spona softver-hardver nešto ne deluje. Dioptrija? Evo šta me još muči - nigde da vidim gde se uzimaju u obzir oni silni _P**** parametri... Da li oni važe i za REPORT FORM, i da li imaju prednost nad njima (tj. onima definisanim u REPORT FORM-u)? Npr. _PLENGTH, ima li nekog smisla da učukam: _PLENGTH = 100 REPORT FORM xxx TO PRINTER (ovde je definisana duž. strane 66) Šta će od ova dva da upali - 100 ili 66? Drugo, kako da nateram REPORT da poštuje moje ranije definisane _P**** sistemske varijable?
fox.211 ndragan, -> #199, willow
/ Kod mene, nema teorije da #if #define #endif prodje. Obrati pažnju na verziju: Visual Fox Pro 3.0 (beta) Na 2.6 neće, nije nikad ni htelo. / a sam kod je gurnut u memo polje . A propao guranja koda u memo polja (to rade foksovi generatori, a često radi i moj), nevolja je što se ne kompajlira dok se ne ispiše u generisani program. Otvorite memo polje koje sadrži kod i probajte štogod da ga kompajlirate. Cvrc. Bilo bi zgodno kad bi neko bio ljubazan da napiše OKL rutinu koja bi to sredila, a?
fox.212 ndragan, -> #200, goxx
/ Razumljivo da neće. #if #else #endif nisu komande već kompajlerske / direktive To je i bilo jasno - grešku i javlja prilikom kompajliranja. Ajd da završimo: kombinacija #if ovo #define ono onako #endif nije podržana zaključno sa verzijom 2.6, ali radi u VFP 3.0. Ok? / i u run-time sa svojim direktivama, ali clipper ima ubedljivo najbolji / predprocesor što fox neće nikad imati (sem ako ga ne ukrade :). Kliper nije interpreter, tj. on je od a do žnj kompajlirani jezik (vidi se po tome što mora da se linkuje - foks _može_ da se linkuje, ako baš hoćete, al' ne vidim čemu bi to služilo). Radi se o popriličnoj koncepcijskoj razlici, tako da mi baš ni ne treba mnogo više # direktiva u foksu nego što ih već ima; kad bih radio kliper, verovatno ne bih mogao da živim bez žestokog pretprocesora. Uostalom, zar nije kliper, po definiciji, pretprocesor koji iksbejzolike (xBase-like) naredbe pretvara u pozive funkcija iz svoje bibliotetke? / Možeš svuda da pišeš _LASTROW umesto srow() što i nije nešto jer je / izraz koji zamenjuješ prost za pisanje. Da, ali #define Read_it Read Save Timeout 200 Modal valid Pera() when Mika() ...pa kad ti treba da zameniš neku od ovih opcija na deset mesta u programu, samo zameniš u definiciji i prekompajliraš. Radio sam čak i #define gurni =fputs(fhandle, pa je program izgledao smešno: gurni string1) gurni "drugi string"), gurni "još koji string") al' je radio ko zmaj i nisam imao nikakvih problema.
fox.213 ndragan, -> #205, max.headroom
/ Drugo, ima dosta neobično MaskEdit polje, a to mu je onaj PICTURE / atribut GET Nisi video SuperNovu, tek je tamo zabunjeno. To smo čudo na jedvite jade dobili na probu, a onda brže bolje posklanjali sa diskova.
fox.214 ndragan, -> #203, max.headroom
/ Statistike radi, svaki projekat veći od 20-ak stavki zaglavi bar / jednom pri Kod mene normalan projekat ima brat bratu stotinak slogova (.app izađe na 800K) a glavi uglavnom kad ga selim s mašine na mašinu ili iz bilo kojih razloga nešto neregularno izađem iz njega itd - dakle, skenja se kao baza ili tako nešto. Retko imam problema sa tim, al' kad počnu, najbolje je ne prati ga, nego praviti nov.
fox.215 ndragan, -> #204, max.headroom
/ brine samo jedna stvar - OO programiranje nije objašnjeno onako kako / bi trebalo... još uvek samo malobrojni znaju da se bez greške snađu u / ovom čudu, a Našao sam na CDu sa junske MSDN konferencije dobar članak o OOP za foksovce - tip je na kraju rekao 'nemojte da padate na retoriku, to je sve u suštini prosto'. Kako ga je on objasnio, i jeste. Gledaću da ga ponovo nađem i okačim (CD mi je ostao u Mađarskoj, dakle za jedno tri nedelje mogu da donesem to čudo ovamo). Jedino je bitno da znaš kojim redosledom okidaju događaji (i metodi koji treba da reaguju na njih) kad se form otvara i zatvara, i kad žiža prelazi sa objekta na objekat (tj kad pređe na sledeće polje), i da voziš računa šta si kako definisao. Ako imaš jasan plan svoje hijerarhije klasa, možeš zaista dosta da uštediš na vremenu i dužini sorsa. / ko zna čega sve ne, sve gledam hoće li se ko zajebati pa napraviti / nešto što će kao krajnji rezultat dati vizuelno BRZU aplikaciju. Pa to / k'o da izmišlja Znao sam šta nas čeka, čim je Bidža kupio lisicu. Samo sam čekao da vidim i nisam se razočarao. Upravo ono što su obećali da neće ("rad pod prozorima značajno usporiti foks"), desilo se. _Sve_ crta pendžere brže od foksa. Uostalom, nije za džabe Borland napisao sopstvene rutine za kojekakve rutinske poslove oko prozora dugmića i ostalom. Ili, zašto isti pendžerski programi brže rade na istoj mašini pod o es pola - zato što je emulaciju istih rutina aj bi em uradio pišući ih ponovo, ali načisto. Sve su to brljotke malog mekanog.
fox.216 ndragan, -> #207, max.headroom
/ kraj definisane strane (dakle, 66. red). Zašto jednostavno ne zakuca / tu Ako imaš bilo kakav objekat u PageFooter traci, automatski dobijaš chr(12) posle trake, a štampa se za svaku stranu na kojoj ima bar nečeg. Obriši celu traku pa probaj ponovo. Meni je to pravilo probleme kad generišem riport - ubacio sam brojač strana u traku za dno strane, i još ubacio slog (ili beše opcija u vodećem slogu, ne sećam se sad) za PageEjectAfter. Rezultat - izbacuje prazan list posle izveštaja. Jedan FF u dnu poslednje strane (kao i bilo koje druge strane) i još jedan iza svega (eject after).
fox.217 ndragan, -> #208, mamba
/ menija.Da li to moze da se nekako izbegne. Generiši sa logom, a .exe startuj sa -t (no logo), eventualno to zavari u .bat fajl odakle pozivaš .exe fajl.
fox.218 ndragan, -> #209, atech
/ Uzgred, da li postoji vise razlicitih kompajlera za fox ili se Ima jedan, al' pravi tri vrste .exe fajla: compact exe, što je u stvari foxr.com+trtmrt.app (manje više), zahteva da negde nađe Fox*.esl fajlove. Zavisno od raspoložive memorije, startovaće šesnaestbitnu verziju sa overlejima (fox*.esl, .eso) ili trijezdvobitnu (foxr26x.esl ili tako nešto, ima jedno x više u nazivu) koja u komadu ide u gornju memoriju. Ne linkuje se, bar se ne primećuje. standalone exe - 16 bitna verzija sa overlejima, sve gorenavedeno, linkovano Wlink8 linkerom, do proliva dugo traje, ždere disk i memoriju, i na kraju je dugačko kao oni .es?+.app zajedno (wlink8 vrlo malo izostavi, nikad se ne zna šta može da zatreba, naročito ako ima bar jedna makro zamena negde u aplikaciji) standalone extended exe - jednokomadni exe, 32 bita, sadrži Phar Lap Extender, tj sam upravlja memorijom. Linkuje se kao Simple Executable (zato kažem jednokomadni), pet do deset puta brže nego prethodni, a sadrži isto što i on, ali bez overleja - podrazumeva se da ima dovoljno memorije da se učita ceo, i da još nešto ostane za bafere, stringove, prozore itd. To praktično znači mega ipo za službeni deo, bar pola mega za aplikaciju, i do pola mega za podatke - dva mega (produžene ili proširene) će mu biti dosta. Kompajler je ugrađen u Foks, i ne postoji kao poseban program. p.s. ovo bi moglo... ko će da sastavi FoxPro.faq?
fox.219 mamba, -> #217, ndragan
> Generisi sa logom, a .exe startuj sa -t (no logo), eventualno to > zavari u .bat fajl odakle pozivas .exe fajl. I na ovaj nacin ostaje background boja nakon izlaska iz aplikacije.
fox.220 max.headroom,
Objektni programeri, help. Nisam u stanju da ukapiram značenje pojma klase (Class). Ako sam dobro shvatio, to je programski kod koji određuje skup metoda koje se mogu izvršiti nad objektom. Klasa može naslediti određene osobine od neke druge klase, koja se naziva predak (Ancestor). Pročitao sam i sledeće: "The term Class is interchangeable with the term Object Type" - to znači da se klasom može smatrati i opšti tip nekog objekta (?) Ali, da krenem redom (vi me ispravite ako negde grešim): Objekat - nešto što se vidi (ako nije hidden tipa) na ekranu (button, polje za unos teksta...); njegovu pojavu određuje skup osobina (Properties). Takođe, akcije nad objektom aktiviraju određene događaje (Events). Tip objekta definiše klasa - dakle, klasom definišemo različite objekte, istog tipa (ovo mi nije najjasnije - kakvi tipovi objekata, globalno, mogu postojati?). Klase mogu nasleđivati osobine jedna od druge, po principu više i niže instance (nisam shvatio - kakve, tačno, osobine? Da li je i prozor objekat? Ako jeste, da li se kroz njega npr. definiše font koji će se uopšte prikazivati u njemu? Ako da, da li je to primer nasleđivanja osobina?). Dalje, metoda (Method) - za nju piše da je to "Procedure or a Function associated with particular object". Dakle, objekat je multifunkcionalan entitet - ali neznam gde se definišu metodi jednog objekta (da li su i oni nasledni? Da li se nalaze u definiciji klase, tj. tipa jednog objekta?) Da li se Method može tretirati kao Property? U svakom slučaju, znam kako se objekti upotrebljavaju (bar to): ImeObjekta.Metod := ImeDrugogObjekta; ili := promenljiva; ili := konstanta; Takođe, moguća je i sledeća kombinacija: ImeObjekta1.Metod1(ImeObjekta2.Metod2); Baš sam ljubopitljiv, zar ne? ;) Samo, ovo je osnova koju nisam našao niti u jednom help-u, a bazično je za makar i najjednostavnije OOP. Kad bih to shvatio teorijski, praktični deo bi mi daleko lakše pao :)
fox.221 nlazic, -> #220, max.headroom
*> Objekat - nešto što se vidi (ako nije hidden tipa) na ekranu (button, *> polje za unos teksta...); njegovu pojavu određuje skup osobina *> (Properties). Takođe, akcije nad objektom aktiviraju određene događaje *> (Events). Ne, ni blizu. U "klasičnom", strukturnom programiranju program pišeš tako što definišeš neke podatke (tipa integer, real, string...) i onda pišeš procedure koje njima barataju. Ono što je bitno je da su podaci i procedure/funkcije koje njima operišu razdvojeni. Fora kod objektnog programiranja je da se podaci i procedure koje ih obrađuju spoje u jednu celinu - objekat. Podaci koji su unutar jednog objekta zovu se POLJA (fields), a procedure i funkcije METODI (methods). Šta su onda klase? Jednostavno rečeno (!?), objekat je instanca klase (ili klasa je tip objekta). Npr. kad napišeš VAR I,J:INTEGER; ti si definisao promenljive I i J kao celobrojne. Analogno, može se napisati: VAR OBJEKAT1, OBJEKAT2 : NEKA_KLASA; Dakle, ono što je INTEGER za neku celobrojnu promenljivu, to je klasa za neki objekat (objekat je promenljiva tipa klase). U prethodnom primeru trebalo je negde iznad napisati nešto poput: TYPE NEKA_KLASA = CLASS (RODITELJSKA_KLASA) { SPISAK POLJA } Jedan, Dva : integer; S1, S2 : string; ... { DEKLARACIJE METODA } procedure PR1; function Funkc1:Boolean; ... END; Konkretan kod metoda se definiše kasnije u programu, npr.: function Neka_Klasa.Funkc1:Boolean; begin Funkc1:=true; end; Što se tiče properties-a i events-a oni sa klasičnim shvatanjem objekata (ovim gore opisanim) nemaju ništa. To su samo "poslastice" koje je Borland uneo u Delphi (pretpostavljam da je pitanje vezano za njega). Osobine objekta su definisane ISKLJUžIVO sadržajem njegovih polja, a akcije objekta se aktiviraju SAMO ako se pozove neki od njegovih metoda (kaže se "objektu se uputi poruka". Npr. ako napišeš NekaForma.Show; ti si objektu NekaForma (čija je deklaracija VAR NekaForma : TForm; ) uputio poruku Show, tj. pozvao si metod NekaForma.Show.). *> Klase mogu nasleđivati osobine jedna od druge, po principu više i niže *> instance (nisam shvatio - kakve, tačno, osobine? Naslednička klasa nasleđuje od roditeljske sva polja i metode. To su te "osobine" o kojima pričaš. Naslednička klasa ih može menjati, a može ih koristiti "as is", onakve kakve su napisane u roditeljskoj. Objekat, dakle ne mora imati svoju reprezentaciju na ekranu. Dizajneri Delphi-a su skontali da je najefektnije da se komunikacija sa Windows-ima izvede preko objekata, pa su u tom cilju napisali klase za prozore, dugmiće, skrol barove, menije, okvire i sve ostalo što vidiš (i ne vidiš) na ekranu. Deklaracije svih ovih klasa (nažalost ne i kod) možeš videti u *.INT fajlovima koji se isporučuju uz Delphi. Ovo je bilo na brzinu. Ipak ti preporučujem da uzmeš neku knjigu u kojoj je to detaljnije objašnjeno. Ako planiraš da radiš u Delphi-u dobar početak bi bile knjige za Turbo Pascal 6.0 (mada i verzija 5.5 podržava objekte). Pozdrav, :) Nebojša :) P.S. Sad ti ništa nije jaso, jel' da? :)))))))
fox.222 max.headroom, -> #216, ndragan
Apropo poruke "izbacivanje cele strane pri štampi" (izvin'te što nema quote-a, ali mi je krepao miš pa nemogu da kvotiram) - baš iz razloga što PageFooter tera stranu do krJaja, ostavio sam samo Summary bend. Summary bi trebao da se nalazi odmah posle završenog izveštaja, koliko se poznajem u report gen. Fox-a. Ali, he-he, iako nema PageFooter benda on ga protera kako netreba. Bljaks.
fox.223 max.headroom, -> #219, mamba
Ako nećeš Fox-ovu boju posle izlaska iz aplikacije, udari jedno CLS kroz .BAT.
fox.224 abica,
Drugar ima jedan problem: u FoxPro 2.6 4Win je napravio aplikaciju i koristeci FoxPro Distribution Kit napravio je .EXE fajl. Medjutim, kada sa njim pokrene aplikaciju iz Win-a (ne iz Fox-a) program izbaci glavni meni (odakle program i treba da pocne) i istog tenutka se vrati tamo odakle je startovan (npr. ako je startovan iz FileMgr-a program se posle iscrtavanja menija vrati u njega, a od aplikacije ni traga ni glasa) Zna li ko u cemu je problem?
fox.225 ndragan, -> #210, max.headroom
/ potrebu da pišem aplikacije za matrične štampače :) Zna li neko / (NDragane?) Nisam se igrao sa _PdSetup, u načelu su svi štampači Esc/P ili Esc/P2 kompatibilni i mogu se neke osnovne sekvence ugurati direktno u sam riport ili ručno rađenu štampu, a ostale baš i nisu nužne. Od ostalih štampača igraju još PCL i PostScript kompatibilni, ali tu se, mislim, ne vredi zezati sa štampanjem iz dosa - o tom potom kad budemo morali da pređemo pod prozore. Tj, jesam napravio par štampi za na laser, ali na ruke. Jednom sam, od zezanja, stavio _pdsetup=postscript u config.fp, i dobijao sam lepe .ps fajlove, koje nisam imao iz čega da gledam, a ni na čemu da štampam :). Pogledao sam par komada iz GoScripta, pa koliko je to na VGA monitoru moglo da se vidi, ličilo je na štogod. Nisam imao laser pri nozi tog trenutka da vidim na šta liči kad se baci na papir.
fox.226 max.headroom, -> #225, ndragan
> pređemo pod prozore. Tj, jesam napravio par štampi za na laser, ali na > ruke. Moja je nezgoda što sam do sada i pravio štampe isključivo za lasere (uglavnom HP familija, ekstra jedan Epson), naravno - iz DOS-a. Smanjim slovca na najsitnije, pa kad pogura izveštaj stane pola megabajta na stranu :) Zaista nisam imao nikakvih problema sa dužinom strane i sličnim zezalicama, a da ručno pravim neke izveštaje ne da mi se ne dopada, nego nemam iskaza (silna grupisanja i tomu nalik). Šta najzad bi sa onim FoxFire! add-in-om? Ima li ko info. o čemu se radi?
fox.227 max.headroom, -> #224, abica
> Drugar ima jedan problem: u FoxPro 2.6 4Win je napravio > aplikaciju i koristeci FoxPro Distribution Kit napravio Najverovatnije je nije dobro debugovao. Neka pogleda SKIP FOR uslove u glavnom meniju, ako ih ima, kao i definicije PAD-ova, i tome slično. Da li je probao sa prethodnim startovanjem aplikacije iz Fox-a? :)
fox.228 nkbog, -> #220, max.headroom
> Objektni programeri, help. Nisam u stanju da ukapiram značenje pojma klase > (Class). Ako sam dobro shvatio, to je programski kod koji određuje skup > metoda koje se mogu izvršiti nad objektom. Klasa može naslediti određene > osobine od neke druge klase, koja se naziva predak (Ancestor). Pročitao sam > i sledeće: "The term Class is interchangeable with the term Object Type" - > to znači da se klasom može smatrati i opšti tip nekog objekta (?) Klasa je pojam. Objekat je pojava. Klasa je čovek. Objekat je Max.Headroom. Klasa je, upravo, opšti tip nekog objekta. > Objekat - nešto što se vidi (ako nije hidden tipa) na ekranu (button, > polje za unos teksta...); To je tzv. "vizuelni" objekat. Objekat nije dugme, već dugme "OK". Nije polje za unos teksta, već "polje za unos imena i prezimena". Ono prvo su klase, ovo drugo su objekti. > njegovu pojavu <OBJEKTA> određuje skup osobina (Properties). > Takođe, akcije nad objektom aktiviraju određene događaje (Events). Manje, više da. S tim da su i metode aktivirane određenom akcijom (pozivom). > Tip objekta definiše klasa - dakle, klasom definišemo različite objekte, > istog tipa (ovo mi nije najjasnije - kakvi tipovi objekata, globalno, mogu > postojati?). Niz. Ceo broj. Push Button. čivotinja. Sve što postoji pripada nekom tipu, a taj tip je klasa (kategorija) tog "postojanja", odnostno tog objekta. Prozor aplikacije "Moja aplikacija" je objekat klase prozora. On pripada vrsti objekata koja se naziva opštim imenom "Prozor" i predstavlja jednu pojavu tog prozora. > Klase mogu nasleđivati osobine jedna od druge, po principu više > i niže instance (nisam shvatio - kakve, tačno, osobine? Ne baš. "Nasleđivanje na dole" - "pravo" nasleđivanje: Klasa nasleđuje osobine klase iz koji je izvedena. Na primer, čovek je nastao od neke vrste primata, neke osobine on je nasledio od pretka, a neke ima nezavisne. Slično, list boks je prozor, pa on ima osobine prozora (visinu, širinu, položaj, reaguje na miša i sl.), ali ima i nove osobine (sadržaj, broj elemenata, aktivan element). "Nasleđivanje na gore" - polimorfizam: (Nasleđivanje na gore nije dobar termin). Stvar je u sledećem: za čoveka kažemo da je primat (kao i gorile i lemuri). Stoga je Nenad Bogojević instanca klase Primata. Sa druge strane klasa žovek je izvedena iz klase Primata, pa objekat Nenad Bogojević, koji je i žovek, ako ga posmatramo kao Primata ponaša se malo drugačije od "običnog" primata. U stvari Nenad Bogojević se ponaša kao da pripada različitim grupama (ima više "oblika" - polimorf): i Primat je, i žovek je. Svi prozori imaju HWND osobinu u Windowsima koja ih jedinstveno identifikuje. Kada ti dobiješ HWND, možeš da pomisliš da je to ordinarni prozor, a to je u stvari dijalog, ili lista ili dugme. Prozor definisan sa HWND ponaša se i kao prozor i kao ono što jeste. > Da li je i prozor objekat? Prozor je klasa. Prozor na ekranu je objekat (čak i ako je nevidljiv). > Ako jeste, da li se kroz njega npr. definiše font koji će se uopšte > prikazivati u njemu? Ako da, da li je to primer nasleđivanja osobina?). Nije. To je definisanje osobine. Nasleđivanje je pravljenje nove klase koja ima osobine Prozora, ali dodaje i druge osobine (npr. smer ispisa teksta). > Dalje, metoda (Method) - za nju piše da je to "Procedure or a Function > associated with particular object". Dakle, objekat je multifunkcionalan > entitet - Tačno! > ali neznam gde se definišu metodi jednog objekta (da li su i oni > nasledni? Da li se nalaze u definiciji klase, tj. tipa jednog objekta?) Do skoro je su oni bili nepromenljivi (VB do 3.0, Access), ali izgleda da su se promenili. > Da li se Method može tretirati kao Property? Ne. Metod je interfejs prema objektu. To je postupak za programsku interakciju sa objektom. Osobina je osobina. Na primer, plave oči su osobina. Poznavanje jezika i razumevanje i reakcija na komandu "Gledaj pravo!" je metod. NB.
fox.229 nkbog, -> #221, nlazic
*> Objekat - nešto što se vidi (ako nije hidden tipa) na ekranu (button, *> polje za unos teksta...); njegovu pojavu određuje skup osobina *> (Properties). Takođe, akcije nad objektom aktiviraju određene događaje *> (Events). > Ne, ni blizu. Naprotiv, vrlo blizu (bar drugi deo). Svaki objekat ima osobine opisane podacima i određene metode koji predstavljaju interfejs prema spoljašnjosti (programerskoj ili korisničkoj). U Microsoftovim Visual jezicima postoje dve grupe metoda: metode koje služe za programski pristup (Methods) i metode kojima se opisuje ponašanje pri interakciji sa korisnikom (Events). Prve su do skora bile bogom dane, a druge su se mogle menjati. > Osobine objekta su definisane ISKLJUžIVO sadržajem njegovih polja, Properties u Visual Basicu, Fox, Accessu, Delphiu predstavljaju jedan "prijateljskiji" način za predstavljanje javnih "polja" objekta. Jer zaista, šta jesu javna "polja" ako ne "osobine" objekta koje mozemo menjati. Šta se unutar objekta zaista zbiva, za programera nije bitno. On ima unapred zadat programerski interfejs, a da li je Property polje ili niz polja, to programera ne mora (a i ne treba da interesuje). > a akcije > objekta se aktiviraju SAMO ako se pozove neki od njegovih metoda (kaže se > "objektu se uputi poruka". Npr. ako napišeš NekaForma.Show; ti si objektu > NekaForma (čija je deklaracija VAR NekaForma : TForm; ) uputio poruku Show, > tj. pozvao si metod NekaForma.Show.). Događaji su metode koje se pozivaju kad se objektu uputi poruka, pri čemu konkretnu poruku upućuje operativni sistem (npr. WM_SHOW, WM_SETFOCUS). NB.
fox.230 nlazic, -> #229, nkbog
*> U Microsoftovim Visual jezicima *> postoje dve grupe metoda: metode koje služe za programski pristup *> (Methods) i metode kojima se opisuje ponašanje pri interakciji sa *> korisnikom (Events). Prve su do skora bile bogom dane, a druge su se *> mogle menjati. OOP je nastao mnogo pre Windows-a, Microsoft-a i njegovih Visual jezika. Identifikovati pojam objektnog programiranja sa Visual jezicima, pa i sa Win-om uopšte, je u najmanju ruku pogrešno. Evo primera: sam si rekao da su metode u V. jezicima (bile) nepromenljive. To se kosi sa jednim od najosnovinih principa OOP-a: jedna klasa nasleđuje drugu, dodaje joj svoje osobine (polja i metode) i modifikuje postojeće. Ako se ne varam, u VB-u (do v.4.0) čak nije bilo moguće ni napraviti neki sopstveni objekat! Hoću da kažem da svi ti pojmovi (properties, events, etc.) koje uvode MS i Borland nemaju mnogo veze sa "klasičnim" shvatanjem objekata. Oni su uvedeni samo da bi se automatizovale neke rutinske stvari. Još jedan primer je Borlandov OWL: to je biblioteka klasa (za paskal i c) koja služi kao interfejs ka Win okruženju. Njene klase ne poznaju ni properties-e ni event-e, već isključivo polja i metode, ali su pravi primer objektnog dizajna korisničkog interfejsa. *> Properties u Visual Basicu, Fox, Accessu, Delphiu predstavljaju jedan *> "prijateljskiji" način za predstavljanje javnih "polja" objekta. Jer Da, ali to nisu standardne osobine objekata. Ono što objektni kompajleri moraju da podržavaju su polja i metodi. Ostale stvarčice o kojima ti govoriš, svaki kompajler (pa čak i svaka nova verzija istog kompajlera, u slučaju MS-a!) tretira na drugi način. One su samo posledica prirode Windows okruženja kojoj su dotični kompajleri prilagođeni. *> Šta se unutar objekta zaista zbiva, za programera nije bitno. On ima Bitno je ako piše neku novu klasu, a praktično je nemoguće napisati (dobar) program koji koristi samo unapred definisane klase. *> Događaji su metode koje se pozivaju kad se objektu uputi poruka, *> pri čemu konkretnu poruku upućuje operativni sistem (npr. WM_SHOW, *> WM_SETFOCUS). Ne, događaji nisu metode. Reč događaj treba shvatiti u najbukvalnijem smislu: događaj je pritisak na taster miša ili tastature, pokret miša i sl. Kad Windows detektuje neki događaj, on generiše poruku (poruka je samo skup podataka koji opisuju događaj, npr. koji je taster pritisnut, gde je pomeren miš i sl.) koju upućuje ciljnoj aplikaciji i tu se njegov posao završava (ako aplikacija "prihvati" tu poruku). Aplikacijin posao je da analizira poruku i reaguje (ili ne reaguje) na određen način. U slučaju objektnih Win. kompajlera (to su pre svega paskal i c kompajleri, VB ne treba porediti sa njima (on i nije kompajler)) cela aplikacia je samo još jedan objekat, koji onda (po prijemu poruke) aktivira odgovarajući metod. REZIME: :))) Nikako ne treba posmatrati OOP "kroz prozore". OOP zaista jeste najbolji način porgramiaranja Win-a, ali daleko od toga da mu je to jedina svrha. Ako se na tome ostane i deo programa koji komuniciria sa Win-om napiše "objektno", koristeći ponuđene klase, a ostatak na "standardan" način, dobija se neka nesrećna mešavina OOP-a i strukturnog programiranja koja retko kad urodi plodom. Pozdrav, :) Nebojša :)
fox.231 nlazic, -> #228, nkbog
*> Do skoro je su oni bili nepromenljivi (VB do 3.0, Access), ali izgleda *> da su se promenili. U "normalnom" OOP-u metodi nikad nisu nepromenljivi, daleko od toga. To je bio slučaj samo u nekim MS-ovim jezicima (VB) koji nisu imali preterane veze za objektnim programiranjem. Jedna od osobina na kojima se temlji OOP je menjanje (redefinisanje) nasleđenih metoda. Pozdrav, :) Nebojša :)