Nauka programowania w Delphi- od czego zacząć?

Proponuje jednak zapoznać się z podstawą każdej nauki, w tym programowania - z logiką. Nie da się udowodnić że niema różowych kotów. Nie da się udowodnić że nie istnie Bóg. Nie da się udowodnić że czegoś nie da się zrobić.

Czyżby systemy operacyjne napisane w C# potrzebowali jakiegoś “systemy z rodziny Windows” aby się uruchomić?

W takim razie Delphi to też platforma :smiley: Bo istnieje tez Kaylix takie Delphi pod linuxa, klasy takie same itp.

Znowu ci coś pomerdało. 13ty Smok jest profesorem i prowadzi zajęcia w szkole wyższej.

Podałem działającą kontrolkę, chyba to proste sprawdzić jak działa i napisać dokładnie to samo, przecież nie ma tu żadnych super algorytmów pod spodem. Ta twoja nowa wersja zupełnie nie działa. Teraz aby wpisać 3,14 trzeba wpisać 314 cofnąć się o dwa znaki nacisnąć przyczynek, po czym kursor okaże się przed cyfrą 3. Może za jakieś pół roku doprowadzisz to do działania. A nie mówiłem, c# to syf :lol:

Jeżeli napisano 3,24 chce zmienić to na 3,14 wstaje pomiędzy 2 a 4 naciskam backspace wpisuje 1 w poprzedniej wersji u ciebie wychodziło 31,4. W nowej już widzę poprawiłeś ale coś innego zepsułeś, a ktoś kiedyś filozofował tu na forum o elastyczności, czyżby to tylko taka modna gadka?

W Delphi nie trzeba tego oprogramowywać. Mam zmienne “Volatile” ThousandSeparator, DecimalSeparator, CurrencyString, CurrencySeparator i tp oraz dwoma kliknięciami mam metodę formatki która się wywoła jeżeli użytkownik zmienił te ustawienia w systemie.

Oczywiście że mogę - mam typ Variant do dyspozycji. Tylko kto by chciał z tego korzystać w Delphi, chociaż czasami się przydaje.

Nie ma tu udawanej serializacji i zostawcie ten TFrame w spokoju - ja myślałem że somekind pyta o serializacji komponentów formatek i tp. Można serializować każdy obiekt pochodzący od TPersistent. Tak a propos grafika formatki (formatka to też obiekt) jest serializowana do strumienia od razu w formacie pliku RES, a przy konsolidacji tylko się dołącza do exe. Przy tworzeniu formatki w programie jest deserializowana z resource. Serializacja do pliku w formacie RES jest od Delphi 1. Serializacja do XML od Delphi 4.

TCar=class(TCollectionItem) // Deklaracja
  public
    FModel:String;
    FYear:Smallint;
  published
    property Model:String read FModel write FModel;
    property Year:Smallint read FYear write FYear;
  end;
  TCarClass=class of TCar; [/code]

[code=php]  List:=TCollection.Create(TCar); // Tworzenie rekordów z dodaniem do kolekcji  Car:=TCar(List.Add);  Car.Model:=‘Model1’;  Car.Year:=2008;  Car:=TCar(List.Add);  Car.Model:=‘Model2’;  Car.Year:=2009; 

  FS:=TFileStream.Create('dane.dat',fmCreate); // strumień
  SW:=TWriter.Create(FS,1024); // serializator
  SW.WriteCollection(List); // zapis do pliku w formacie RES, jest też WriteComponent oraz WriteProperties dla TPersistent
  SW.Free;
  FS.Free; [/code]

[code=php]  FS:=TFileStream.Create(‘dane.xml’,fmCreate); // strumień  xml:=TJvgXMLSerializer.Create(Self); // serializator  xml.Serialize(Car,FS); // zapis do pliku XML  xml.free;  FS.Free; 

Mówiliśmy o szyfrowaniu, powiedziałem że wszystko jest co znam. A na wypadek aby kolega nie znający się na logice nie zrozumiał tego niepoprawnie dopisałem że można użyć każdy ofiarowany w .NET. Dla człowieka myślącego który używa logiki oznacza to że w Delphi można użyć tyle samo lub więcej niż w C#, nie ma tu ani cienia chęci korzystania z syfa.

Są na to specjalne mechanizmy, z jednej strony TJvPlugIn z drugiej TJvPluginCommand.

Aplikacje webowe są w standardzie od chyba Delphi 3 (mogę się mylić w Delphi 5 już byli na 100%). Naciskasz File New i jedna z opcji to WebServerApplication w wariancie Exe lub Dll

Czego niby nie zrozumiałem, twojego wąskiego pojmowania refleksji?

Dorabiam jako FreeLancer pisze programy na zamówienia, więc jak narazie więcej zamówień mam w Delphi. Potężne pieniądze poszli na reklame .NET oraz C# przez jakiś czas to będzie działać.

Odpowiem na to twoimi słowami (dosłownie nie pamiętam): Kiedy zrozumiesz różnice między IDE a .NET ? Nie potrafiłem dodać do IDE - “Microsoft Visual C# 2008 Express Edition”, ale dla ciebie to oczywiście podstawy .NET :lol:

Delphi potrafi stworzyć na wyjściu:

Pliki wykonywalne .com - wg mnie jak najbardziej czysta binarka.

Pliki wykonywalne .exe

Biblioteki dynamiczne .dll

Biblioteki statyczne .lib

Pliki skompilowane .obj (kompatebilne z C++)

ActiveX i wele innych z których jak narazie nie korzystałem.

Nie, jedynie nie uwzględnia innych typów procesora.

Może ty już nie możesz, ja jak narazie mogę :smiley:

Widzę bardzo dużo o tym komponencie na tym linku co podałeś. Jak chcesz sobie ściągnąć to: Jedi open source project

Właśnie tak twierdze, opensourcowe projekty zawsze wykazywali się większą stabilnością oraz szybszym łataniem dziur niż ich odpowiedniki od korporacji.

To tylko na chłopski rozum. Czyżby nigdy ci się nie zdarzyło poprawiać kodu po nieudolnym autorze? Poza tym gdyby tak było to opensource’owe projekty nie mieli by sensu. Ktoś piszę zalążek a potem gro programistów poprawia, modyfikuje, rozwija. W jaki sposób mogą zrobić lepiej niż autor zalążka?

Nie tak dawno pisałem na zamówienie program komunikujący się z http://www.allegro.pl Allegro WebApi - wszystko przez Soap (używałem TJvgXMLSerializer).

Guziki - nawet wyglądające jak gwiazdka z okrągłą dziurką w środku.

Czyżby C# bezpośrednio korzysta ze sprzętowej akceleracji 2D/3D? Ma wbudowane sterowniki wszystkich kart graficznych?

To powiedz, jak to robisz, z chęcią się dowiem. Poza tym, możliwość zrobienia .com niewiele ci da - .com jak to .com, jest programem 16-bit, czasy systemów w real mode się skończyły wraz z wyginięciem dinozaurów.

Racja, to dotyczy tylko x86. Szkoda, że w tej architekturze timigi ADD i INC zawsze były albo takie same, albo (jak w przypadku P4) ADD był trochę szybszy.

To zrób. Z chęcią zobaczę.

Wystarczą te, które zainstaluje user…

Dla Singularity kompilatrem jest Bartok, który kompiluje C# od razu do kodu natywnego(ew. jeszcze jest asembler, ale pewien nie jestem).

Nie. .NET Framework to nie tylko zestaw klas. .NET obejmuje środowisko uruchomieniowe, zestaw klas(WF, WPF) i niektóre technologie(np. ASP.NET) niezależne od języka(widziałem asembler ze składnią NASM-a do pisania stron w ASP.NET). A Delphi to tylko język. VCL to znów tylko zbiór klas. Nic więcej.

Nie wiesz co to mechanizm refleksji. To nie tylko ładowanie innych bibliotek(zresztą to jest chyba wszędzie możliwe, .dll - LoadLibrary w WinAPI, dynamiczne ładowanie .so też gdzieś widziałem) ale również listowanie pól, metod, podklas, przestrzeni nazw i wszystkiego co może zawierać się w tej DLL-ce. Do tego wszelakiego rodzaju adnotacje(po których można wyszukiwać metody i klasy) jak i cała przestrzeń nazw System.Reflection.

Akurat referencje to nie są tylko w IDE, ale cała platforma .NET się na nich opiera. Jak narazie to ty mylisz IDE z .NET.

Zacznijmy od tego, że Jedi nie jest standardem dla Delphi i VCL.

GDI+

To coś z logiką u Pana magistra słabo. Można udowodnić, że nie istnieją 3 liczby naturalne a, b, c spełniające warunek a^3 + b^3 = c^3. Można udowodnić, że nie istnieje największa liczba pierwsza (ten dowód jest na tyle krótki, że jeśli masz jakieś wątpliwości, mogę go przytoczyć). Można udowodnić, że za pomocą liniału i cyrkla nie da się podzielić kąta na 3 równe części. Takich dowodów w matematyce jest multum. Łyso?

Czyli mając na uwadze dozwolone jednokrotne dziedziczenie klas, NIE KAŻDY. W praktyce użyteczność takiego rozwiązania jest mocno ograniczona. W C# i Java mogę serializować obiekt każdej klasy, niezależnie od tego, gdzie jest w hierarchii i jaką ma klasę bazową.

To użyj mi garbage collectora takiego jak w .NET lub JVM do Twojego programu napisanego w Delphi.

