Cześć,
za pomocą jakich głównie środowisk/bibliotek/narzędzi były dotychczas tworzone duże aplikacje desktopowe (jak np. Microsoft Word, Excel, Access, Corel Draw, Adobe InDesign itd. Czy były one tworzone w narzędziach typu C++ Builder, czy za pomocą MFC, czy jeszcze jakoś inaczej? W ogóle od kiedy Microsoft oferuje narzędzia RAD (.NET) do tworzenia aplikacji? Wydaje mi się, że od niedawna, a widziałem, że aplikacje pisane w MFC to mnóstwo dodatkowego kodu napisanego np. do obsługi okienek itp.
Jak teraz się to przedstawia? Słyszałem, że Microsoft wycofuje wsparcie dla MFC, czy w związku z tym wszystkie te duże aplikacje są teraz przenoszone na C#?
2
0
Wszystkie które wymieniłeś prawie na pewno w MFC. Na pewno nie w C# i na pewno nie C++ Builder.
0
OK,
a czy teraz w związku z wycofywaniem wsparcia dla C++/MFC przez Microsoft (czy to rzeczywiście jest prawda) należy oczekiwać przepisania tych programów do C#/.NET? W ogóle, to dziwi mnie, że Microsoft przez tak długi czas nie opracował żadnego narzędzia RAD będąc liderem na rynku produktów desktopowych, pozwalając chyba niepodzielnie rządzić tym rynkiem firmie Borland (jeżeli się mylę, to mnie poprawcie, ale tak czytałem w jakimś artykule). Wymierzanie miejsca, które winien zając odpowiedni przycisk/okienko dialogowe już samo w sobie może zeżreć znaczną ilość czasu, który możnaby przeznaczyć na zdecydowanie bardziej kreatywne rzeczy.
Czy jeszcze w ogóle opłaca się uczyć MFC?
Pozdrawiam
0
O jezu, chcesz się uczyć MFC? Daj sobie spokój, technologii jest dostatek (lepszych, nowych), po co zajmować się starociem?
6
Aplikacje kiedyś napisane w mfc są dalej rozwijane w mfc bo jest to tańsze niż przepisywanie ich od nowa. Czasy świetności C++ Buildera i Delphi już dawno minęły, mfc co prawda nie jest wycofywane, ale też rzadko już używane.
0
MS nie wycofuje wsparcia ani dla C++, ani dla MFC - wraz z nowym systemem pojawia się uaktualnienie MFC o nowe kontrolki, rozwiązania.
Hmm, w MFC też można sobie wyklikać okienka, zdarzenia, klasy i to nie tak od niedawna, bo z 10 lat jak nie więcej.
0
Jeśli chodzi o buildera to ciekawe projekty w nim mieszczą się tu chociażby :)
Niektóre z nich to naprawdę klasyki
http://www.embarcadero.com/rad-in-action/application-showcase
5
Marekleo napisał(a):
W ogóle, to dziwi mnie, że Microsoft przez tak długi czas nie opracował żadnego narzędzia RAD będąc liderem na rynku produktów desktopowych, pozwalając chyba niepodzielnie rządzić tym rynkiem firmie Borland (jeżeli się mylę, to mnie poprawcie, ale tak czytałem w jakimś artykule).
:D
Słyszałeś może o Visual Studio? Albo o tym, że Borland jakieś 5 lat temu przestał tworzyć narzędzia RAD?
Czy jeszcze w ogóle opłaca się uczyć MFC?
Nie. Rzadko kiedy można trafić na ofertę pracy w tym.
Na jakiej planecie byłeś przez ostatnie 15 lat?
1
O Visual Studio słyszałem, nawet używam Visual C++ czasami, ale RAD do tego środowiska zostało chyba stworzone stosunkowo niedawno, prawda (razem z C#/.NET)? A mówiąc o tym, że Microsoft przez tak długi czas nie utworzył narzędzi RAD miałem na myśli sytuację wcześniejszą.
O zaprzestaniu rozwijania narzędzi RAD przez Borland coś tam słyszałem, ale jak to teraz jest, to nie wiem, właściwie dlaczego to zarzucili?
Nie jestem programistą :).
0
W ogóle od kiedy Microsoft oferuje narzędzia RAD
Nie każda aplikacja musi być napisana przy pomocy RAD. To jedno.
Wszystkie programy Microsoftu możesz spokojnie założyć że sa pisane pod Visual Studio, w znacznej większości C++, a idąc dalej - w MFC.
O zaprzestaniu rozwijania narzędzi RAD przez Borland coś tam słyszałem, ale jak to teraz jest
Delphi i Buildera kupiło Embarcadero. Tam znajdziesz najnowsze wersje znajomych narzędzi. Resztę Borlanda (to była jakaś reszta?) kupił Micro Focus. Na głównej stronie MF jest link do artykułu “Rich modern COBOL development environment”, czyli to jakiś straszny beton jest.
Wydaje mi się, że od niedawna
wydaje mi się, że wydarzenia sprzed 5-10 lat wydają ci się niedawne. pobudka!
0
OK, dzięki za odpowiedź.
To, że nie każda aplikacja musi być napisana przy użyciu RAD - jasne, ale po co się męczyć klepaniem kodu, który może szybko zostać wygenerowany przez odpowiednie narzędzia (chyba, że masz na myśli aplikacje, w których w ogóle nie ma okienek, albo są tylko w minimalnym stopniu).
Jakich bibliotek radzilibyście się nauczyć osobie chcącej pisać duże aplikacje desktopowe, w których szybkość działania może mieć istotne znaczenie?
Wydarzenia sprzed 5-10 lat wydają mi się niedawne - no, coś w tym jest, rzadko wychodziłem poza C++ i konsolę :).
Pozdrawiam.
0
Jakich bibliotek radzilibyście się nauczyć osobie chcącej pisać duże aplikacje desktopowe, w których szybkość działania może mieć istotne znaczenie?
Ostatnio modne jest Qt. Szybkość działania na pewno, bo to natywny C++, a jak się sprawdza to nie wiem, na razie tylko liznąłem na poziomie Hello Worlda.
1
Jakich bibliotek radzilibyście się nauczyć osobie chcącej pisać duże aplikacje desktopowe
Ja bym raczej odradzał, bo odchodzi się od dużych aplikacji desktopowych (no może oprócz gier)
0
Hmm może autorowi tematu chodziło o środowisko do takie gdzie wizualnie tworzy się interfejs jak w Delphi/C++ Builder i generuje się pliki exe natywne... Bo faktycznie w Visual C++ Express trzeba ręcznie w WinAPI klepać interfejs, nawet nie ma edytora plików RC (np. okienek dialogowych), natomiast w MS Visual C++ Professional to jest wsparcie dla MFC i wizualny kreator. W MS Visual C++ Express można tworzyć wizualnie interfejs aplikacji, ale już jako aplikacja .NETowa (C++/CLI),a nie stricte natywny exek....
0
Takiego Photoshopa, nawet pierwsze wersje, nie sądze by tworzyli bez wizualnego edytora kontrolek, bo tam idzie się pogubić w setkach okienek dialogowych.
0
Photoshop to raczej mfc, przynajmniej te stare (6, 7), były w mfc, nowsze nie sprawdzałem, ale podejrzewam że też.
0
Do dużych aplikacji zdecydowanie wybrałbym C# i .NET. Najlepiej, najszybciej, najprościej, no i przyszłościowo. No i Visual Studio - cud,miód, malina -nieporównywalne raczej z niczym innym. Czego chcieć więcej ?
IMHO, wszystko poza .NET'em i Javą , może wyłączając assemblera w bardzo nielicznych zastosowaniach, to po prostu zabawki.
0
wybrałbym C# i .NET. Najlepiej, najszybciej, najprościej, no i przyszłościowo.
być może, być może i być może, ale co w .Net przyszłościowego?
To już jest od lat teraźniejszość, a nie przyszłość.
Poza tym, nie musi być wszystko koniecznie „przyszłościowe”.