Ma win32API je svoje vrijeme vec otkucao, sad kad dodje winFX u Longhornu, nece ga koristiti na najveci zagovornici. MS-u vrlo dobro ide kako tjeranje klijentele za kupovanje novog hardvera (postavljanjem minimalnih hardverskih zahtjeva u novim generacijama windoza), tako i forsiranje novih tehnologija, sucelja...Htio ne htio.. .NET je buducnost :-(

Da, Microsoft ohrabruje programere da se bave .NET-om i očekuju Avalon - novi API za GUI. Međutim, Longhorn treba da se pojavi tek krajem 2006-te, a dok postane dominantna platforma još će dosta vode proteći, pa ja ne bih baš tako rano odustajao od Win32 API. Uglavnom, ako hoćeš da koristiš C++ za GUI programiranje, mislim da je MFC (nažalost) jedini logičan izbor.

jedva čekam dan kada će DT preći na .net :-P


btw, nije mfc jedini izbor. postoje i druge biblioteke za pravljenje GUIa, mnoge od njih i portabilne...

Da tako sam i mislio, MFC. Takodje sam cuo dobre price o WTL template biblioteci, DT sta mislis o njoj?
Za C# cu prvo morati dobro da se informisem jer ne znam nista o njemu.

Longhorn Krajem 2006.? Pa vec sad po netu postoje neke beta piratske verzije koje kao rade... A sta je sa 64-bitnim Windowsima, oni ce sigurno ranije izaci, kakve ce oni imati promene u API-ju?

-zombie-, naravno da MFC nije jedini izbor, ni yugo nije jedini auto, ali je verovatno najbolji u ovom trenutku (mislim na MFC ne na yugo )

@zombie: Ja sam već "prešao" na .NET za neke aplikacije (mada i tu radije koristim C++ nego C#).

@Mikky: WTL je mnogo bolje dizajnirana biblioteka nego MFC (razumljivo s obzirom da je rad na MFC-u počeo krajem 80-ih u vreme kad je C++ bio još u povoju), i znam mnoge koji su totalno prešli sa MFC-a na WTL. Međutim, imaj u vidu par stvari:

1. WTL zahteva bolje poznavanje C++a nego MFC - pre svega višestruko nasleđivanje i šabloni (templates).

2. Kao što si i sam zapazio, za MFC postoji "brdo" gotovih kontrola na sajtovima kao što su Code Project i Code Guru. Može se tamo naći dosta toga i za WTL, ali u poređenju sa MFC-om ipak jako malo.

3. Dokumentacija za WTL je gotovo nepostojeća, osim nekoliko članaka koji se mogu naći na internetu.

Najzad, ako ti je stalo da ti aplikacije budu "male" (mislim na malu veličinu exe fajla i eventualno pratećih dll-ova), onda zaboravi MFC i prioni na WTL.

I još da dodam. Imao sam priliku nedavno da pričam sa ljudima iz VC++ tima i rekli su mi da planiraju da naprave nešto slično WTL-u što će da radi sa Avalonom.

Ja sam bio u slicnoj situaciji, korisitio sam C i API, i bio sam u dilemi sta da koristim dalje jer mi se MFC nikako ne svidja.
Na kraju sam se odlucio za WTL i veoma sam zadovoljan, po mom misljenju je odlican i mnogo mi je olaksao posao. Mana mu je verovatno sto je skoro potpuno nedokumentovan, ali meni licno ovo ne smeta. Ukoliko si spreman da vise ucis gledajuci source i dobro poznajes winapi, WTL uopste nije los izbor (naprotiv). Ovo je po malo i stvar licnog ukusa.

Ok mogao bih onda da pocnem malo i sa MFC i sa WTL pa sam da odlucim koji mi vise lezi. Btw da li i u kojoj meri je moguce kombinovanje ova dva?

bzero, kako najbolje poceti s obzirom na taj nedostatak dokumentacije, mozes li mi dati neke smernice za pocetak.

Za početak sa WTL-om, najbolje je da pogledaš članke Michalea Dunna na Code Project-u (na slici nije on, već njegova devojka :) )

http://www.codeproject.com/scr...s/list_articles.asp?userid=152

Verovatno najvise stvari ima na CodeProject-u:

http://www.codeproject.com/wtl/

za pocetak pogledaj Begginers deo, gde ces naci neke osnovne stvari.
Pored ovoga WTL grupa na Yahoo-u:

http://groups.yahoo.com/group/wtl/

WTL namespace reference:

http://www.gnomedia.com/cw/wtl/wtldocs/namespaceWTL.html

i dosta zanimljivog koda:

http://home.worldonline.dk/viksoe/all_wtl.htm

I da ne zaboravim: odličan članak (1-vi deo, ima i drugi) za Win32 API programera koji želi da razume MFC:

http://www.codeproject.com/cpp/mfc_architecture.asp

Mozda ti je ipak bolje da za UI koristis Winforms (dakle .NET), bilo iz C++a ili iz C#a, stagod ti vise odgovara. Bolje ti je da svoje vreme ulazes u nove tehnologije nego u zastarele. A i pre ces zavrsiti posao u .NETu...

Mislim da je pre Winforms zastarela tehnologija nego WTL. Koliko sam razumeo, to je samo privremeno rešenje dok ne stigne Longhorn sa Avalonom.

Skoro (nije jos zastereo), ali je model mnogo blizi Avalonu nego WTL / MFC. Znaci ako vec covek mora da se opredeli za nesto sa ogranicenim rokom trajanja, onda da to bude ono sto je najblize novoj tehnologiji.

Jeste, ali kao što sam već napomenuo VC++ tim planira biblioteku vrlo sličnu WTL-u koja će ispod haube da koristi Avalon a ne Win32 API, pa mislim da je WTL u tom smislu bolja investicija nego WinForms.

Lično mislim da nema mnogo smisla praviti .NET desktop aplikacije (osim možda za neke unutar-kompanijske potrebe) pre nego što Longhorn zauzme bar 50% tržišta. .NET je, kao i Java, sjajna platforma za Web aplikacije, ali ga ne vidim na desktopu još nekoliko godina.

Pa, posto sam framework jeste ili ce uskoro da bude na prakticno svakom kompjuteru sa XPom, interesuje me zasto mislis da sada ne treba praviti .NET desktop aplikacije (i na sta mislis pod 'desktop' - Word ili WinZip)?

ma nemanja je poznati konzervativac po tom pitanju, i mislim da nema razloga ulaziti u još jednu ovakvu raspravu.

on ima svoje (često opravdane) razloge da misli to što misli, i ne verujem da ga možete ubediti u suprotno :-P


A conservative is a man who believes that nothing should be done for the first time. -- Alfred E. Wiggam

(bez ljutnje ;)

Relja, da li to znači da će .NET da ide obavezno kao deo Service Pack-a 2 za Windows XP? Ako ne, zašto misliš da će .NET biti na praktično svakom Windows kompjuteru pre.. recimo 2008/9 (i to ako Longhorn izađe 2006)?

Kao što rekoh, zavisi od aplikacije. Verovali ili ne, nama mušterije traže da podržavamo Windows 95 i bilo je jako čupavo kad smo im saopštili da podržavamo samo 2k+. Verovatno se ne bi završilo na tome da se nije ispostavilo da naše biblioteke rade i na W95, mada ih ne testiramo na tim sistemima. Što se tiče .NET-a, imamo jednu, uslovno rečeno desktop aplikaciju za "unutrašnje" potrebe koja radi na .NET platformi i mogu vam reći da su hardverski zahtevi nešto tipa minimum PIII sa 1Gz i 512Mb memorije. Ovo je minimum!?!?!?

Da me ne shvatite pogrešno, ja verujem da je .NET budućnost i da se treba baviti time, ali ako želite da pravite desktop aplikacije za "široku upotrebu", zaboravite na .NET još nekoliko godina.

Ok, primedbe na racun performansi su ok - ja sam te razumeo da ti se ne dopada nesto drugo, tipa sam API, broj PCa sa frameworkom, itd. Vreme ce srediti to sa performansama - vreme leci sve :)