Samo GC skraca czas programowania o ok. 1/3 i eliminuje większość trudnych do wyłapania błędów związanych z zarządzaniem pamięcią.

Przy używaniu słów ZAWSZE, NIGDY, WSZĘDZIE itp. należy zachować szczególną ostrożność. Po pierwsze najczęściej (nie zawsze, ale tak na oko gdzieś proporcja jest w okolicach 99%) oprogramowanie opensource jest dużo uboższe w funkcjonalność niż komercyjne, więc takie porównanie jest nie na miejscu. Co do stabilności i łatania dziur: zamknięte sterowniki do grafiki pod linuksem są nadal o niebo stabilniejsze i lepsze od tych otwartych, KDE 4 ma stabilność wyraźnie gorszą od Windows 98 i od ponad roku nie może się z tego wygrzebać, MySQL to zabawka przy Oracle/DB2, podobnie GIMP zalicza mi częściej zwiechy i pady niż Adobe Photoshop. Ba, nawet takie trywialne rzeczy do napisania jak profilery, w przypadku OS / za darmo to żal w porównaniu z wersjami komercyjnymi.

Oprogramowania specjalistycznego (CAD, EDA) na poziomie praktycznie w ogóle nie ma.

Ale gdyby było na Hessianie to musiałbyś sobie sam przeportować tę bibliotekę na Delphi.

Ale BEZ ZMIENIANIA kodu źródłowego aplikacji korzystającej z owych guzików. Czyli w kodzie ma być dalej TButton. Bo jak się główny grafik w firmie zmieni i będą chcieli inny L&F, to żeby nie trzeba było przepisywać całego kodu. Da się w standardzie? Czy też zaraz wynajdziesz na to jakiś zewnętrzny komponent?

Z licytacją zewnętrznymi komponentami to sobie daj od razu spokój, bo tutaj Javy czy .NETa raczej Delphi nie przebije, ze względu na po prostu znacznie niższą popularność. A o popularność na razie nie ma czym zawalczyć. Ani ceną, ani przenośnością (napiszesz mi przenośny kod między Windows i Linksem? - w .NET lub Javie napiszę) ani możliwościami samego języka, ani narzędziami (pokaż mi coś darmowego do Delphi dorównującego Eclipse / Netbeans dla Javy). Nie wystarczy zresztą dorównać, trzeba prześcignąć konkurencje, żeby klienci zwrócili uwagę.

Kylix nie żyje.

Jeśli zależy Ci na łatwym znalezieniu pracy, to dobrym wyboremspośród języków ogólnego przeznaczenia jest nauczenie się C (nie C++) i Javy.

Dzień Dobry, zainteresował mnie ten wątek dlatego piszę.

Na wstępie - nie jestem super wyjadaczem C# ani Delphi. W obydwu tych językach mam doświadczenie, które pozwala mi pisać aplikacje i zarabiać na życie. Chciałbym się z Wami podzielić moim spojrzeniem na poruszoną tu sprawę C# i Delphi

Obydwa te języki składniowo są niezwykle do siebie podobne, bo są zaprojektowane przez tego samego człowieka. Obydwa te języki mają ogromne możliwości, które programista może wykorzystać do stworzenia w łatwy sposób wydajnej i estetycznej aplikacji. Wiele rozwiązań jakimi cieszymy się teraz w C# to “spuścizna” po Delphi, a wiele rozwiązań Delphi pierwotnie wzorowanych było na języku Smalltack. Obydwa te języki są językami nowoczesnymi i wspierającymi wszystkie nowoczesne i sprawdzone technologie.

W przeciwieństwie do Delphi, C# wspiera także różne najnowsze technologie Microsoftu. Ale nie podoba mi się to, że gdy programiści oswoją się już z jakąś technologią, MS ją porzuca nagle na rzecz innej, nowszej,lepszej. Dla mnie szokiem było wycofanie wsparcia (chodzi mi o rozwijanie technologii) dla WinForms na rzecz WPF. Dlatego język C# według mojej opinii gna za nowościami zamiast wciąż udoskonalać to co dobre.

Jest rzeczą logiczną, że jeśli wciąż tworzy się coś “nowego” a nie udoskonala się “starego” to stary kod jest zawsze zaniedbany i niedopracowany. Platformy .NET nie jest jednolita jeśli chodzi o solidność - to moja opinia. Z jednej strony mamy najlepsze, naprawdę najlepsze na świecie algorytmy, super zoptymalizowane w bibliotekach DLL - jakieś szyfrowania i takie tam (niektóre możliwości .NET są rewelacyjne, powtarzam REWELACYJNE) - i to się Microsoftowi chwali, że nie szczędził na tym pieniędzy :smiley:

A z drugiej strony mogę wiele zarzucić kontrolkom w Visual Studio (np. że są przebajerowane różnymi opcjami (ilość nie pokrywa się w ich przypadku z jakością, bardziej wolę VCL w Delphi i uważam komponenty Delphi za o wiele bardziej przemyślane od tych z VS)). Nie mówiąc już o tym, że nie uważam Visual Studio za świetne środowisko programistyczne, mam mu wiele do zarzucenia - przede wszystkim brak przejrzystości, którą lubię w IDE Delphi i brak kilku innych rzeczy, które są w Delphi. Ale środowisko programistyczne Delphi też nie jest środowiskiem świetnym, nie będę kłamał, brakuje mi w nim z kolei niektórych udogodnień z VS. Większą przyjemność mi sprawia praca w IDE Delphi. Żadne z nich nie jest lepsze od drugiego. Obydwa IDE są dobre :smiley: Ale nic więcej. Tak ja to odbieram.

Na szczęście powstała technologia Hydra, która pozwala korzystać w Delphi (od Delphi 2005 w górę) z dobrodziejstw .NET-owych technologii przy zachowaniu całej potęgi i możliwości języka Delphi. Tak więc w Delphi pod Win32 można osiągnąć więcej niż w C#, jeśli wykorzystamy przewagę kodu natywnego nad tym nie-natywnym i skorzystamy z możliwości platformy .NET. Co nie dowodzi oczywiście w żaden sposób wyższości jednego języka nad drugim.

Delphi to twardy zawodnik - chce stanowić z jednej strony konkurencje dla C# a z drugiej strony dla C++. Powiem szczerze, mnie to fascynuje. A skoro CodeGear wciąż jest na rynku, wciąż ludzie kupują produkty CodeGear, skoro można znaleźć oferty pracy w Delphi 2009 to znaczy, że język Delphi jest wciąż konkurencyjny :slight_smile: No i nie zapominajmy o rzeszy fanów (czasem fanatycznych) tego języka, dla których Delphi ma w sobie coś kultowego. “Ruch” ten stworzył Delphi dla Linux i MacOS - osadzone w IDE Lazarus-a - i choć nie jest to do końca ten język Delphi, który ma wsparcie ze strony CodeGear, to jednak jakiś funkcjonalny, działający dialekt tegoż języka na kompilatorze Free Pascal gdzieś ma swoje życie :slight_smile: No ale w biznesie nie liczy się czy język jest “kultowy”, nawet nie liczy się czy jest popularny, liczy się czy można zarobić programując w tym języku, a właściwie ile można zarobić. W końcu wciąż są fani Commodore C64, Atari, NES-a (Pegasusa), fani maluchów i syrenek. To jest piękne, ale nie liczy się w biznesie.

