Piszesz aplikację pod office? Albo może ma Ci się trafić taki projekt? Sam nie wiesz na co możesz trafić? Szukasz w sieci, ale nic nie znajdujesz, zakładasz więc, że się da? Znam to, byłem tam, zrobiłem tak. Dosłownie zrobiłem tak. Dziś zaś podzielę się z Tobą kilkoma informacjami które POMOGĄ Tobie w podjęciu decyzji czy pakować się w taki projekt i zaoszczędzą masę godzin szukania rozwiązania.

Na początku powiedzmy sobie szczerze, programowanie na office do najlepszych nie należy, ale office jest tak popularny, że aż dziwnie by było, gdyby nikt pod niego nie pisał. Na tych aplikacjach może całkiem nieźle zarobić, trzeba jednak mieć dobry pomysł jak i rozsądne wymagania. W przeciwnym wypadku to równie dobrze możemy wziąć krakersy i próbować sobie żyły pociąć.

Office Interop ma już wiele wiele wiele wiele wiele lat… metody mają nazwy typu ExecuteOld, Execute2007, Execute czy też typy zdarzeń są Office97_2003. Ogólnie to mała czarna magia i jest kilka fajnych perełek w sieci które niektóre rzeczy bardzo ładnie opisują, ale TRZEBA ICH SZUKAĆ GODZINAMI. I tylko wtedy je znajdujemy jak już wiemy jaki mamy konkretny błąd. W przeciwnym wypadku możemy zapomnieć.

No ale dobra. TE KROKI ułatwią Tobie podjęcie decyzji czy pakować się w Office Dev a jak tak, to co na Ciebie CZEKA.

Liczba i rodzaj aplikacja ma znaczenie!

Jeżeli masz napisać aplikację na PowerPoint, Excel, Word i Outlook to ma to duże znaczenie. Office NIE JEST wspólny, jeżeli chodzi o API. Na przykład taka prosta rzecz jak Visible – Word, Excel, Outlook – bool. Excel? Enum, gdzie -1 to true ;)

Nie wspominając już o eventach i innych rzeczach do obsługi. Dokładnie mówiąc możecie przyjąć, że jak wchodzi Outlook, Visio, Project to są osobne byty i każdy wymaga OSOBNEGO softu z małą liczbą kodu który może być współdzielony. Jeżeli chodzi o Word, Excel i PowerPoint to zaleczy co chcecie zrobić, ale przeważnie da się mieć z unifikowany interfejs i co najwyżej osobne implementacje pisać pod aplikację. Ale prawie będzie to jedno i to samo.

Synchronizacja Ribbon

Ribbon jest fajny, lubię go bardziej od tego co było kiedyś. Ale jego oprogramowanie to czysta MASAKRA. Do póki kod ma operować na akcjach: klik akcja, koniec. To spoko, da radę. Ale………. Jak już trzeba utrzymywać stan – na przykład zaznaczenie powoduje, iż jest coś włączone/wyłączone (toggle) to mamy delikatnie mówiąc trochę pod górkę.

Ribbon jest JEDEN dla całej aplikacji. Każde okno to ten sam ribbon. Raz coś ustawione w jednym oknie jest USTAWIONE we wszystkich oknach. Do nas należy pamiętanie stanu przycisków, ładowanie ich i odpowiednie reagowanie. Tak jak w outlook jest to jeszcze jakoś rozsądnie zrobione za pomocą inspektora tak w innych aplikacjach każdy musi się tym sam męczyć.

Ribbon per aplikacja

Zapomnijcie posiadać jedne ribbon dla wszystkich aplikacji – outlook, word itp. Niestety nie da rady, więc przygotujcie się do dużej liczby kopiowania elementów. A jak macie aplikację wielojęzykową… dużo bardzo dużo czasu się na to marnuje. I nie jest to takie proste jak copy-paste.

Office 365 to dwie bestie

To ważne, office 365 to dwa rodzaje pisania kodu i rozszerzeń. Mamy dwie opcje:

  1. Coś co będzie działało na Web i na desktopie tak samo;
  2. Coś co będzie działało tylko na desktopie.

1 piszemy w JavaScript w oparciu o Node.js, 2 piszemy w .NET Framework w języku naszego wyboru. To co jest dostępne w (2) nie jest tym samym co jest w (1). Więc jak macie robić (1) to trzeba zrobić, TRZEBA zrobić research czy to jest w ogóle możliwe.

Dynamic… nie zawsze pomoże