A do tada, treba sesti i izanalizirati - ako se projekat pocinje sada, moze da se proceni sta ce biti min config kada to bude pocelo da se prodaje, i u zavisnosti koliko je kompleksan UI, izabrati da li treba da se radi u .NETu ili necemu drugom. U .NETu ce UI biti sigurno jeftiniji za razvoj i odrzavanje, ali ce to zato kostati u performansama.

ovo mi je poznato. i mi smo skoro naišli na ovaj "zahtev", al sam ja mislio da je to zbog toga što je ovo srbija. izgleda da to nije bio razlog ;)

a inače, kako ja da podržavam win98, kad ni MS više ne podržava ništa starije od w2k?

jel može neko da mi objasni taj paradox?

MS podržava ne samo W98, već i NT4 (iz 1996), ali većini nezavisnih firmi je to potpuno neisplativo - osim kad ljute mušterije sednu na vrat :)

During the next few months, Microsoft will begin phasing out support for a number of its Windows flavors and related technologies.

http://www.microsoft-watch.com/article2/0,4248,1418117,00.asp

At the end of mainstream support, business and developer software customers have the option of purchasing up to two years of "extended support."

Probaj wxWindows. Ja ga koristim vec oko godinu dana i vrlo sam zadovoljan.

http://www.wxwindows.org

