Temat: MS Office jako platforma dla aplikacji biurowych
To idzie moim zdaniem w złym kierunku, nie może być tak, że z jednej strony staramy się pokazać, że developer office'a to naprawdę wartościowy programista, a z drugiej strony wchodzimy w pułapkę własnych kompleksów...
Moniko pozwolisz, że na przykładzie twojego posta rozwinę o co mi chodzi.
Monika M.:
Problemem z aplikacjami Office'owymi jest to, że:
1) wymagają aplikacji, w której mogą pracować, jak np. Word, Excel;
I to jest zaleta, przecież o to chodzi by rozbudować/dodać możliwości do środowiska, które użytkownik dobrze zna. Przecież piszemy DODATEK, a nie osobną aplikacje, więc jest to naturalne, a nie wada
2) problemy z zabezpieczeniem - brak kompilacji do formy wykonywalnej (.exe) - czasem wystarczy otworzyć plik Excela w Oo, żeby wszystko rozwalić lub po prostu zobaczyć co i jak zrobił autor i... "trochę dostosować" albo... "zaczerpnąć inspiracji";
Możesz zawsze pisać dodatek VSTO, ale to nie o to chodzi, ja nie mam problemu, aby ktoś czerpał "inspiracje" z mojej pracy, a prawda jest taka, że jeżeli klient jest zadowolony z dodatku to sam poprosi o dodanie funkcjonalności niż będzie w nim grzebać. Oczywiście może, ale mi się to nie zdarzyło. Osobiście zdarza mi się przy klientach poprawić na szybko coś w VBA i nie robię z tego tajemnej sztuki, ale to raczej budzi zainteresowanie jak wyglądają bebechy, a nie jak coś zmienić
3) do niedawna tylko wersja Developer Accessa miała możliwość dystrybucji bazy z runtime'm;
Ale to w dalszym ciągu Access tylko okrojony, plik nie różni się dla pełnej wersji czy runtimowej. Naprawdę klient nie płaci za to czy to jest exec czy coś innego, on tak naprawdę chce konkretne rozwiązanie.
4) różne wersje Office'a, które to powodują, że pewne polecenia w danej wersji są dostępne, a inne nie, różne wyświetlanie teoretycznie tych samych elementów;
A co mają powiedzieć webdeveloperzy, nie dość że kilka przeglądarek to jeszcze różne działanie ich różnej wersji. Z reguły specyfikacja określa z jaką wersją office'a pójdzie dany dodatek, jeżeli napiszę aplikacje w .net dla framework-a 4.0 to na 2.0 nie pójdzie, zupełnie jak dla mnie sztuczny problem, to się dzieje w każdym środowisku.
5) zdecydowanie łatwiej tworzy się choćby takie formularze, np. w Visual Studio, gdzie np. są już kontrolki pól tekstowych od razu z pokrętłem, paski statusu, paski postępu, panele reagujące na zmianę wielkości okna itd. itd.
Wg. mnie jeżeli chodzi o tworzenie formularzy to jakoś szczególnie nie robi mi to różnicy i nie uważam, żeby VS było jakoś szczególnie lepsze. Przez lata pracy, wyrobiłem sobie zestaw kontrolek, progressbarów które używam i nie odczuwam ich braku, fakt, że pewne rzeczy wymagają dodatkowego kodu ale to też się zmienia, jak chociażby panele i resize na formularzach w accessie
Ponadto mam wrażenie, że MS jakby utrudnia zamiast ułatwiać tworzenie aplikacji pod Office'm a to wyrzucaniem jakiś funkcji w kolejnej wersji (bez zastąpienia czymś lepszym czy w ogóle czymkolwiek), brakiem rozwijania funkcjonalności VBE.
Nie demonizowałbym, aż tak chłopaków z MS;) Pewne decyzje zapadają i tak jest trzeba się dostosować. Co do VBE to rzeczywiście wygląd archaiczny ale z drugiej strony, ja używając
http://www.mztools.com/v3/mztools3.aspx nie narzekam na brak funkcjonalności, no może zwijanie pętli cz if-ów.
Reasumując to chyba wiekszość programistów VBA rzeczywiście ma problemy ze zdefiniowaniem wartości swojej pracy, jeżeli w procesie sprzedaży klient skupia się na tym, że to nie będzie exec to znaczy, że robimy coś nie tak.
Tak naprawdę takie dyskusje można toczyć w gronie programistów, klient ma być przede wszystkim zadowolony
пропозиції роботи