Wydawałoby się, że dynamic pomoże z Interopami i ogólnie pomaga. Do póki nie natrafi się na przypadek iterowania po obiektach w PowerPoint (mój przypadek). Różnica zmiany tego samego kodu na predefiniowane typy z interop? 50 sekund.

Więc rozwiązaniem wydajnościowym może być po prostu zamiana dynamic na typy zdefiniowane.

Tagi/Document Properties/Fields

To jest coś co może o tym wiecie, ja nie wiedziałem. Jedynie Word wspiera wstawianie własności dokumentu jako pól do dokumentu. Excel, PowerPoint i inne tego nie umożliwiają (nie sprawdzałem Visio nie mam). Co to znaczy? Tylko tyle, że jak macie plugin który ma silnie operować na tekście to będzie on silnie operował na tekście zamiast sobie ułatwić i działać na polach częściowo zautomatyzowanych.

Co też powoduje problemy wydajnościowe z wyszukiwaniem i aktualizowaniem elementów.

Eventy generowane przez aplikacje

Mogą się nazywać tak samo, mogą mieć takie same parametry, ale każdy będzie działał inaczej. Na przykład w excel nie jesteśmy wstanie przerwać wychodzenia z aplikacji jak plik nie jest zapisany. Dokładniej: otwieramy excel, modyfikujemy, ALT+F4, z opcji wybieramy Save a potem robimy Cancel na zapisywaniu pliku. Jeżeli event save został przez nas przechwycony, to cancel na nim nic nie da i excel zamknie okno. Gdzie w Word już nie. Ale zaś w Word i Excel możemy zablokować drukowanie a w PowerPoint już nie.

Warto więc o tym wiedzieć.

Wsparcie narzędziowe

Przy dużych projektach dodajcie 2-3 tygodnie czasu na walkę z narzędziami. Różne przypadki mogą być. Ja na przykład musiałem fizycznie w kodzie zmienić IdMso (może kiedyś opiszę, nie ważne co to, takie coś msowego) na jakieś durne, odpalić projekt, zamknąć, i zmienić na poprzednie by mój plugin zaczął się wyświetlać. Wpadłem na to po 4h…

Innym razem rejestrowanie biblioteki z poziomu VS po prostu nie chciało działać. Rozwiązaniem było zarejestrowanie dllki z poziomu command line i następnie już F5 śmigał, jak trzeba (PS.: dla danego projektu dalej tak mam).

Jeszcze taki standardowy przypadek – nie wiem jak ale z designera znikały mi przyciski albo zmieniały one nazwy na domyślnie generowane. Co powodowało wiele innych problemów w tym kompilacyjnych. Czasami to była prosta sprawa, czasami musiałem poprawiać jeszcze 3 języki w zasobach…

Tych problemów pomniejszych jest masa. Ja dla miesięcznego projektu spędziłem 4-5 dni właśnie tylko nad nimi.

Podsumowanie

Dużo? Mógłbym więcej, pewnie będę też rozwijał każdy z punktów albo nawet będzie kilka postów na dany punkt, zobaczymy. Tak czy siak, mam nadzieję, że te informacje trochę Ci pomogą, jak będziesz musiał zadecydować czy w ogóle podjąć się pisania pod Office. Wiem, że mi by bardzo pomogły. Ale mądry człowiek po szkodzie :)

Tak czy siak, projekt udało się skończyć, więc nie było to też takie, że TEGO SIĘ NIE DA. Prawie wszystko się dało zrobić… HACKiem. Ale o tym już chyba kiedyś pisałem? :)

4 KOMENTARZE

  1. Znam ten ból, Interop okazał się być porażką i przenosiłem operowanie na plikach w format Open XML, znam tylko część z tego, ale i tak czasu trzeba planować na takie projekty z zapasem.

    • No ja miałem jeden problem taki, że musiałem operować na Open XML bo… Shell32 nie dawał mi odpowiednich rezultatów co do własności plików ;) oj… czysta przyjemność

  2. Kolega, który był na zeszłotygodniowym NDC w Oslo wspominał, że w MS ponoć planują to (wszystko) posprzątać… Ciekawe, jak za kilka tygodni materiały będą dostępne, być może warto będzie na to zerknąć i śledzić sprawę.

    Ale jak znam życie – to posprzątana będzie tylko najnowsza wersja. Jak będą wymagania by wspierać stare wersje (na 200%) to pewnie i tak pupa blada…

    • ;) ja tam się boję posprzątania przez MS. Od 4 lat sprzątają .NET i jak na razie jest chyba większy bałagan ;)

Comments are closed.