Inace, OpenSource je i ima specijalnu licencu (nesto slicno MPL) tako da je 100% free i za komercijalnu upotrebu, a ne treba da "otvoris" svoj kod.

zar nisu najavili end of life za pocetak 2003-e?

GTK# i QT# su moj odgovor (ako bas pozelis da se bavis .NET-om). O Avalon-u ne znam nista, ali neki low-level API koji ce moci da se koristi iz C-a (pa i asemblera) ce Microsoft morati da obezbedi ako zeli da ima "normalan" OS. Dakle, poprilicno sam siguran da price tipa "WinAPI je mrtav" nemaju osnova. Nesto sam poprilicno siguran da .NET koristi isti, a i spomenuti Avalon. ;)

Uz rizik da budem zheshce napadnut, moja preporuka bi bila : CLX u C++Builder-u.
CLX koristi Qt kao podlogu, gotovih komponenata imash kol'ko volish, sve shto napravish je skroz Win/Linux portabilno, i ceo sistem je pravi RAD, imash UI gotov za minut, bez nekog programiranja! A ako ti portabilnost nije bitna, VCL je to isto, samo malo robustnije (strogo Win32).
Nazalost, ni Borland vise nije siguran da je ovo future-proof , ali se itekako isplati probati!

Da, ako ga ne interesuje .NET o kome se prica(lo) u ovoj diskusiji CLX je svakako dobra odluka, a licno mislim i da je "future-proof", jer Borland (C++) skupa sa CLX koristim u par projekata...

Leka, da li mozes da mi objasnis ovo gore? Ispada da je CLX future-proof JER ga ti koristis u par projekata.

Ne znam, ali obicno prva asocijacija za "Borland" nije bas "future proof". Doduse, mozda gresim, mozda je u Evropi bitno drugacije stanje, ali u USA gotovo da nema poslova za Borland programere.

Ovaj citat nije tacan. VCL (Pascal code) je pun uslovnog kompajliranja (filovan IFDEF direktivama), radi portabilnosti na Linux. CBuilder taj 'gotov' VCL 'uvlaci' *.hpp fajlovima, tako da sto se CB-a (Delphi-ja?) tice, sistem je potpuno transparentan (Win32 ili Linux, svejedno mu je).
E sad, ako se pod 'portabilnost' mislilo i na neke druge sisteme...mrka kapa, pretpostavljam.

Rajko

čekaj rajko, sad si i mene zbunio. koliko sam ja upoznat, VCL se zasniva na win32 APIju, bar ovaj vizuelni deo, tj sve što nasleđuje od tWinControl.

sve "iznad" toga toga u hijearhiji (recimo tComponent) je zajedničko i za VCL i za CLX, a u CLX je tWinControl i sve ispod njega zamenjeno sa tWidgetControl, iz QTa.

ispravi me ako grešim?

Zombie, ne greshish, to jeste tako...
Prochitao sam x puta Rajkov post i dalje ne kontam shta je hteo da kazhe ...

ja otprilike mogu da skontam šta je rajko hteo da kaže, ali za pometnju je možda najviše kriv sam borland ;)

naime, VCL nije baš ono za šta se izdaje, znači nije samo Visual Component Library. u okviru VCLa su prisutne i komponente kao što su tComponent, tXMLDocument, tList, tReader i još mnoge druge koje nemaju veze sa vizuelnim, tj koriste se i u potpuno nevizuelnim aplikacijama kao što su npr serveri..

e sad, od (valjda) Delphi 6 je taj ne-vizuelni deo VCLa napisan portabilno, sa IFDEFovima i slično, tako da je totalno portabilan na linux, dok je vizuelni razdvojen na win32 VCL i qt CLX.

verovatno otuda pometnja ;)

Da, to sam upravo i napisao u prethodnim postovima. Mada, kada kazem VCL, ipak mislim na vizuelnu stranu stvari, i to je strogo Win32.
TList, AnsiString i slicne klase su ipak samo pozadinske, i ne moraju da se posmatraju kao deo VCL-a per-se. A i inace u Builder-u VCL komponente ne mozhesh da instancirash na steku (kao lokalne), moraju biti na heap-u, dok pomenute "pomocne" klase mozhesh da instancirash kako hocesh, shto ih i chini nekako odvojenim od VCL-a (i samim tim je logichno da se prave kao portabilne od starta)