Mogę wiele zarzucić różnym technologiom Microsoftu, że są tworzone przez MS na zasadzie - a może się sprzeda, może ktoś kupi, może się spopularyzuje - a jak nie to trudno [-X Wiele takich rzeczy jest eksperymentalnie wprowadzanych do języka C#. Wiem np. że LINQ jest fajny, ale ile w % firm na serio skorzystało (i po jakim czasie) z tych “ficzerów” dodawanych do języka. W języku nie liczy się, żeby miał “ficzery”, w języku liczy się, żeby był stabilny. Żebyśmy, jak zaczniemy w nim tworzyć używając jakiejś technologii, nie otrzymali nagle od producenta kompilatora prztyczka w nos - oj sorry, ja już nie wspieram tej technologii, zainwestuj w nową, lepszą, oczywiście moją. Tak Microsoft traktuje swoich klientów [-X

Dlatego wybór Delphi jest wyborem kompilatora, choć trochę “zacofanego” w stosunku do najnowszych możliwości jakie się pojawiły, to jednak kompilatora stabilnego, pewnego. To pracodawcy cenią. Nie ma tu takich problemów, że firma napisała program pod .NET 1.0, zapłaciliśmy dużo za stworzenie naszej aplikacji, ale nagle się okazało, że nie mogę łatwo przerobić mojej aplikacji tak, by działała pod .NET 3.5 i używała WPF-a. I co? =D> Zostaliśmy w ciemnej d**** bo zaufaliśmy Microsoftowi. W Delphi nie ma takich problemów. Aplikację napisaną w Delphi 2.0 bez najmniejszego trudu skompiluje w Delphi 2009 i podepnę pod to WPF używając technologi Hydra jeszcze. I co? A jednak, firma wyjdzie na tym lepiej niż na .NET i VS.

Wybierając język wybieramy także politykę producenta kompilatora. CodeGear zostało teraz za ogromne pieniądze przejęte przez Embarcadero Technologies, a ta firma nie ma zamiaru powtórzyć grzechów Borlanda. To zacięci i twardzi ludzie, chcący zarobić. Odrobić najpierw to, co zainwestowali w Delphi, a potem wyciągnąć pierwsze zyski. Patrzcie jak ostro Delphi ruszyło w tym roku. Długo oczekiwane Delphi 2009 - rewelacyjne zresztą - Delphi Prism czyli język Delphi używający IDE Visual Studio pod platformę .NET, technologia Hydra - niesamowicie agresywne pokazanie światu - my jeszcze nie zrezygnowaliśmy, będzie konkurencja na rynku kompilatorów, nie martwcie się biedni programiści, nie zostawimy Was na pastwę jednego producenta, nie będzie monopolu! :slight_smile:

Język Delphi jest językiem dobrym. C# też. Każdy z tych języków ma jednak swoje lepsze i gorsze cechy w stosunku do drugiego. I kłamstwem by było mówić coś innego :^o

Hmm… Masz jakiś pomysł, co jeszcze można dodać do WinForms?

A konkrety?

To już raczej kwestia gustu i przyzwyczajenia :slight_smile:

Wydaje mi się, że wiele wynalazków w historii ludzkości powstało w ten sposób, że ktoś coś kombinował i przypadkiem okazywało się, że jest to coś przydatnego. Chyba wszystkie firmy z wszystkich branż mają swoje laboratoria, w których próbują coś odkryć, i pewno mniejsza część z tych eksperymentów kończy się powodzeniem. Koniec dygresji :slight_smile:

Uważam jednak, że nie masz w tym momencie racji. Najczęściej to, co M$ wprowadza poprzedzane jest wersjami CTP, Beta, itd., powstaje w odpowiedzi na jakieś zapotrzebowanie rynku, jest konsultowane z ludźmi, którzy będą z tego korzystać. Raczej nie mogliby sobie pozwolić na zbyt wiele nieudanych eksperymentów, to korporacja, nie laboratorium.

To nie są “ficzery”, to jest pewien rozwój. Co w nim złego?

LINQ jest bardzo przydatnym narzędziem, można się nastawić na to, CO chcemy zrobić, a nie JAK. Zdecydowanie mniej pisania przy wywołaniu jednej metody, która coś robi, zamiast własnej jej implementacji. To pozwala zaoszczędzić czas, więc także i pieniądze - generalnie na tym rozwój polega.

A ja myślałem, że to, aby umożliwiał i ułatwiał tworzenie oprogramowania.

Zaś wszystkie nowe rzeczy dodawane do .NET są długo i mocno testowane, o stabilność bym się nie obawiał.

Faktycznie (bardzo stare) wersje 1.0 i 1.1 są niekompatybilne z wersjami od 2.0 wzwyż. Dlatego, jeśli korzystamy z programów w nich napisanych trzeba mieć zainstalowany stary Framework. Niemniej jednak nie sądzę, żeby coś nie dawało się skompilować, problemy mogą być przy próbie kompilowania nowego kodu pod stary Framework, ale to nic dziwnego.

Jeśli ktoś zrobił aplikację tak, że nie da jej się przerobić do nowej wersji, to niestety, ale jest ona źle zaprojektowana i wykonana. Faktycznie łatwo winić Microsoft za indolencję autora :slight_smile:

A co do pracy… Programiści Delphi są potrzebni głównie do utrzymywania starych systemów. Nowe raczej już nie powstają. Oferty pracy dla programistów Delphi to kilka procent wszystkich. Jakoś nie widzę, żeby się mocno trzymało.

Naprawdę trzeba być wyjątkowym fanboyem tego języka, żeby nie zauważać, że jego udział w rynku jest marginalny.

Tu nie chodzi o to co by można dodać nowego, tylko o to by rozwijać starą technologię, udoskonalać. Na tym polega wsparcie. Można bardzo wiele rzeczy zrobić. Poprawiać starą funkcjonalność, przyspieszyć wydajność niektórych komponentów (np.DataGridView). Można by zwiększyć możliwości kontrolek. Np. ComboBox musi mieć kolor elementu zaznaczonego ten sam, systemowy - zawsze. Dlaczego nie mam standardowo mieć możliwości zmiany tego koloru? To jest niedopracowanie. Owszem, ktoś może powiedzieć - można obejść się bez tego. Ale co mnie to obchodzi, że można obejść się bez tego, albo napisać własną kontrolkę. Można obejść się bez prądu i bez komputera. Ja płacę ciężkie pieniądze za produkt, mam prawo żądać jakości.

Uważam, że niektóre kontrolki są źle zaprojektowane. Dlaczego mam 3 różne property odpowiedzialne za tą samą funkcjonalność? Wezmę pierwszy, lepszy przykład z brzegu:

Kontrolka: Button.

Funkcjonalność: Tło kontrolki Button.

Opis:

W trzech różnych miejscach w klasie kontrolki jest: BackgroundImage, Image, ImageList. Plus do tego dochodzi teraz bałagan z właściwościami każdego tła:

BackgroundImageLayout, ImageAlign… I robi się nam sieczka w oknie Properties. Po prostu wstyd i żal :cry: dla kogoś kto tą kontrolkę zaprojektował. Po co tyle różności dla jednej funkcjonalności? Jak używam BackgroundImage to nie używam Image, jak używam Image to nie używam ImageList. To mogło być jedno property, tylko dobrze skonstruowane. Jedna właściwość dla jednej funkcjonalności.

Drugi przykład: RichTextBox w Visual Studio. Wygoda użycia tego komponentu jest o wiele, wiele mniejsza niż w przypadku TRichTextBox w Delphi. Dla mnie już straszliwą zbrodnią jest nieistnienie metody takiej jak vRichTextBox.Lines.Add(“Moja linijka”). Czytanie, pisanie w RichTextBox nie jest dla mnie czymś intuicyjnym, w przeciwieństwie do odpowiednika tej kontrolki w Delphi.

Nie oszukujmy się. Wszystko wymaga czasu. Kontrolki Delphi są na rynku 14 lat. Są dopracowane, bo był czas na to, były na to pieniądze. Visual Studio było pisane szybko i kontrolki VS też były pisane na szybko - byleby sprzedać tylko produkt jak najszybciej. Nie mogą być tak dopracowane jak w Delphi. Nie mogą być tak przetestowane. I jest ich zdecydowanie mniej. Dlatego twórcy Visual Studio, zapewne zdając sobie z tego sprawę, chcieli wynagrodzić programistom ten fakt duża ilością różnego rodzaju bajerów w tych kontrolkach, co im - moim zdaniem - średnio wyszło.

A teraz trochę filozofii… :slight_smile: MS wycofał wsparcie dla WinForms? Więc nikt nie będzie już za bardzo zajawiał się na pisanie kontrolek dla Visual Studio pod WinForms, bo po co - skoro MS promuje tylko WPF. W Delphi jest w Internecie mnóstwo fajnych kontrolek, przez lata, długie lata pisanych przez zajawkowiczów i amatorów, doświadczonych programistów, oraz profesjonalne firmy. Delphi całe lata żyło duchem tworzenia własnych kontrolek… Kontrolki w Delphi “się liczą”. Bo zwykły człowiek chce się cieszyć życiem, fascynować tym co robi. I wtedy wybiera Delphi bo jest właśnie fajne. W programowaniu chodzi o coś więcej niż o zarabianie pieniędzy… Wznieśmy się na wyższy poziom abstrakcji. Pomyślmy, że język programowania powinien być czymś więcej niż bezduszna technologia. Język programowania musi mieć duszę, być tworzony z pasją… A kontrolki w Visual Studio, to tylko… kontrolki - bez żadnej filozofii. Wiem, że zamiast WinForms można wciąż tworzyć kontrolki WPF, ale wątpię, że kiedykolwiek stanie się to tak popularne jak było w Delphi. Zresztą po co się zajawiać na kontrolki WPF, skoro nieprzewidywalny MS może nagle powiedzieć - teraz stworzyłem coś lepszego niż WPF - porzućcie tworzenie kontrolek WPF, jak porzuciliście tworzenie kontrolek WinForms. To było takie moje małe przemyślenie, bez większych konkretów.

Takim eksperymentem jest Windows Vista i był nim Windows Millenium. Dlaczego BSD jest świetnym systemem dla administratorów? Bo został setki, tysiące razy przetestowany. Nie jest eksperymentem jak Vista. Ma ponad 20 lat. O nim można powiedzieć, że jest dobrze przetestowany. Na testy trzeba czasu. Dużo czasu. Jeśli chodzi o programowanie, nie wierzę, że Microsoft przetestował dokładnie cały .NET. Wierzenie w to graniczy wręcz z naiwnością. Najnowszy Silverlight na pewno nie został dokładnie przetestowany. A jak przetestować LINQ-a? Czy WCF został dokładnie przetestowany? Wątpię - .NET dopiero teraz jest naprawdę testowany. Ludzie, którzy stworzyli PEX-a (Microsoft) testują nim teraz .NET, ale zaczynając od samych podstaw. Od roku testuje się wciąż stary framework 2.0. Jest takie narzędzie jak CHESS (Microsoft), które znajduje błędy w działaniu aplikacji wielowątkowych. Za pomocą tego narzędzia były testowane biblioteki .NET okazało się, że w .NET 2.0 były błędy, mimo że framework 2.0 już tak długo był testowany przez CTP i był pisany z użyciem testów jednostkowych #-o Natomiast testy beta w przypadku Microsoft to plaster na ranę. Wiele narzędzi MS, które są w sprzedaży, powinny być jedną wielką betą.

Była konferencja społeczności .NET w Krakowie, licząca ponad 150 osób. Był na niej pan Tomasz Kopacz (http://www.tomaszkopacz.com/author/tkopacz.aspx),który jest znaczącą osobą w firmie Microsoft w Polsce. Na pytanie ile osób regularnie korzysta z LINQ, ze 150 zgłosiło się 5-7 osób. Jeśli pracownicy w firmie poświęcą tydzień na nauczenie się LINQ-a pochłonie to duże koszty na szkolenie (w którym pracownik nic dla firmy nie będzie robił). Teraz, żeby być dobrym w LINQ-u trzeba też nabyć doświadczenia. Bo choć LINQ jest świetną rzeczą, należy umieć go stosować. Czas, wydajność,czas… Czy to się firmie opłaca? Co zyskam stosując LINQ? Zyskam bezpieczeństwo - nie będzie SQL injection, składnia pobierania danych jest unormowana - nie trzeba być specjalistą od XML-a, baz danych - wystarczy dobrze znać LINQ i mam wszystkie dane jakie są mi potrzebne uzyskane w jeden prosty sposób. Operuje wciąż na kodzie C# (Delphi Prism, Visual Basic) - a nie piszę zapytań w osobnym języku SQL. Tylko, czy zysk z zastosowania LINQ-a jest większy, lub adekwatny do kosztów włożonych w wyszkolenie pracowników w tą technologię?

Po pierwsze dla mnie to jest dziwne, bo w Delphi pod Win32 nie ma takich problemów :stuck_out_tongue: Źle zaprojektowany i wykonany jest Framework 1.0 i 1.1. Nie jest też prawdą, że każdą aplikację, nawet dobrze zaprojektowaną da się bez problemu przenieść do Framework-a wyżej. Nawet mogą być problemy z przeniesieniem się z 2.0 do 3.5, a co dopiero z 1.0. Znam projekty w dużych firmach pisane w .NET 1.1, których nie da się przenieść do .NET 2.0. Programiści pracujący w tej starej technologii załamują ręce, a ich pracodawcy raczą ich dużymi pieniążkami, żeby przypadkiem nie odeszli od systemu… Konkretnych przykładów z wiadomych względów podawał nie będę.

Nie zgadzam się z tą opinią. Powstają nowe systemy, nawet w Delphi 2009. Słowo “raczej” jest mało konkretne

Nie powiedziałbym tak. Matlab ma 4 razy mniejszy udział w rynku, a nikt rozsądny nie powie o tym potężnym języku programowania, że Matlab jest językiem marginalnym. A udział Delphi w rynku jest po prostu 10 razy mniejszy niż udział Javy.

BorysBe , niema co dyskutować na ten temat z somekind em. Dyskusją na temat wyższości Delphi nad C# wg mnie została w tym wątku jednoznacznie rozstrzygnięta. somekind , próbował udowodnić że można w C# powtórzyć to co da się zrobić w Delphi - minął prawie miesiąc a on nie potrafił powtórzyć w C# tego co w Delphi zrobiłem w dwie godziny. A wg logiki a la somekind , skoro nie udało się udowodnić że C# jest tak samo dobry jak Delphi to jednoznacznie udowodniono że C# jest gorszy od Delphi. :lol:

BorysBe , zauważ pewne zjawisko, w tym wątku udzieliło się trzech bezwarunkowych zwolenników C# z których:

  • [*:1b1v71bg]jeden nie zna się na logice - wielokrotnie to udowodnił na tym forum;[*:1b1v71bg]z drugim też coś nie tak bo nie odróżnia problemu udowodnienia że niema największej liczby pierwszej od problemu nie istnienia Boga;[*:1b1v71bg]trzeci to zupełnie majaczy.

Więc wśród bezwarunkowych zwolenników C# mamy tu 100% powiedzmy - “umysłowo sprawnych inaczej”, daje to do myślenia mimo że 3 nie jest “liczbą statystyczną”.

:lol:

Może już bardziej się po prostu nie da? Zresztą na wydajność DGV ktoś narzeka? Chyba tylko tacy, którzy nie potrafią używać VirtualMode :slight_smile:

No tu może masz trochę racji. Z drugiej strony kontrolki standardowe właśnie takie są - standardowe. Raczej ciężko Microsoftowi przewidzieć czego akurat jakiś programista będzie potrzebował i zrobienie nieskończonej liczby kontrolek, żeby każdy mógł sobie bezboleśnie tworzyć programy bez ingerencji w kod :slight_smile:

Programowanie, niestety, polega na tym, że czasem trzeba napisać coś samemu, nie wystarczy przeciągnąć komponent z toolboxa w RAD od Delphi.

I nie trzeba pisać własnej kontrolki, wystarczy zmienić DrawMode na OwnerDrawVariable i obsłużyć zdarzenie DrawItem:

private void comboBox1_DrawItem(object sender, DrawItemEventArgs e)

{

    e.DrawBackground();

    e.Graphics.DrawString(this.comboBox1.Items[e.Index].ToString(), e.Font, new SolidBrush(e.ForeColor), new Point(e.Bounds.X, e.Bounds.Y));

    if (e.State == (DrawItemState.NoAccelerator | DrawItemState.NoFocusRect | DrawItemState.Selected))

    {

        e.Graphics.FillRectangle(Brushes.Red, e.Bounds);

        e.Graphics.DrawString(this.comboBox1.Items[e.Index].ToString(), e.Font, Brushes.White, new Point(e.Bounds.X, e.Bounds.Y));

    }

}

Nigdy wcześniej tego nie robiłem i nie wiedziałem, jak się robi. Znalezienie przykładu za pomocą Google i wykonanie zajęło mi z 3 minuty.

■■■? :expressionless:

Przecież to są trzy różne rzeczy i trzy różne funkcjonalności.

BackgroundImage używamy, gdy chcemy ustawić tło dla przycisku.

Image, gdy umieścić w nim jakiś obrazek.

ImageList, gdy chcemy przypisać jej kilka obrazków, które będziemy zmieniać w trakcie działania aplikacji.

Stąd też inne są sposoby wyświetlania BackgroundImage i Image. ImageList też można by zastąpić własną listą Image, tylko po co, skoro tak jest wygodniej?

Ty może nie używasz BackgroundImage i Image jednocześnie, ale zdaj sobie sprawę, że są tacy, którzy używają. Bo chcą mieć na przycisku jednocześnie tło i ikonę symbolizującą jego przeznaczenie. Naprawdę nie trzeba doktoratu, żeby rozumieć odmienność tych funkcjonalności.

Nie rozumiem Cię - najpierw narzekasz, że źle, bo nie można w ComboBoxie standardowo zmienić koloru tła, a w Buttonie przeszkadzają Ci trzy różne właściwości, których jedyną wspólną cechą jest to, że dotyczą grafiki? Jak nie ma, to źle, jak jest, to jeszcze gorzej. To kiedy jest dobrze?

Hmmm… Wystarczy zajrzeć do dokumentacji: http://msdn.microsoft.com/en-us/library/system.windows.forms.textboxbase.appendtext.aspx

To też raczej kwestia Twojego przyzwyczajenia - jak dla mnie to jest bardzo intuicyjne. Można operować w całym tekście, jak i każdą linijką oddzielnie. Jest masa metod i właściwości umożliwiających zbudowanie na bazie tej kontrolki edytora tekstowego lepszego niż WordPad w 10 minut :slight_smile:

Miałem spytać już poprzednio, ale darowałem… Dlaczego nie odróżniasz .NET od Visual Studio? A .NET od C#?

Bo Ty tak uważasz? Czy jesteś w stanie to poprzeć czymś więcej, niż ślepą wiarą we wspaniałość Delphi?

Problem w tym, że WinForms nadal jest bardzo popularne, prawdopodobnie nadal większość oprogramowania powstaje pod WinForms (niewiele jest raczej firm, które przesiadły się na WPF). Nadal są tworzone kontrolki, dla istniejących nadal jest wsparcie - zarówno produkty komercyjne, jak np. Devexpress, jak i masa hobbystycznych do znalezienia na SourceForge czy CodeProject.

WinForms jest i będzie, o jego popularności decydują użytkownicy, nie producent, a Ty po prostu piszesz głupoty.

Tak, bo w internecie nie ma mnóstwa fajnych kontrolek dla .NET… :shock:

To ja chyba nie jestem zwykłym człowiekiem :smiley:

Wybiera Delphi bo jest zacofane o kilka ładnych lat w porównaniu z innymi technologiami, wielu rzeczy nie ma standardowo, więc trzeba korzystać z dziwnych rzeczy znalezionych w internecie, które nie wiadomo jak będą działały później? Fakt - masochiści cieszą się tym, co robią :smiley:

Przeczytaj wątek od początku, w Delphi długo brakowało albo nadal brakuje wielu potrzebnych rzeczy.

I nie rozumiem czemu piszesz tylko o kontrolkach - masz świadomość, że tworzenie UI to tylko mała część programowania? Że oprócz designera są jeszcze pliki z kodem?

No, a co to ma być? Pralka bąbelkowa?

Można, ale nie trzeba. Nikt nikogo nie zmusza. Microsoft nigdzie nie stwierdził, że za rok wszystkie programy w WinForms przestaną działać, bo oni tak chcą.

WPF jest pewnym nowym rozwiązaniem. Ułatwieniem tworzenia interfejsu użytkownika, bo można wszystko bardzo ładnie deklaratywnie opisać w XAMLu - nie tylko wygląd kontrolek, ale i ich zachowanie, animacje, itp. Ponadto dzięki programom narzędziowym tworzeniem interfejsu mogą się teraz zająć bardziej np. graficy niż programiści.

Jest to pewna nowość, pozwala coś osiągnąć, kto będzie z tego chciał korzystać, to będzie korzystał. Naprawdę nie musisz dorabiać tu zbędnych teorii :expressionless:

Nie wiem, czy to jest dobre forum do dyskusji o sprawach wiary, w internecie są fora różnych religii - może tam spróbuj.

Albo się skupiamy na faktach, albo na swoich wierzeniach. Jeśli wiesz o czymś, co nie zostało przetestowane albo co nie działa, a powinno, to napisz po prostu.

Normalnie? Nie rozumiem w czym masz problem.

Ja nauczyłem się skorzystać z LINQ i LINQ to SQL w ciągu mniej więcej godziny, w stopniu pozwalającym na wykorzystanie go w działającej aplikacji.

Wystarczy przeciąć tabele z bazy do designera, automatycznie zostaną wygenerowane klasy - odpowiedniki encji, które “same” same będą potrafiły się do bazy zapisać, odczytać, usunąć, itp. Na pewno jest to szybsze, niż użycie ADO.NET, czy też klepania ich samemu.

Natomiast liczba operacji na kolekcjach, które LINQ pozwala wykonać jest moim zdaniem imponująca. Naprawdę można zaoszczędzić dużo czasu na pisaniu rozmaitych pętli. Przykłady podawałem już w tym wątku, mogę podać więcej, jeśli chcesz.

No jeśli kod napisany w najnowszej wersji Delphi przy wykorzystaniu wszystkich jego możliwości daje się bez problemu skompilować w najstarszej wersji Delphi, to znaczy tylko jedno - Delphi się nie rozwija w ogóle, zarówno pod względem składniowym, jak i bibliotek. Tak faktycznie jest?

Czy ja wiem - większość rzeczy z niego została, po prostu trzeba go oddzielnie zainstalować, jeśli chce się używać archaicznych programów - to wszystko :slight_smile:

Można prosić o konkrety? Co może być nie tak? Zniknęły jakieś klasy, metody czy co?

Bezsensowne porównanie. Matlab jest językiem bardzo specjalistycznym, nie można go porównywać do języków służących do tworzenia aplikacji różnego rodzaju.

Bo jest zacofane, brak w nim wielu rzeczy, nie ma wsparcia i nikt rozsądny nie chce go już używać, czy to może spisek kosmitów albo starożytnych Egipcjan?

Nie chodzi tylko DGV. Naiwnym jest twierdzenie, że nie da się poprawiać wydajności i funkcjonalności kodu, który już powstał. Windows 98 też nie dało się poprawić… Visual Studio też się nie da… tak? Skąd takie bezkrytyczne uznanie dla Microsoftu i jego produktów? Strasznie niedojrzałe wydaje mi się Twoje myślenie. Moim zdaniem, fanatycznie bronisz C# i platformy .NET. Ja też lubię C# i popieram istnienie platformy .NET, wyobraź sobie, ale uważam, że na wszystko trzeba patrzeć z dystansem a nie krzyczeć: “moje, moje, jak moje to najlepsze”. Nie ma najlepszych języków programowania. Każdy ma swoje zalety i wady. Nawet “Twój” C#. I “moje” Delphi również. I “jego” C++ także. I “ich” Java też.

co nie zmienia faktu, że ja muszę pisać coś oczywistego. Na ten pomysł powinien wpaść twórca tejże kontrolki. Po tylu latach…

Proszę, nie traktuj mnie jak swojego wroga i nie odpisuj mi na post w stylu: “Ty mi coś napisałeś, to ja coś napiszę Tobie żeby nie być gorszy”. Jestem takim samym człowiekiem jak Ty, mam swoje marzenia, pasje, upodobania, rozwiązania w których widzę piękno. Jeśli widzę, że coś jest napisane w sposób nieprzemyślany to mówię o tym otwarcie, nie po to, żeby coś zgnoić, tylko by ktoś się nad tym zastanowił a ktoś inny coś poprawił. To jest walka o dobro nas wszystkich. Ja używam VS i Ty też go używasz. Chcemy by produkt, za który płacimy był jak najlepszy. Mnie załamuje jak strasznie zasobożerne jest Visual Studio 2010. Załamuje mnie jak widzę, że jednym z niewielu dobrych produktów dostarczanym wraz z Vistą jest Direct X10. Mogę przyznać - to jest świetne, to jest świetne, a to doskonałe wręcz, ale będę narzekał jeśli coś jest złe… Bo jako odbiorca tych produktów mam do tego prawo. Przecież gdyby nikt nie zgłaszał swoich zastrzeżeń i uwag to wciąż tkwilibyśmy w epoce Windows 95, a programowalibyśmy w Assemblerze. Poprzez narzekanie na technologię sprawiamy, że technologia postępuje. Chwaląc twórców natomiast motywujemy ich do dalszej pracy. Jedno i drugie jest potrzebne.

Boże, ale naiwnie wierzysz w tą kontrolkę. Dystans, dystans… Myślisz, że nie wiem do czego służy BackgroundImage, Image i ImageList? Otóż wiem. Służy do tego samego :twisted: Do umieszczenia obrazka na przycisku. Tylko za każdym razem w inny sposób. Skoro służy do tego samego to czemu używa różnych properties?

Wniosek który wyciągnąłeś z moich wypowiedzi jest nieprawdziwy. Proszę, czytaj ze zrozumieniem.

Co ma do tego Delphi? Nie uważam, że Delphi jest wspaniałe. A moje rozumowanie wynika z prostej logiki, że żeby coś było dobrze przetestowane, musi przejść wiele testów, a wiele testów długo trwa. BTW: niektóre komponenty Delphi też są mocno niedopracowane.

Z całym szacunkiem, ale nie napisałem, że WinForms-a nie ma i nie będzie. Napisałem, że producent wycofał dla niego wsparcie.

Jest dużo fajnych kontrolek. Tylko w poprzedniej mojej wypowiedzi chciałem zauważyć, że w czasach gdy powstało Delphi, pisanie kontrolek było czymś niezwykłym, nowym, niesamowitym. Kontrolki były czymś więcej niż kontrolkami. Miały w sobie magiczną siłę przyciągania. Gdy powstało Visual Studio kontrolki nie były już niczym nowym, kultowym. To było powielanie starych, sprawdzonych schematów. Sam widzisz, że podchodzisz do tego bez emocji. To na zasadzie filmów. Pierwszy film jest świetny, nowy, rewolucyjny jest, mega hit. Później ktoś nakręca film powielający stare schematy i ten film ma to samo co ten pierwszy, ale nie jest niczym nowym, zachwycającym. Jest Diablo i są Diablo-podobne gry. To pierwsze jest jedyne w swoim rodzaju, te następne są mniej, lub bardziej udanymi klonami. Klon to klon.

Po prostu napisałem Ci wcześniej :slight_smile:

Bawisz się słowami: “kilka ładnych lat”, “wiele rzeczy”. To nie jest prawda. Kilku rzeczy brakuje w Delphi, ale nie sądzę, że Ty akurat wiesz co piszesz. Używałeś w ogóle tego środowiska, pisałeś coś w języku Delphi? A być może wypowiadasz się o czymś o czym nie masz większego pojęcia ? Jeśli tak, to nie świadczy to najlepiej o Twoich kompetencjach. Nie wszystko czego nie znasz jest złe, brudne i zacofane :slight_smile:

Nie, tak nie jest:) Nie zrozumiałeś co napisałem, być może pod wpływem emocji jakie wzbudził w Tobie mój post. W najnowszym Delphi daje się skompilować bez najmniejszych problemów kod napisany w najstarszym Delphi i wzbogacić go o najnowsze możliwości języka. To jest wsteczna kompatybilność. To jest duża zaleta produktów CodeGear. Ta solidność jest wizytówką firmy. Dlatego, pomimo wcześniejszej -nie oszukujmy się - beznadziejnie żałosnej polityki marketingowej Borlanda, Delphi jest wciąż na rynku i wciąż jest kupowane. Spytaj się innych fachowców,powiedzą Ci to samo.

BTW, kiedyś nawiązałem długą korespondencję z firmą CodeGear i poinformowano mnie:

Mamy wielu klientów którzy wrócili do Delphi bo uznali że ich praca z WinForms poszła na marne - napisane aplikacje będą pielęgnować, lecz nowe projekty rozpoczynają w Delphi.

Matlab też jest językiem, który ma wiele, naprawdę wiele zastosowań. Tworzone są w nim aplikacje różnego rodzaju. Nie wiesz o tym?

Kończąc ten post chciałbym zaznaczyć, że niepotrzebnie się tak emocjonujesz. Skoro Delphi jest i ludzie go kupują, to znaczy, że jest konkurencyjne i ktoś go jednak chce używać. A ktoś na nim zarabia i jest bardzo zadowolony. Jeśli Matlab ma o wiele, wiele mniejszy udział na rynku a firma dobrze prosperuje, to pomyśl jaki zysk Delphi przynosi jego twórcom. Prawa rynku są dla mnie najlepszą argumentacją. Nie wiem, co tu do rzeczy mają starożytni Egipcjanie, albo kosmici. Powtórzę również to, co napisałem na początku - nie jestem Twoim wrogiem, nie będę się z Tobą kłócił tylko po to, żeby się kłócić. C# i Delphi są moimi ulubionymi językami, zaprojektowała je ta sama osoba. W jednym i drugim języku jest ten sam duch Andersa Hejlsberga.

Zauważ, że ja nie stwierdziłem, że się nie da, tylko spytałem :slight_smile: Być może M$ uważa, że już nie mają co tam zrobić, więc to zostawiają. Cztery lata temu uznali produkt za gotowy i go zostawili - widocznie stwierdzono, że te kontrolki standardowe są wystarczające. Może to źle i sami sobie wbili nóż w plecy - czas pokaże :slight_smile:

Chociaż od tamtej pory parę rzeczy się pojawiło, np. Chart Controls.

Dokładnie :slight_smile: Więc wyjaśnij to temu geniuszowi, który pisze, że “.NET to syf” :slight_smile:

Ja nie napisałem nigdzie, że C# i .NET są najlepsze na świecie, zawsze pisałem w odniesieniu do zastosowań.

Sądzę, że jeśli chodzi o tworzenie aplikacji dla Windows, to .NET jest najlepszym obecnie rozwiązaniem, jeśli chcemy je robić łatwo, szybko, przyjemnie i wygodnie. Jeśli będziemy potrzebowali wieloplatformowości, to lepsza będzie pewno Java, jeśli jakiejś niezwykłej wydajności możliwej do osiągnięcia tylko w kodzie niezarządzanym, to pewno C++.

Ale raczej nie Delphi, które jest dość zacofane w porównaniu z resztą, co zostało w tym wątku już wielokrotnie opisane. I to są fakty, a nie moje preferencje :slight_smile:

Co do mojej bezkrytyczności… W C# czasem wkurzający jest brak argumentów domyślnych w metodach, do tego trochę niemądrze zaprojektowane typy wartościowe - nie da się łatwo napisać generycznych metod pozwalających na wykonywanie na nich działań arytmetycznych - czasem to przeszkadza :/. Ale w C# 4.0 będzie to prawdopodobnie poprawione. Do tego serializacja XML niekiedy jest ułomna - np. nie da się standardowo serializować słowników generycznych ani też kolekcji zawierających obiekty klas potomnych. Np. do tego można się przyczepić, jeśli chce się konstruktywnie krytykować .NET.

No i najlepsze - w Visual Studio, nie da się napisać “Ć” przy użyciu standardowej kombinacji klawiszy :stuck_out_tongue_winking_eye:

U mnie beta bez problemu chodzi na maszynie wirtualnej z 512MB RAMu. Ale nie bawiłem się jeszcze nim za bardzo. Trzeba jednak brać poprawkę na to, że to jest beta. Nie wiem też, co tam nowego dodali, bo na pierwszy rzut oka oprócz przyjemniejszego interfejsu nic nie zauważyłem.

Zresztą, 2008 tez potrafi być zasobożerne, jeśli np. ma się otwarty ClassDesigner i do tego kilka plików z klasami.

Wiesz - mi tam Vista w całości bardzo przypasowała i nigdy nie miałem z nią większych problemów. Mam jednak nadzieję, że Windows 7 będzie jeszcze lepszy :slight_smile:

Ja nie wierzę w kontrolki. Dla mnie są to rzeczy, które można pojąć rozumem, więc wiara jest w tym przypadku niepotrzebna.

Nie myślę, że Ty nie wiesz - tylko nie wiesz, co potwierdzasz swoimi słowami. Jeśli dla Ciebie obrazek na przycisku i obrazek będący jego tłem to to samo, w momencie, gdy chcemy używać obydwu, to nie mam więcej pytań.

Doprawdy? To garść cytatów:

Nie ma czegoś takiego jak kontrolki/komponenty VS. VS to tylko IDE. To, co nazywasz kontrolkami, to klasy z przestrzeni nazw System.Windows.Forms platformy .NET.

Podobnie LINQ nie jest częścią C#, tylko .NET.

Należy rozgraniczać C#, .NET i Visual Studio, jeśli chce się prowadzić merytoryczną dyskusję.

A możesz podać źródło tych informacji? ;>

Naprawdę jest wiele rzeczy, do których można podchodzić emocjonalnie, chociażby wspomniane przez Ciebie filmy, żeby nie musieć tak podchodzić do klas, z których składa się aplikacje okienkowe. Ale co kto lubi :slight_smile: W każdym razie, moim zdaniem podniecanie się kontrolkami nie jest czymś fajnym, nie znam też nikogo z takim podejściem jak Twoje.

Swoją wiedzę czerpię z internetu, oraz od ludzi, którzy np. kiedyś tworzyli w Delphi, a potem je porzucili, bo okazało się, że stoi w miejscu, gdy reszta poszła do przodu.

Kiedy wprowadzono typu generyczne, a od kiedy były dostępne w innych językach programowania? ;> A LINQ jest? A nawiasy klamrowe? (tak, wiem, to poniżej pasa :P)

Generalnie o wszystko, o co ja czy inni pytaliśmy w tym wątku, czy da się zrobić w Delphi, to okazywało się, że albo w ograniczony sposób, albo stosując jakieś dziwne obejścia, typu niestandardowe komponenty ściągane z netu. Nieprawda?

Za to Ty w .NET akceptujesz tylko to, co znasz z Delphi, bo gdy czegoś Ci brakuje, to jest źle, gdy czegoś jest więcej, to jeszcze gorzej, a gdy coś nazywa się inaczej, to w ogóle poruta, bo do dokumentacji nie łaska zajrzeć - to wynika z Twoich postów.

Nie no, zaraz, to Ty szukasz tu emocji w kontrolkach formularzy i innych dziwnych rzeczach. Mnie wszystkie posty na wszystkich forach ani ziębią, ani grzeją, bez względu na ich pochodzenie. Co najwyżej mogą wywołać uśmiech politowania albo wybuch śmiechu, jeśli są naprawdę wybitne :slight_smile:

A w VS się nie da? Bo do tej pory bez problemu konwertowałem projekty z VS 2003 i Frameworka 1.1 do VS 2005 i .NET 2.0, z tego zaś na VS 2008 i .NET 3.5. Zawsze z powodzeniem…

Jesteś w stanie pokazać mi taki kod, który po tej operacji nie zadziała? Bo widzisz - ja nie biorę rzeczy na wiarę, ja potrzebuję faktów i dowodów.

No właśnie już pytałem :slight_smile:

Różnego rodzaju aplikacje służące do obliczeń i symulacji, tak?

Bo jeśli znasz np. program użytkowy, narzędziowy, graficzny, bazodanowy czy aplikację webową napisaną w Matlabie, to podziel się linkiem.

Najpierw autor Delphi je porzuca i odchodzi do konkurencji, gdzie zajmuje się tworzeniem C#.

Potem producent wydziela z siebie spółkę-córkę, która ma się zajmować rozwojem Delphi, a następnie sprzedaje ją innej firmie. Sprzedaje za niewielką sumę - 23 mln $ w tym biznesie to nie jest imponująca kwota. M$ pewno mógłby sobie kupić takich Delphi pięć dziennie :wink:

Prawa rynku - wg. TIOBE Delphi ma nieco ponad 2% rynku. W 2005 roku miało nawet niecałe 6, ale spadło i od pewnego czasu jest mniej więcej stabilne. Kilka innych języków ma ten udział znacznie większy.

Dlaczego tak?

Odpalmy sobie jakiś portal z ogłoszeniami o pracę. Oferty rozkładają się tak:

C++ - 44

Java - 70

.NET - 26

Delphi - 7

Dlaczego tak?

Ja nie jestem wrogiem Delphi, mi ono zwisa. Tylko niech ktoś wyjaśni, czemu nie jest popularne, mimo swojej wspaniałości? :slight_smile:

Cieszę się, że ta dyskusja nabrała jakiegoś sensu i ogłady.

Co to konkretnie znaczy “dość”? Znaczy pytam, bo nie wiem o które technologie Ci chodzi. Tylko nie pisz mi o takich oczywistościach jak WPF, którego zresztą nie ma np. w języku Java [nie chodziło Ci o to, że Delphi jest zacofane bo nie ma wsparcia dla najnowszych technologii w Microsoft .NET Framework (Delphi pod Win32 samo w sobie nie ma tego wsparcia, owszem), tylko chodziło Ci o to, że jest zacofane w stosunku do “reszty” - innych języków programowania - ja niestety nie mogę się zgodzić z tą opinią - uważam, że jest nieprawdziwa i nieobiektywna]

Jasne, tylko że nikt rozsądny nie pisze tak kodu. Kod powinien być jak najbardziej prosty i przejrzysty. Po co komplikować tak proste rzeczy jak wyświetlenie obrazka na przycisku? :stuck_out_tongue:

Uważam nawet, że powinno się podchodzić emocjonalnie do jak największej ilości rzeczy (pod warunkiem, że są to pozytywne emocje, oczywiście) :slight_smile: Przecież gdyby człowiek nie wkładał serca w to co robi, to świat byłby szary, nudny i zacofany.

Przepraszam, jeśli wyrażam się dla Ciebie nie precyzyjnie. Mój błąd. Ale używasz czasem skrótów myślowych? Kontrolki/komponenty VS to graficzne zobrazowanie klasy z przestrzeni nazw System.Windows.Forms platformy .NET dostępne z poziomu Visual Studio… ale nie tylko. Jak napiszesz własną kontrolkę i umieścisz ją na palecie komponentów Visual Studio, to nie pochodzi ona całkowicie z System.Windows.Forms - dlatego określenie kontrolki Visual Studio, moim zdaniem, lepiej oddaje obraz sytuacji. LINQ jest częścią .NET, ale automatycznie staje się częścią języka C#, Delphi Prism i wszystkich innych języków, które w pełni wspierają .NET 3.5. Przecież w swoim listingu C# piszesz zapytanie LINQ i jakoś nie odgraniczasz go od reszty kodu.

Ale postaram się być bardziej precyzyjny, nie chcę Cię irytować.

Może nie jak nazywa się inaczej, tylko jak działa inaczej niż uważam to za najprostsze i najlogiczniejsze. Ma mi prawo nie pasować, jestem wolnym człowiekiem. Przy okazji, nie porównuj platformy .NET z językiem Delphi, bo to dwie różne rzeczy :twisted:

Wiesz, kiedyś miałem problem w kodzie C#, bo okazało się, że język nie umożliwia czegoś, co było dla mnie oczywistością w Delphi. Chodzi o podpinanie event-ów należących do innych komponentów. Pisałem o tym na forach i w końcu ktoś mądrzejszy ode mnie napisał mi, że nie da się tego zrobić tak jak w Delphi (1 linijka kodu) i napisał mi kod. Musiałem rozwiązać problem kopiując delegaty i to było kilkanaście linijeczek więcej. Zawsze znajdą się takie szczegóły, że coś w jednym języku programowania to linijka, a w drugim jest to 10 linijek.

Problemy z konwersją zawsze istnieją, w każdym języku, w każdej technologii. .NET ma ich dość sporo. Im bardziej skomplikowany system tym więcej problemów. Znajomy pracuje w dużej firmie X :x w Krakowie i pisze w .NET 1.1 i nikt nie ma czasu, ani pieniędzy by konwertować ten system, choćby do 2.0. Jak widzisz, nie jest to takie oczywiste

Matlab to język programowania - taki jak każdy inny. Pomyśl, jak mogę coś napisać łatwo i szybko w Matlabie (zwłaszcza jeśli chodzi o macierze), albo mam się męczyć z podobnym problemem w C# to który język wybiorę. Matlab. Czyli nie C#! Więc już to jest konkurencja dla C#. Słyszałem, że Toyota zresztą niedawno wykupiła spory pakiet Matlab do programowania czegoś tam (już nie pamiętam co to było). W ogóle w Matlabie da się generować niezależne aplikacje pod Windows (EXE), nie wiem czy o tym wiesz. Każdy język programowania ma swoje specyficzne zastosowanie, ale są też dziedziny, w których języki konkurują ze sobą.

Sam sobie odpowiedziałeś na to pytanie. To nie wina języka, tylko beznadziejnej polityki marketingowej firmy Borland. Język broni się sam. Przetrwał mimo to.

Delphi to ciekawy język i wciąż nowoczesny.

Pisałem już tutaj, zresztą nie tylko ja. Powtarzał się nie będę, wszystko jest w tym wątku. Była chociażby mowa o problemach z takimi podstawami jak generyki i serializacja.

Skoro do tej pory tego nie zrozumiałeś, to już nie zrozumiesz, więc nie mam po co kolejny raz powtarzać, że tło i ikona na przycisku to dwie różne i niezależne od siebie rzeczy.

Nie dla mnie :slight_smile: Wyrażasz się tak chaotycznie, jakbyś w ogóle nie wiedział o czym piszesz. Cieszę się, że wreszcie się douczyłeś i już prawie umiesz odróżniać język C#, platformę .NET i środowisko programistyczne Visual Studio.

Tak? Napisz zatem w .NET kontrolkę, której którymś przodkiem nie będzie System.Windows.Forms.Control :slight_smile:

A jeśli korzystam z MonoDevelop, SharpDevelop albo Turbo C# Explorera, to też mam kontrolki Visual Studio? Czy może te same kontrolki .NET WinForms nazywają się w tych środowiskach różnie? :smiley:

Karta graficzna jest częścią komputera, ale automatycznie staje się częścią Windowsa, Linuksa i wszystkich innych systemów operacyjnych, które można na tym komputerze zainstalować.

Z taką filozofią nie można się nie zgodzić :slight_smile:

Nie irytujesz mnie, tylko bawisz czytelnika. To różnica :slight_smile:

Jeśli możesz, to pokaż to na przykładzie kodu.

To, że ktoś utrudnia sobie życie (o ile tak jest naprawdę) nie jest żadnym argumentem ani faktem. Zwłaszcza, że wciąż piszesz o jakichś “znajomych”, “firmach X”, zamiast pokazać cokolwiek realnego, o co już kilka razy prosiłem.

Owszem. Pod względem tworzenia programów obliczeniowych Matlab jest konkurencyjny dla wszystkiego, także dla Twojego Delphi.

Tylko dlaczego (po raz kolejny) nie odpowiedziałeś na moje pytanie?

Jest w zasadzie zbyt nowoczesny, dlatego pewno prawie nikt nie chce go używać :slight_smile:

Wiesz - cechuje Cię taka sama odporność na fakty i niechęć do udzielania odpowiedzi na proste pytania, jak 13tego Smoka. Ciągle kręcisz i przeczysz oczywistym faktom. Do tego dziwna filozofia i sofizmaty, więc raczej nie ma jak z Tobą prowadzić dalszej dyskusji.

Pozdrawiam serdecznie.

Generyki pojawiły się w ostatniej edycji języka jak zauważyłeś, z serializacją trzeba niestety kombinować. To nie jest wcale wielkie zacofanie. Leciwy C++ też nie ma w standardzie języka serializacji, a ma swoje miejsce na rynku. Moim zdaniem jesteś najzwyczajniej w świecie uprzedzony do języka Delphi i nic poważnego w nim nigdy nie pisałeś. Za dużo rozmawiałeś z kolegami, którzy Ci powiedzieli, że Delphi “fuj”. Tylko to mnie razi w Twoich wypowiedziach - nie jest to moja odporność na fakty. Udzielam Ci odpowiedzi na Twoje pytania, bo szanuję ludzi, którzy się mnie o coś pytają - ale Ty zachowujesz się tak, jakbyś moich odpowiedzi nawet nie chciał przemyśleć, i jakbyś wychodził z założenia, że we wszystkim prezentujesz jedynie słuszny punkt widzenia. To tylko pozory, rzecz jasna. Doskonale wiem, że tak nie jest - jesteś skromnym, solidnym, uważnym programistą C#, który jednak nie zna Delphi a próbuje się na jego temat wypowiadać.

Jeśli widzisz sens jednoczesnego używania na przycisku: obrazka malowanego w tle, obrazka ładowanego do Image i mniejszego obrazka wziętego z ImageList - to nie mam więcej pytań. Twoje aplikacje muszą świetnie wyglądać. A tak na poważnie, dla mnie to wciąż jest obrazek i lepszym rozwiązaniem byłoby “rozwijane property” (błagam, nie każ mi wyjaśniać tego skrótu myślowego), coś w stylu (tylko, że bardziej przemyślane):

  • ButtonImage
  • do wyboru: enum Bitmap, ImageListItem, Both (ImageListItem + Bitmap = specjalnie dla Ciebie, żebyś mógł skomplikować wszystko :P)
  • ImageAlign

* Top Left, Center, Right

* Middle Left, Center, Right

* Bottom Left, Center, Right

* Fill Tile

* Fill Stretch

  • Bitmapa do załadowania: Image
  • ImageListHandler
  • ImageList

  • ImageIndex

  • ImageKey

Uważam, że już taka konstrukcja zapewniłaby wygodniejszą obsługę obrazka na przycisku. Po pierwsze całą funkcjonalność dotyczącą obsługi obrazka mamy w jednym property, tyle że rozwijalnym. Teraz wybieramy rodzaj obrazka na przycisku, czy ma być to obrazek z ImageList, czy też może obrazek załadowany bezpośrednio do kontrolki. ImageListHandler służy do tego, by opcje dotyczące tylko ImageList przestały się nam walać po głównych właściwościach kontrolki. Można by to jeszcze usprawnić i przemyśleć bardziej.

no widzisz, ja nie muszę pisać, są takie kontrolki:

System.ComponentModel.BackgroundWorker

System.ServiceProcess.ServiceController

System.IO.Ports.SerialPort

System.Diagnostics.Process

System.Diagnostics.PerformanceCounter

itd…

Co do kontrolek standardowo instalowanych z Visual Studio, to faktycznie wszystkie jakie znam są częścią z platformy .NET. Ale jak doinstaluję jakieś nowe to nawet jeśli te dziedziczą po System.Windows.Forms.Control, to i tak mają sporo kodu od niezależnych programistów. Ten dodany kod nie wchodzi już w skład platformy .NET. Dlatego wcześniej postowałem “jak napiszesz własną kontrolkę i umieścisz ją na palecie komponentów Visual Studio, to nie pochodzi ona całkowicie z System.Windows.Forms”. A wciąż jest to dla mnie kontrolka Visual Studio :wink: Nie jest to żadna oficjalna nazwa, no weź daj spokój :slight_smile: Kontrolki Visual Studio to te dostępne w Visual Studio. Nie muszą one wcale pochodzić z System.Windows.Forms ani nawet być częścią platformy .NET - jak np. ReportViewer. Przepraszam Cię bardzo, że znów dla Ciebie jestem taki nieprecyzyjny :slight_smile: Mam nadzieję, że mi wybaczysz to.

Niezbyt ten link może świadczyć dobrze o moich umiejętnościach wtedy gdy go pisałem, ale daję Ci go

http://forum.4programmers.net/viewtopic.php?id=130510

Ajaj, toż to nie żadna filozofia mój drogi czytelniku, a tym bardziej nie taka, z którą nie można się zgodzić. Żadne też to sofizmaty (przepiękne słowo, aż musiałem użyć Wiki). LINQ bardzo się integruje z językiem C#. A pewien taki pan tak pisze o LINQ-u

“W C# z LINQ, jak przystało na obiektowy język programowania, baza i jej elementy traktowane są jak obiekty, stają się częścią składni języka” http://csharp.blog365.pl/?p=15

No wiesz, wydawało mi się, że poważne firmy wiedzą co robią, w końcu umieją zarabiać duże pieniądze. Dlaczego więc, nie przechodzą z tymi systemami na .NET 2.0 tak automatycznie i z wielkim optymizmem - jaki proponujesz? Ja też uważam, że należy do życia podchodzić optymistycznie, odważnie i nie załamywać się, ale czy w takim przypadku jest to ryzyko rozsądne?

Bo się zgubiłem i zapomniałem o co pytałeś. Nie znam programu użytkowego, narzędziowego, graficznego i bazodanowego, ani aplikacji webowej napisanej w Matlabie, do której mogę dać Ci link. Lecz nie tylko do takich programów sprowadza się tworzenie aplikacji różnego rodzaju. Aplikacje różnego rodzaju to również: aplikacje służące do rozpoznawanie ręcznie zapisanych kodów pocztowych na listach, aplikacje rozpoznające tablice rejestracyjne za pomocą sieci neuronowych, aplikacje wykorzystujące sieci neuronowe w ekonomii, aplikacje do rozwiązywania problemów optymalizacyjno - decyzyjnych, aplikacje wykorzystujące sieci neuronowe do klasyfikacji danych i kompresji danych, systemy wnioskowania rozmytego, aplikacje służące do wizualizacji danych, wizualizacji funkcji, powierzchni itd… Matlab to wszystko potrafi, w dodatku można wszystkie programy w nim napisane eksportować do bibliotek, niezależnych aplikacji wykonywalnych, oraz - to jest najciekawsze - używać w C# funkcji matlabowych. Matlab jest niesamowity. Potężny…

Eee tam… Delphi ma na rynku o wiele więcej odbiorców niż Matlab, a o Matlabie nie powiesz - że prawie nikt go nie chce używać, a o Delphi tak mówisz. Coś nie tak jest z Twoim wnioskowaniem.

Również pozdrawiam Cię serdecznie. Jesteś bardzo miłym człowiekiem :smiley:

Czemu dopiero w ostatniej, skoro w innych językach są od dawna? :slight_smile: To jest właśnie zacofanie.

No, a dlaczego mamy nie chcieć zrobić czegoś np. takiego:

screenhdj.th.png

Skoro dla Ciebie jeden obrazek to to samo co dwa obrazki… :expressionless:

Może i tu masz rację. Widocznie w Delphi tak jest i dlatego to lepsze rozwiązanie dla Ciebie.

Jak w tym osiągałoby się efekt, jak na screenie, który wkleiłem?

W Visual Studio możemy sobie pogrupować właściwości według kategorii. Wówczas właściwości związane z wyglądem kontrolki są w sekcji “Apperance” - może to Ci pomoże się odnaleźć w ich gąszczu :slight_smile:

No widzisz, to nie są kontrolki. Kontrolka to element GUI. Nie wszystko, co jest w Toolboxie, to kontrolki, nikt nie ograniczył go do wyświetlanie jedynie ich.

Hmmm… ale co Wy tam wyczarowaliście? Przecież eventy to po prostu wbudowana obsługa Observera. Za obsługę zdarzenia w odpowiedzi na jego wystąpienie odpowiada po prostu metoda w klasie obserwującej. Można ją podpiąć do dowolnej liczby zdarzeń w dowolnej liczbie obiektów obserwowanych.

Serio nie wystarczy takie coś?

using System;

using System.Windows.Forms;


namespace OtherEvent

{

    public partial class Form1 : Form

    {

        public Form1()

        {

            InitializeComponent();

            this.button1.Click += new EventHandler(this.anyButton_Click);

            this.button2.Click += new EventHandler(this.anyButton_Click);

            this.button3.Click += new EventHandler(this.anyButton_Click);

        }


        private void anyButton_Click(object sender, EventArgs e)

        {

            MessageBox.Show((sender as Button).Text + " został kliknięty!");

        }

    }

}

Zaciekawiły mnie też Twoje słowa z tamtego wątku:

Po pierwsze, to z CF zostały usunięte klasy niepotrzebne na urządzeniach mobilnych oraz nadmiarowe klasy i metody, dublujące funkcjonalność pozostałych. Nie, żadne “najważniejsze rzeczy”. PerformClick jest bardzo łatwo zastąpić:

private void button2_Click(object sender, EventArgs e)

{

    //this.button1.PerformClick(); //zamiast tego można:

    this.button1_Click(sender, e);

}

Nie wiedziałem, że mam do czynienia z człowiekiem nie posiadającym matury. W takim razie miałem wobec Ciebie zbyt wielkie wymagania, przepraszam.

Tylko, że Delphi jest konkurencją dla języków biznesowych, takich jak C++ i C# (sam to napisałeś), także Javy, a nie specjalistycznego Matlaba, który ma swoją niszę na rynku.

Bardzo prosto :smiley: Przecież wstawiłem Ci tam opcję Both (ImageListItem + Bitmap) - specjalnie dla Ciebie, przyglądnij się:) A w ogóle dzięki za obrazek, inspirujący:)

