Forum » Programiranje » MFC, deskband/tray in 500 EUR
MFC, deskband/tray in 500 EUR
d156 ::
Kot omenjeno v eni drugi temi, sem napisal eno kratko specifikacijo za app, ki bi ga rad imel. Enemu izkusenemu windows programerju pomoje ne bi smelo vzeti vec kot dva dni (glede na to, da je dosti kode ze napisane in prilozene)...
Kot motivacijo pa lahko ponudim 500 EUR. Ni ravno veliko, je pa boljse kot nic.. :)
http://www.kulone.com/contrib/utilproje...
http://www.kulone.com/contrib/utilproje...
Kot motivacijo pa lahko ponudim 500 EUR. Ni ravno veliko, je pa boljse kot nic.. :)
http://www.kulone.com/contrib/utilproje...
http://www.kulone.com/contrib/utilproje...
BlueRunner ::
Ali si za DeskBand iskalnik predstavljal nekaj takšnega? Pa IMHO, ideja s tlačenjem MFC-ja v DLL komponento za desktop je sicer izvedljiva, če res veš kaj delaš... ampak hkrati pa prav prosi za težave. Boljša zasnova je, da imaš deskband kot čisti ATL brez MFC, "integriran" brkljalnik pa narediš kot ločen exe. Potem pa lahko izbiraš kater rendering engine si želiš imeti: IE, Gecko, WebKit, idr.
Aha, pa seveda kot vedno velja, da lahko datoteke vključujejo viruse, zlonamerno kodo, trojanske konje ali pa bodo samo v celoti izbrisali vse podatke na disku. Protivirusni programi in okolje za virtualizacijo so nujni. Namestitev se izvede z uporabo regsvr32.exe.
Aha, pa seveda kot vedno velja, da lahko datoteke vključujejo viruse, zlonamerno kodo, trojanske konje ali pa bodo samo v celoti izbrisali vse podatke na disku. Protivirusni programi in okolje za virtualizacijo so nujni. Namestitev se izvede z uporabo regsvr32.exe.
Zgodovina sprememb…
- spremenilo: BlueRunner ()
d156 ::
Ali si za DeskBand iskalnik predstavljal nekaj takšnega? Pa IMHO, ideja s tlačenjem MFC-ja v DLL komponento za desktop je sicer izvedljiva, če res veš kaj delaš... ampak hkrati pa prav prosi za težave. Boljša zasnova je, da imaš deskband kot čisti ATL brez MFC, "integriran" brkljalnik pa narediš kot ločen exe. Potem pa lahko izbiraš kater rendering engine si želiš imeti: IE, Gecko, WebKit, idr.
Aha, pa seveda kot vedno velja, da lahko datoteke vključujejo viruse, zlonamerno kodo, trojanske konje ali pa bodo samo v celoti izbrisali vse podatke na disku. Protivirusni programi in okolje za virtualizacijo so nujni. Namestitev se izvede z uporabo regsvr32.exe.
Hehe, obvladas. :)
Ja, to je search funkcionalnost, ki jo rabim. Spot on. Ostane edino le se tista druga funkcionalnost, ki sem jo napisal v PDFju kot "tray app". :)
Glede DLLja. Lahko je tudi EXE (oz. se boljse, da je EXE). Sploh ce bi bila kombinacija se s tray app funkcionalnostjo. Dejansko "tray app" ne rabi biti tray app, lahko je deal "deskband search" appa.
PS Sporoci, ko bos imel cas, da se dobiva. Jaz naceloma imam vsak dan po 15h.
Pozabil sem se komentirat MFC, ATL... Moj namen z integracijo MFC je bil, da se ne bi prevec drobilo po projektih. Da je DLL, pa EXE, pa ... Ampak ce ne gre drugace, potem pac ne gre drugace... Oz. ce se precej poveca moznost, za kaksne buge, ali nedelovanje na kaksnih verzijah Windowsov itd itd.
Zgodovina sprememb…
- spremenil: d156 ()
BlueRunner ::
DeskBand komponente ima InProcess aktivacijo. Poenostavljeno to pomeni, da se koda izvaja znotraj explorer.exe procesa. Vsaka napaka v teh kodi pomeni napako v explorer.exe procesu, ki nadzoruje namizje (tray, ikone na namizju, Start vrstico, ... vse). Napaka pomeni sesutje tega procesa in njegov ponovni zagon. Na WV in W7 je bil sistem nadgrajen tako, da ti povrne vse tray ikone, na XP in starejših pa temu ni tako... Torej bi sesutje skoraj vedno pomenilo, da se mora uporabnik odjaviti, nato pa znova prijaviti. Zato je pri DeskBand aplikacijah manj == več. Manj kode je manj verjetnosti za napako, kar pomeni več stabilnosti.
Drug zadržek je način dela MFC-ja, kadar želiš uporabljati Document/View njegovo arhitekturo. To je skelet, kjer je aplikacija "car", ostale funkcionalnosti pa se ji podrejajo. _USRDLL se sicer lahko uprablja, vendar pa ga ni čisto trivialno podakniti kakšni drugi aplikaciji. Še posebej, če je tista druga aplikacija večnitna. Takšen način delovanja, kot se ga poslužujem tukaj, predstavlja nevarnost, saj obstaja čisto realna možnost, da se bo več razširitev, ki uporabljajo MFC, med seboj steplo. "Steplo" pa v tem kontekstu pomeni preprosto prekinitev delovanja in sesutje procesa. Proces pa je explorer.exe (gl. zgoraj). Document/View arhitektura pa je pogojena s tem, da si v specifikaciji zahteval CHtmlView. Rešitve za to zagato se skrivajo v uporabo CHtmlCtrl, ki sem ti ga naredil zadnjič, zamenjavi MFC z WTL ali pa preprosto ločitvi HTML funkcionalnosti v nov proces (.exe) s katerim .dll potem komunicira.
Tretji zadržek je poraba pomnilnika. DeskBand lahko skriješ, vendar to še ne sprosti pomnilnika, ki ga zaseda. Če imaš W7, lahko postaviš DeskBand, odpreš "builtin" brkljalnik, nato pa zapreš DeskBand. Okno z brkljalnikom bo ostalo odprto, ker je DLL še vedno v pomnilniku. Hkrati pa nimaš nobenega enostavnega načina, da se ga bi iz pomnilnika znebil. To je še en razlog, da se .dll in .exe ločita.
Četrti zadržek pa je povezan z drugim. Inicializaciji, ki jo MFC izvede za .EXE in _USRDLL se razlikujeta (tretja varianta, _AFXDLL tukaj ni relevantna), obe pa se zanašata na "skrite" metode WinMain in DllMain. Čeprav je tehnično možno, da se da kodo za _USRDLL aktivacijo v .EXE in se hkrati ohrani tudi originalno .EXE inicializacijo, je to z MFC-jem zelo, zelo, zelo grd hack, ki ga je potem kot izvorno kodo tudi težje vzdrževati od alternativ. Če bi vzel drug framework, npr. WTL, potem bi to lahko izvedel, saj sta .EXE in .DLL samo dve opimenovanji za isto stvar. Razlikujeta pa se samo v temu, da se prvega "požene" s klicem WinMain, drugega pa inicializira s klicem DllMain.
To so nekako 4 razlogi za ločitev DeskBand in Browser funkcionalnosti na dva projekta. Funkcionalnega prekrivanja med projektoma praktično ni, vsak opravlja svoje delo na optimalen način, medsebojna komunikacija pa je pred uporabnikom skrita.
Tray app pa se potem res doda kot komponenta v .EXE. Pri zagonu pa se nadzoruje kako se bo aplikacija zagnala. Recimo, da z enim parametrom določiš "startup" obnašanje, kjer glavno okno ostane skrito, prikaže pa se TrayApp. Pri nadalnjih zagonih brez uporabo posebnega parametra pa se vedno pokaže tudi glavno okno aplikacije.
Kaj praviš?
PS: Aha, ko smo že pri podpori za starejše sisteme. Ta DeskBand deluje tudi na Win2000 SP4 + Update Rollup 1 in z originalnim IE 5.0. To je minimum, da lahko namestiš VC2008 runtime. Če pa želiš podporo tudi še starejšim, potem pa moraš preiti na VC2005, če ne še malo bolj nazaj. Novejše VC knjižnice na starejših platformah več ne delujejo. Iz vidika funkcuionalnosti pa bistvenih razlik ni, saj je samo Vista dodala en nov vmesnik za Aero compositing... Da userdraw kontrole vedo kdaj je aktiven in kdaj ne, s čemer se omogoči pravilen izris Start vrstice.
Drug zadržek je način dela MFC-ja, kadar želiš uporabljati Document/View njegovo arhitekturo. To je skelet, kjer je aplikacija "car", ostale funkcionalnosti pa se ji podrejajo. _USRDLL se sicer lahko uprablja, vendar pa ga ni čisto trivialno podakniti kakšni drugi aplikaciji. Še posebej, če je tista druga aplikacija večnitna. Takšen način delovanja, kot se ga poslužujem tukaj, predstavlja nevarnost, saj obstaja čisto realna možnost, da se bo več razširitev, ki uporabljajo MFC, med seboj steplo. "Steplo" pa v tem kontekstu pomeni preprosto prekinitev delovanja in sesutje procesa. Proces pa je explorer.exe (gl. zgoraj). Document/View arhitektura pa je pogojena s tem, da si v specifikaciji zahteval CHtmlView. Rešitve za to zagato se skrivajo v uporabo CHtmlCtrl, ki sem ti ga naredil zadnjič, zamenjavi MFC z WTL ali pa preprosto ločitvi HTML funkcionalnosti v nov proces (.exe) s katerim .dll potem komunicira.
Tretji zadržek je poraba pomnilnika. DeskBand lahko skriješ, vendar to še ne sprosti pomnilnika, ki ga zaseda. Če imaš W7, lahko postaviš DeskBand, odpreš "builtin" brkljalnik, nato pa zapreš DeskBand. Okno z brkljalnikom bo ostalo odprto, ker je DLL še vedno v pomnilniku. Hkrati pa nimaš nobenega enostavnega načina, da se ga bi iz pomnilnika znebil. To je še en razlog, da se .dll in .exe ločita.
Četrti zadržek pa je povezan z drugim. Inicializaciji, ki jo MFC izvede za .EXE in _USRDLL se razlikujeta (tretja varianta, _AFXDLL tukaj ni relevantna), obe pa se zanašata na "skrite" metode WinMain in DllMain. Čeprav je tehnično možno, da se da kodo za _USRDLL aktivacijo v .EXE in se hkrati ohrani tudi originalno .EXE inicializacijo, je to z MFC-jem zelo, zelo, zelo grd hack, ki ga je potem kot izvorno kodo tudi težje vzdrževati od alternativ. Če bi vzel drug framework, npr. WTL, potem bi to lahko izvedel, saj sta .EXE in .DLL samo dve opimenovanji za isto stvar. Razlikujeta pa se samo v temu, da se prvega "požene" s klicem WinMain, drugega pa inicializira s klicem DllMain.
To so nekako 4 razlogi za ločitev DeskBand in Browser funkcionalnosti na dva projekta. Funkcionalnega prekrivanja med projektoma praktično ni, vsak opravlja svoje delo na optimalen način, medsebojna komunikacija pa je pred uporabnikom skrita.
Tray app pa se potem res doda kot komponenta v .EXE. Pri zagonu pa se nadzoruje kako se bo aplikacija zagnala. Recimo, da z enim parametrom določiš "startup" obnašanje, kjer glavno okno ostane skrito, prikaže pa se TrayApp. Pri nadalnjih zagonih brez uporabo posebnega parametra pa se vedno pokaže tudi glavno okno aplikacije.
Kaj praviš?
PS: Aha, ko smo že pri podpori za starejše sisteme. Ta DeskBand deluje tudi na Win2000 SP4 + Update Rollup 1 in z originalnim IE 5.0. To je minimum, da lahko namestiš VC2008 runtime. Če pa želiš podporo tudi še starejšim, potem pa moraš preiti na VC2005, če ne še malo bolj nazaj. Novejše VC knjižnice na starejših platformah več ne delujejo. Iz vidika funkcuionalnosti pa bistvenih razlik ni, saj je samo Vista dodala en nov vmesnik za Aero compositing... Da userdraw kontrole vedo kdaj je aktiven in kdaj ne, s čemer se omogoči pravilen izris Start vrstice.
Zgodovina sprememb…
- spremenilo: BlueRunner ()
d156 ::
OK. :)
Tudi jaz sem razmisljal, da bi lahko CHtmlView okno lahko bilo del "tray app" exeja. Tako da, lahko se tako naredi.
Dejansko bi najraje videl, da bi lahko EXE instaliral/startal deskband DLL (tako kot to naredi Calendar demo, ki je locen v DLL (deskband) in v EXE (tray app) in EXE zna instalirat/startat DLL). Jaz DLL ne znam drugace startat kot s regsvr32 - za uporabnika je to mogoce prevec za pricakovat.
Glede verzij Windowsov. Rabim dobit VS2005, ker imam samo VS2008. Podpora za starejse verzije bi bila zelo dobrodosla! :)
PS Glede WTLja ne vem, se mi zdi je MFC bolje, ker je uradno podport, WTL je pa neuraden, ceprav kar lepo dajejo nove verzije. Kljub temu bi bolje spal z MFCjem kot z WTLjem. Spanec je pa pomemben :)
Tudi jaz sem razmisljal, da bi lahko CHtmlView okno lahko bilo del "tray app" exeja. Tako da, lahko se tako naredi.
Dejansko bi najraje videl, da bi lahko EXE instaliral/startal deskband DLL (tako kot to naredi Calendar demo, ki je locen v DLL (deskband) in v EXE (tray app) in EXE zna instalirat/startat DLL). Jaz DLL ne znam drugace startat kot s regsvr32 - za uporabnika je to mogoce prevec za pricakovat.
Glede verzij Windowsov. Rabim dobit VS2005, ker imam samo VS2008. Podpora za starejse verzije bi bila zelo dobrodosla! :)
PS Glede WTLja ne vem, se mi zdi je MFC bolje, ker je uradno podport, WTL je pa neuraden, ceprav kar lepo dajejo nove verzije. Kljub temu bi bolje spal z MFCjem kot z WTLjem. Spanec je pa pomemben :)
d156 ::
DeskBand komponente ...
Eno vprasanje. A ti mogoce delas sedaj na tray app funkcionalnosti?
Rabil bi vedeti, da lahko dolocene druge stvari planiram...
BlueRunner ::
Bom pogledal in podelal obe stvari do konca tedna (konec tedna sta sobota/nedelja, ne petek).
Sicer pa moram reči, da sem si mislil, da je v Sloveniji več znalcev iz MFC. Še kakšno desetletje nazaj smo se neprestano srečevali, danes pa kakor, da tega več nihče ne želi početi. Saj razumem moderne tehnologije, produktivnost, RAD, ... ampak, da se tega niti popoldne ne da nikomur malo popraskati, pa res nisem pričakoval.
Sicer pa moram reči, da sem si mislil, da je v Sloveniji več znalcev iz MFC. Še kakšno desetletje nazaj smo se neprestano srečevali, danes pa kakor, da tega več nihče ne želi početi. Saj razumem moderne tehnologije, produktivnost, RAD, ... ampak, da se tega niti popoldne ne da nikomur malo popraskati, pa res nisem pričakoval.
noraguta ::
Sicer pa moram reči, da sem si mislil, da je v Sloveniji več znalcev iz MFC. Še kakšno desetletje nazaj smo se neprestano srečevali, danes pa kakor, da tega več nihče ne želi početi.le zakaj , le zakaj :~))). sam sem se pečal z wx-i(praktično enak koncept kot mfc), na koncu obupal , ker oneman band pač ne more špilat polifonične glasbe, pa vse skup prepisal v winformse, kjer je znalcev kolikor hočeš pa še nadzor nad kvaliteto kode in vzdrževanje sta precej lažja. Sicer pa na splošno fantje iz supporta če jim omeniš c++ radi otrpnejo potem ti pa pljunejo v obraz in odkorakajo iz salona.
Pust' ot pobyedy k pobyedye vyedyot!
BlueRunner ::
odkorakajo iz salona
Verjetno je v temu težava... iz salona je lahko biti pameten in ne videti rovov. MS pa svoje glavne produkte (Windows + Office + SQL Server + ...) še vedno dela s C++. Šele (pred)zadnja inkarnacija IIS-a je recimo temu resnično absorbirala .NET kodo. Tudi če želiš uporabljati UI elemente, ki jih ponuja Windows 7, pa moraš uporabiti interop knjižnice, da prideš do tistega, kar je C programerjem že položeno v zibko. Podobno pa je veljalo tudi za Visto in takrat aktualno verzijo .NET Framework.
Saj jaz sem tudi za VM okolja in vse dobrobiti, ki jih ti prinašajo. Ampak nisem si pa mislil, da je neko znanje kar nenadoma nekam poniknilo in ga več nikjer ni... Izgleda, da sem prava generacija X. PHP mi ni všeč, Python je za okolico preveč tog, C++ je pa za stare fosile in nevaren za uporabo.
noraguta ::
. Ampak nisem si pa mislil, da je neko znanje kar nenadoma nekam poniknilo in ga več nikjer ni... Izgleda, da sem prava generacija X.
to so ljudje prav iz te generacije. dejansko so povečini splezali iz supporta ven.(po mojem mnenju najbolj zajeban posel v industriji) Dočim c tolerirajo so pa veliki c++ haterji. ker je branje multiparadigm jezikov dobeseden brain fuck, če jo nisi spisal sam predkratkim. Saj to znanje je ampak večini se ne da ukvarjat z reševanjem kolateralne škode. Seveda brez native implementacij dostikrat ne gre, ampak tudi pri mfc moraš nemalokrat skrenit v win32, pa tudi dandanes imaš interop knjižnice bolj ali manj za večino funkcionalnosti v windowsih.
Pust' ot pobyedy k pobyedye vyedyot!
BlueRunner ::
Dočim c tolerirajo so pa veliki c++ haterji. ker je branje multiparadigm jezikov dobeseden brain fuck, če jo nisi spisal sam predkratkim.
He, he... še malo pa bom malo osvežil znanje Cobol in FORTRAN. Ker sem očitno eden zadnjih čudakov v teh logih - pa, da še do konca izpo(po)lnim tudi ta stereotip. Je pa res, da sem začel svojo pot s Turbo Pascal/C++ kombinacijo, kar pomeni, da so bili moji mladi možgani verjetno že takrat nepovratno deformirani. Wirth + Knuth + K&R vsi istočasno pod vzglavnikom mora pustiti trajne posledice.
noraguta ::
se zna zgodit , da ti bosta ali fortran ali cobol padla v naročje brez velikega osvajanja. sam sem se moral 3 leta nazaj adaptirat na prebavljanje piton-fortran naveze(se mi je pa pri tem podrl mit o znanstvenikih kot nekih solidnih programerjih), pa mi niti približno ne pade na pamet , da bi počel z njima kaj več kot zgolj vzdrževanje. sicer pa mislim , da tudi ms inhouse v čedalje večji meri uporablja prisilno modularizacijo(managed-wrapper-unmanaged), IIRC naj bi rico mariani VS 2010 spravil nekje na fifty-fifty situacijo. predvsem ker gredo trendi v deklerativne vode na kar lepijo različne backende(tipičen primer wpf ki je lahko strojno pospešen na gpu prek aera ali pa prek caira na linuxu , nekaj podobnega se gredo z nitkarjenjem).
Pust' ot pobyedy k pobyedye vyedyot!
BlueRunner ::
Gre, gre... vse gre v to smer in z dobrimi razlogi, kot si tri že naštel (hitrejši razvoj, lažji nadzor kvalitete, lažje vzdrževanje). Ampak "bazična koda" (v narekovajih, ker niti ne vem točno kako bi to definiral), pa še vedno ostaja v unmanaged vodah.
JVM lahko napišeš v Javi, ampak nihče tega ne reklamira, kot dobro idejo. Pa še je takšnih primerov. Meni osebno pa so kot programerju vedno bolj dišale bolj bazične stvari. Včasih gledano implementacijsko (base services), včasih pa gledano arhitekturno (underlying principles).
Se pa stvari hitro spreminjajo in ne bi si upal napovedati kako bo šlo tukaj naprej. Lovljenje GHZ-jev se je upočasnilo, večanje zmogljivosti pa se je preusmerilo iz navpičnega v horizontalno. Na eni strani se gremo lahko danes masovno paralelizacijo, ki jo je neizmerno lažje izkoristiti s pristopi, ki s klasičnim deklarativnim "enonitnim" programiranjev nimajo ravno veliko. Na drugi strani pa imam občutek, da se znova pojavlja težnja po temu, da bi bili osnovni gradniki znova napisani na način, ki bolj optimalno izkorišča vire. Tukaj pa se prevelika abstrakcija v xVM-jih velikokrat pokažeje kot omejitev, saj veliko programerjev, ki so ob njih odraščali, dejansko ne pozna arhitekturnih osnov strojarne. Potem pa nevede delajo napake in znova odkrivajo toplo vodo ali pa, kar je še huje, samo recepte kaj dela in kaj ne. Po drugi strani pa staroste, ki programirajo (programiramo?) v stari klasiki morajo poznati te arhitekturne lastnosti sistemov, oziroma jih poznajo v veliko večji meri, kot pa tisti, ki se s C/C++ niso nikoli zares ukvarjali. Torej postaja znanje C ali pa C++ znova referenca. Pa ne zaradi samega sebe, temveč bolj zaradi nekih posledic, ki iz tega znanja izhajajo. Sam še vedno menim, da bo vsak programer tudi v JVM/CLR okolju delal bistveno bolje, če bo pred tem poznal C. To pa samo zato, ker znanje C kot nujno posledico prinese tudi znanja o temu kako ti računski stroji v resnici delujejo.
Kar se pa tiče samega MFC-ja, pa je bila stvar že od 1. dneva kritizirana. Se še prav dobro spomnem borlandovega OWL-ja, ki je bil resnično objektna hirearhija. MFC pa je bil že od samega trenutka stvaritve samo tanek sloj preko Win32 API, DocView arhitektura pa samo najlažji način kako C++ programerjem dati relativno enostaven dostop do OLE dokumentov. Foundation Classes je kar primeren izraz za to, kar ta knjižnica sploh je. Bazični razredi. Če jo gledaš takšno, kot je, potem so to predvsem olajšava pri klicanju API-ja in sledenju Hnekaj ročic. Potem pa se stvar zaključi, Win32 API pa je pred teboj z vsemi svojimi dobrimi in slabimi lastnostmi.
JVM lahko napišeš v Javi, ampak nihče tega ne reklamira, kot dobro idejo. Pa še je takšnih primerov. Meni osebno pa so kot programerju vedno bolj dišale bolj bazične stvari. Včasih gledano implementacijsko (base services), včasih pa gledano arhitekturno (underlying principles).
Se pa stvari hitro spreminjajo in ne bi si upal napovedati kako bo šlo tukaj naprej. Lovljenje GHZ-jev se je upočasnilo, večanje zmogljivosti pa se je preusmerilo iz navpičnega v horizontalno. Na eni strani se gremo lahko danes masovno paralelizacijo, ki jo je neizmerno lažje izkoristiti s pristopi, ki s klasičnim deklarativnim "enonitnim" programiranjev nimajo ravno veliko. Na drugi strani pa imam občutek, da se znova pojavlja težnja po temu, da bi bili osnovni gradniki znova napisani na način, ki bolj optimalno izkorišča vire. Tukaj pa se prevelika abstrakcija v xVM-jih velikokrat pokažeje kot omejitev, saj veliko programerjev, ki so ob njih odraščali, dejansko ne pozna arhitekturnih osnov strojarne. Potem pa nevede delajo napake in znova odkrivajo toplo vodo ali pa, kar je še huje, samo recepte kaj dela in kaj ne. Po drugi strani pa staroste, ki programirajo (programiramo?) v stari klasiki morajo poznati te arhitekturne lastnosti sistemov, oziroma jih poznajo v veliko večji meri, kot pa tisti, ki se s C/C++ niso nikoli zares ukvarjali. Torej postaja znanje C ali pa C++ znova referenca. Pa ne zaradi samega sebe, temveč bolj zaradi nekih posledic, ki iz tega znanja izhajajo. Sam še vedno menim, da bo vsak programer tudi v JVM/CLR okolju delal bistveno bolje, če bo pred tem poznal C. To pa samo zato, ker znanje C kot nujno posledico prinese tudi znanja o temu kako ti računski stroji v resnici delujejo.
Kar se pa tiče samega MFC-ja, pa je bila stvar že od 1. dneva kritizirana. Se še prav dobro spomnem borlandovega OWL-ja, ki je bil resnično objektna hirearhija. MFC pa je bil že od samega trenutka stvaritve samo tanek sloj preko Win32 API, DocView arhitektura pa samo najlažji način kako C++ programerjem dati relativno enostaven dostop do OLE dokumentov. Foundation Classes je kar primeren izraz za to, kar ta knjižnica sploh je. Bazični razredi. Če jo gledaš takšno, kot je, potem so to predvsem olajšava pri klicanju API-ja in sledenju Hnekaj ročic. Potem pa se stvar zaključi, Win32 API pa je pred teboj z vsemi svojimi dobrimi in slabimi lastnostmi.
d156 ::
Bom pogledal in podelal obe stvari do konca tedna (konec tedna sta sobota/nedelja, ne petek).
Odlicno. Komaj cakam na ponedeljek... :)
d156 ::
Bom pogledal in podelal obe stvari do konca tedna (konec tedna sta sobota/nedelja, ne petek).
Odlicno. Komaj cakam na ponedeljek... :)
Kako kaze? :)
BlueRunner ::
O, lej ga... Ja, pa imam res nekaj zate. Samo še kakšen zanimiv regex za testiranje bi potreboval, da ne bom na suho drgnil stvari.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | analiza hijack thisOddelek: Pomoč in nasveti | 1923 (1703) | klaudija |
| » | [C++] Uporabnost c++-a v današnjih časih (pa malo linuxa)Oddelek: Programiranje | 2802 (1985) | [SkA] |
| » | [c++] prenosljivostOddelek: Programiranje | 1697 (1512) | Celeborn |
| » | Visual C++ .NETOddelek: Programiranje | 972 (795) | OwcA |
| » | Visual Basic Developer Site & ForumOddelek: Programiranje | 1896 (1487) | webblod |