🚀 go-pugleaf

Jacek Wołoszka wrote:
> "Marek Janaszewski (USUN_TO. z adresu!)" <USUN_TO...@gazeta.pl>
> wrote in message news:c53s4n$1q18$1@news.atman.pl...
[...]
> tylko tyle ile wymaga aplikacja.
> Rozwiajajc Twoj tok myslenia najlepiej byloby nie uzywac a aplikacjach
> komponentow NET (np DataGrid) tylko je samodzielnie pisac.....
> A grupowicz przedstawiajacy sie jako tibe zadal wg mnie bardzo
> rozsadne pytanie.
[...]

Witam!

Zależy co i do czego. Nie znam na tyle DataGrida aby określić sensowność
jego użycia ale mogę wyobrazić sobie sytuacje, w które powszechne używanie
tego komponentu wcale nie będzie dobrym rozwiązaniem. Być może lepszym
rozwiązaniem będzie użycie ListView albo ListBox i wypełnienie go danymi.
Nie chodzi mi budowanie wszystkie od nowa ale być może lepszym pomysłem jest
jakieś twórcze wykorzystanie tych kilku sprawdzonych komponentów, które są.

Sytuacja z raportami jest zupełnie specyficzna. Szczerze mówią nie ma dla
tej sytuacji dobrych rozwiązał. Rozpoznał bym najpierw co się nadaje w .NET
do wykorzystania.

Jest także inny argument. Prowadziłem kiedyś rozmowy na temat kontrolek
bazodanowych w Delphi. To akurat nie jest dobra analogia bo jak dotąd
ADO.NET wydaje się dobrze zrobione i nie przeautomatyzowane pozwalając na
używanie jego w różnych scenariusza. W Delphi jest kontrolka TDBEdit (T od
Type czyli typu), odpowiednik TEdit do baz danych. Otóż mój rozmówca
potwierdził moje przemyślenia mniej więcej takim zdaniem "Oczywiście, że
łatwiej jest zrobić edycje w bazie danych za pomocą TEdit niż TDBEdit".
Borland zrobić kontrolkę, która moim zdaniem dobrze sprawuje się tylko na
pokazach. Wystarczy ustawić właściwości i działa. Tylko nie można jej
wykorzystać w wielu scenariuszach. Reasumują jak napisał Wirth "Algorytmy +
Struktury = Programy". Manipulując tylko właściwościami a nie piszą także
samemu program zaburzamy to równie. Można stosować coraz bardziej
rozbudowane komponenty zajmujące w .exe i pamięci coraz więcej miejsca
podczas gdy rozwiązanie za pomocą kodu jest prostsze i elastyczne. Po prostu
nie należy zapominać o algorytmach. Oczywiście i w stronę samy algorytmów
nie należy przesadzać nie ma to jak dobre struktury danych rozjaśniające
program.

I jest jeszcze jeden argument, pieniądze. Dobre komponenty kosztują. Tu
akurat mamy do czynienia z promocją ComponentOne. Ale nie wydaje mi się, że
przy oprogramowaniu dla małych i średnich firm będzie nadmiar pieniędzy aby
obtaczać się różnymi bibliotekami, podczas gdy brakuje pieniędzy na nie
pirackie podstawowe oprogramowanie do tworzenia programów. Dlatego moja
rada, że należy ćwiczyć dobrze poznać w pierwszej kolejności to co jest
dostępne w .NET Framework.

-- 
Pozdrawiam,
Marek Janaszewski
[ j_m...@gazeta.pl ]