Kontrolka Delphi to pojedyncza klasa instancjonowana zwykle raz dla danej instancji formatki i zwykle konfigurowana w edytorze GUI. Ale niekoniecznie musi to być element GUI. W Delphi są kontrolki wizualne i niewizualne, wiesz? W takim samym odniesieniu mówię o kontrolkach w Visual Studio.

No właśnie nie bardzo. Problem polegał na tym, że ja nie wiedziałem jaka metoda będzie podpięta pod zdarzenie Click. A Ty w powyższym kodzie dokładnie wiesz. To nie jest to samo.

Zauważ, że Ty w swoim kodzie wciąż wiesz o istnieniu metody button1_Click. A u mnie nie było takiej możliwości. Tak to jest jak korzysta się z dobrodziejstwa anonimowych delegatów do tworzenia dynamicznie nowych metod, które jeszcze nie istnieją:D Piękna sprawa:D

np.

Timer vTimer = new Timer();

vTimer.Interval = 20;

vTimer.Enabled = true;

vTimer.Tick += delegate(object iSender, EventArgs iE)

{

   (...)

  if (EndOfAnimation())

    vTimer.Enabled = false;

};

A to jest przejaw Twojej złośliwości, co źle świadczy nie o mnie - a o Tobie. Nie musisz przepraszać, że masz wobec mnie wymagania, choć właściwie jestem bardzo zdziwiony, że Ty chcesz ode mnie w ogóle czegoś wymagać… W ogóle, co masz do ludzi, którzy nie mają matury? Uważasz się za lepszego od nich?

