Excel, Access, VBA ....

Tym razem moja oferta - dodatek Excela będący generatorem kodu QR.

Działa tak:

Szczegóły i wersja demo do pobrania są tu:

 Generator QRCode

Zapraszam.

Ostatnio dotarł do mnie plik ze zdjęciami. Było ich kilkanaście, oprócz tego zapisane dane (nic wielkiego - ok.200 wierszy w 6 kolumnach). Wydawać by się mogło, że nie powinien być zbyt wielki, a jednak - w wersji xls miał rozmiar ok.35 Mb. Nie udało się go nawet przesłać pocztą.
Taka wielkość pliku z pewnością niekorzystnie wpływa na pracę w pliku, znacząco obciąża pamięć operacyjną i tak naprawdę - trudno w nim cokolwiek zrobić.
Podstawową przyczyną tego wielkiego rozmiaru były właśnie te zdjęcia i od tego właśnie zaczęłam optymalizację pliku.

Jak się do tego zabrać? Wstawiając do skoroszytu Excela zdjęcia, obrazy czy pliki graficzne - musimy dokonać ich kompresji. Sposób działania w takich przypadkach pokazuję tu:

Rozwiązanie proste, a jednocześnie skuteczne.

W niektórych plikach Excela znajdują się łącza do innych plików. Najczęściej są to działania świadome i celowe, pozwalające np. na agregację danych z różnych arkuszy/skoroszytów. Czasem jednak zdarza się, że łączy teoretycznie nie powinno być, a jednak są widoczne. W dodatku ich odnalezienie jest trudne, nie można ich także przerwać.

Wprawdzie można wyłączyć aktualizację łączy, ale to tylko maskuje, a nie rozwiązuje problem. Brak komunikatów nie załatwia sprawy.
W tego typu przypadkach najczęściej okazuje się, że łącza do innego pliku wcale nie są wstawione bezpośrednio w komórkach, a nieco bardziej "zagnieżdżone". Na początek warto więc sprawdzić:

• ustawienia poprawności danych
  kto wie, czy na którejś z list nie ma odwołania do innego pliku?
  
• formatowanie warunkowe
  tu też mogą być łącza
  

Tego typu sytuacje mogą się zdarzyć, gdy na przykład kopiujemy jakiś zakres komórek z innego skoroszytu, zapominając o tym, że jest tam zdefiniowana lista poprawności danych (przećwiczyłam to na sobie).
Jeśli plik jest mało rozbudowany - można to znaleźć ręcznie, choć czasem trzeba się naszukać. Gorzej, gdy plik zawiera wiele arkuszy, w każdym jest sporo danych i wykresów. Wówczas znalezienie takich odwołań może być naprawdę bardzo pracochłonne. Na takie przypadki jest specjalny dodatek Billa Manville'a:

FindLink

Trafiłam na niego dzięki pomocy przyjaciół z ExcelForum.pl  (to naprawdę najlepsze forum Excela). Zainstalowałam, zastosowałam i problem z dziwnymi łączami zniknął. Teraz dodatek nadal jest zainstalowany w moim Excelu, widać go na karcie Dodatki. I przydaje się.

A tu na wszelki wypadek link do filmiku pokazującego jak zainstalować dodatek w Excelu:

Instalacja dodatku Excela

W ramach promocji świątecznej, w dniach 10 - 12 kwietnia 2017r., pakiety kurs video + ebook tańsze o 30%. 

Warto skorzystać.

Osobiście polecam kursy, które sama znam i opisałam je tu:

Kursy video

Szczegóły promocji są tu:

Wielkanocna promocja

Tylko do końca dnia 19 marca 2017 - dobre kursy komputerowe w bardzo obniżonych cenach:

Warto zajrzeć.

Przez ostatnich kilka lat współpracowałam z jednym z portali elearningowych. Publikowałam tam swoje autorskie szkolenia z VBA w Excelu. Niestety, kilka miesięcy temu portal zniknął z sieci, nawet nie udało mi się wyśledzić co się z nim stało. I tym sposobem pozostały mi materiały (nie wszystkie, ale sporo), które w tej chwili są zupełnie niewykorzystywane. Trochę mi ich szkoda - po małych przeróbkach można je wykorzystać, może się komuś przydadzą? A ponieważ większość z tych materiałów to filmiki, na swoim koncie YouTube założyłam kanał, gdzie będę je sukcesywnie publikować.

Na początek kurs "VBA dla początkujących" czyli kurs dla tych, którzy chcieliby zacząć swoją przygodę z VBA. Link jest tu:

VBA dla początkujących

Zapraszam do subskrypcji.

Wyobraźmy sobie arkusz Excela z kodem reagującym na zdarzenia arkusza. W zależności od tego, jaki jest to kod, jego wykonywanie bardzo łatwo może generować kolejne i zupełnie niepotrzebne zdarzenia arkusza.
Załóżmy, że mamy oprogramowane zdarzenie arkusza, które po zmianie wartości w komórce kolumny A w sąsiadującej z nią komórce kolumny B wstawia datę. Przykładowy kod takiej funkcji wygląda tak:

W trakcie wykonywania kodu, po wstawieniu wartości w kolumnie B następuje wykrycie zdarzenia "przy zmianie" i następuje ponowne uruchomienie makra (mimo, że pierwsze nie doszło jeszcze do końca). W tym przypadku akurat może być praktycznie niezauważalne, ale jeżeli takich zmian jest więcej - owszem. W ekstremalnym przypadku może to doprowadzić do zapętlenia kodu.