http://www.calamitiesofnature.com/archi … ?comic=215

Co robisz dla świata ze swoją wiedzą, oprócz tego, że się nią bezmyślnie chełpisz?

Delphi też ma swoją niszę na rynku - są to natywne aplikacje biznesowe Win32. Niszą języków .NET są aplikacje biznesowe .NET-owe. Java chce być naprawdę przenośną platformą - to jest jej nisza. Każdy z języków ma swoją nisze - czyli określone zastosowanie, gdzie jest najlepszy i jego zastosowanie się najbardziej opłaca. Języki trochę konkurują jeśli chodzi o ogólne zastosowanie, ale też nie wchodzą sobie za bardzo w drogę jeśli chodzi o jakieś specyficzne cele, dla których istnieją. Każdy wytwórca kompilatora i tak się nachapie i jest zadowolony. Każdy sobie rzepkę skrobie. Biznes się kręci. Wszyscy są mniej, lub bardziej zadowoleni, ale nikt z biedy nie przymiera, nawet jeśli ma “tylko” 2% rynku. Skoro nikt z biedy nie przymiera, to znaczy, że jest zapotrzebowanie i popyt na określone usługi i towary. Każdy zarabia i jest git :slight_smile:

A które właściwości dotyczą położenia obrazka, a które tła? ;>

Może w Delphi tak. Ale na świecie kontrolką nazywa się element GUI - i nie miej do mnie o to pretensji, to nie ja wymyśliłem.

Owszem, piękna. Ja zazwyczaj stosuję je, gdy chcę go użyć jednokrotnie. Dla kilku kontrolek piszę już normalną metodę.

W takim razie faktycznie, w zwykłym .NET można to zrobić przez PerformClick, w CF ciężko to osiągnąć. Może są inne sposoby, ale ja ich nie znam, zresztą zapewne byłyby dłuższe, niż zrobienie tego przy użyciu zwykłej metody. W Delphi wystarczy przypisanie - punkt dla Delphi :slight_smile:

Zatem jedyna dla Ciebie rada w tym wypadku, to porzucenie .NET CF i napisanie takiego programu w Delphi, które takich ograniczeń nie posiada i bez problemu można to zaimplementować.

Dzielę się nią, zarówno tą z dziedziny programowania, jak i medycyny, z ludźmi, starając się pomagać. Sporo osób mi za to dziękuje, co mnie bardzo cieszy.

Nie uważam się lepszy od nikogo. Po prostu od niektórych ludzi nie wymagam umiejętności zrozumienia pewnych słów, argumentów, faktów, itp. (Ale jestem świadom, że na pewno za to mają wiele innych zalet, których ja nie posiadam.)

Z tego właśnie powodu kończę dyskusję z Tobą.