Chcąc tego uniknąć musimy na czas wykonywania kodu po prostu wyłączyć obsługę wykrywania zdarzeń. Wykorzystujemy do tego właściwość obiektu Application - EnableEvants. Jest to właściwość typu Boolean czyli może przybierać wartość Prawda lub Fałsz. Ustawiamy ją tak:

Application.EnableEvents=False          'wyłączenie obsługi zdarzeń

Application.EnableEvents=True            'włączenie obsługi zdarzeń

Wykorzystując w kodzie makra jw. mamy więc:

I już. Na czas wykonywania kodu obsługa zdarzeń jest wyłączona - wstawienie daty w komórce sąsiadującej nie wywoła w tym przypadku ponownej reakcji na zdarzenie.

Poprzednia notka na blogu poświęcona była dobrym praktykom przy tworzeniu aplikacji Access, tym razem kilka rad jakich zasad trzymać się przy pisaniu kodu VBA (czy to w Accessie czy w Excelu).

Na wszelki wypadek uprzedzam, że są to rady wynikające z moich własnych doświadczeń - stosuję je na co dzień i sprawdzają się. Generalnie jednak uważam, że nie ma jedynie słusznego sposobu tworzenia oprogramowania, choć pewne zasady powodują, że kod jest bardziej optymalny, a aplikacja działa szybciej i wydajniej.

• na początku każdego modułu warto wstawić Option Explicit. Pozwoli to na zabezpieczenie przed literówkami w nazwach zmiennych i procedur;
  
• żadnych polskich literek w nazwach funkcji, procedur czy zmiennych - tak jest naprawdę bezpieczniej i kod nie wysypie się przy uruchomieniu na komputerze z inną wersją językową;
  
• ponieważ słowa kluczowe VBA są ściśle związane z językiem angielskim, nadając własne nazwy (procedur, funkcji, zmiennych) lepiej używać oznaczeń bardziej przypominających słowa polskie. Pozwoli to na łatwe wyłapanie w kodzie tych nazw, które sami zdefiniowaliśmy od tego, co jest zdefiniowane w bibliotekach VBA;
• makra w aplikacjach Access lepiej napisać lub przekonwertować do kodu VBA - działają szybciej;
• w aplikacjach Excel przy nagrywaniu makra najczęściej pojawiającym się obiektem jest Selection - modyfikujmy nagrany kod tak, aby tego uniknąć. Nie tylko spowalnia działanie, ale także często powoduje niepotrzebne miganie ekranu;
• przy bardziej skomplikowanych aplikacjach warto podzielić kod na kilka różnych modułów i nadać im własne nazwy - odszukamy wówczas moduł z funkcjami, kodem wejściowym itp.
• korzystajmy z obsługi błędów - to się zawsze sprawdza;
• kompilujmy kod - od razu wyłapiemy jego błędy.
  

To takie podstawy. Ja wykorzystuję na co dzień i się sprawdzają.

Każdy tworzący aplikacje w Accessie ma swoje własne przyzwyczajenia i zasady tworzenia. Moim zdaniem nie ma jedynie słusznych rozwiązań, różne drogi prowadzą do tego samego celu. Owszem, są metody mniej lub bardziej optymalne, działające szybciej lub wolniej, ale najczęściej nawet nie widać różnicy, szczególnie przy prostych aplikacjach.

Ja też mam swoje przyzwyczajenia i sposoby tworzenia aplikacji - takie własne dobre praktyki. Może komuś się przyda?

• nazwy tabel, kwerend i formularzy nie powinny mieć takich samych nazw. Wprawdzie od wersji chyba Access 2007 jest to możliwe, ale jeśli odwołujemy się do jakiegoś obiektu, lepiej wiedzieć czy chodzi tu o tabelę czy kwerendę. Jeśli mamy np. tabelę Spis - warto zapisać ja pod nazwą np.TbSpis, związaną z nią kwerendę - KwSpis, a formularz - FrSpis.
  W podobny sposób - wszystkie inne obiekty. W ten sposób na pewno się nie zgubimy, nawet gdy obiektów jest dużo;
• żadnych polskich literek w nazwach obiektów i nazwach pól. Teoretycznie tu też nie ma zakazu, ale wszystkie te ogonki mogą być źródłem problemów. Polskie znaki diaktryczne można za to wpisywać w tytułach kolumn, pól itp. Efekt końcowy np. na formularzu będzie taki sam, a unikamy w ten sposób ewentualnych błędów przy uruchomieniu aplikacji na komputerze w innej wersji językowej;
• nazwy obiektów, pól itd. lepiej gdy są jednowyrazowe. Czyli zamiast np. Marka samochodu można wykorzystać nazwę MarkaSamochodu - to metoda zapisu "na wielbłąda". Moim zdaniem dobrze się sprawdza;
• wszystkie nieprzypisane formanty na formularzu (przyciski poleceń, pola kombi itp.) powinny mieć swoje własne nazwy mniej więcej opisujące ich zawartość. Zamiast Polecenie1, Polecenie2 ... lepiej stosować nazwy typu PolecenieWyjscie, PolecenieWydruk itp. Przy większej ilości formantów na pewno w ten sposób się nie pogubimy;
• nie jest to regułą, ale przy wprowadzaniu danych bardzo często stosuję pusty, niezwiązany formularz. Przy wypełnianiu poszczególnych pól stosuję kontrolę poprawności danych, a dopiero później wprowadzam dane do tabeli/tabel kodem VBA.

To takie podstawy. Ja wykorzystuję na co dzień i się sprawdzają.

Świąteczna promocja na aplikację do mailingu:

Szczegóły tu:

Aplikacja do mailingu