[vba] automatyczne nadawanie nazw zmiennym

Uzyj kolekcji. Klucz możesz definiować sobie zupełnie dowolnie.

Tak rzuciłem tylko okiem zaraz sbie temat przeczytam ale ... , czy dobrze rozumiem że to taki odpowiednik klas i obiektów z C# ?
Wycofuję pytanie,
Zasada najpierw sprawdź potem pytaj wraca do użycia :)

Uzyj kolekcji. Klucz możesz definiować sobie zupełnie dowolnie.

Ok, dokształciłem się, poczytałem i ... nadal jestem początkującym początkującym :)
Proszę więc o potwierdzenie/zaprzeczenie słuszności obranej drogi. A wygląda to mniej więcej tak:
<> Tworzę sobie kolekcję do przechowywania danych o czymś, niech to będzie dla przykładu zaplanowane działanie serwisowe w samochodzie.
<> Użytkownik tworzy takie działanie (wybiera z listy na ten przykład) pod postacią wymiany opon. Określa terminy, warunki. miejsce i cenę jaką będzie musiał zapłacić.
<> Wprowadzone dane zapisuję w kolekcji jako np. pozycję 1
<> Użytkownik wpadł dodatkowo na pomysł wymiany amortyzatora, bo mu się auto "giba" na zakrętach i teściowa w drodze do kościoła ma nudności. Nikt nie lubi zarzyganej tapicerki.
<> Użytkownik tworzy takie działanie jako kolejne.
<> Wprowadzone dane zapisuję w kolekcji jako pierwsza wolna pozycja.
Użytkownik powtarza swoje działania aż do końca ram, a ja mam dane poukładane w sensowny sposób , z możliwością ich "bezproblemowego" obrabiania na dalszym etapie.
W tym dalszym etapie, dane z każdego z wprowadzonych "Działań serwisowych" będą obrabiane i przetwarzane dalej w innym kontekście. Może dla jasności pominę co dalej bo mi się wymyślanie przykładów nie powiodło :).

Czy taka droga ma sens?
Jeżeli nie, to w którą stronę się kierować?

P.S.
Ten przykład to tylko przykład. Właśnie go wymyśliłem dla zobrazowania problemu.

Nie, nie ma sensu. Użyj bazy danych.

Nie to że się bronię przed takim rozwiązaniem. W przyszłości z ochotą zacznę to rozpracowywać, gdyż postanowiłem się rozwijać również w tym kierunku.
Jednakże ... chwilowo jako osoba zupełnie początkująca naumiewam się vba od strony excela (dodatkowo i równolegle to samo osiągam poprzez c#) . Uczę się samodzielnie, korzystając głównie z dokumentacji ms, poradników i wujka google. Zanim przejdę do baz danych, chciałbym we własnej ocenie mieć świadomość, poznania podstaw vba (i c#).
W tym konkretnie przypadku chodzi mi o ogarnięcie sposobu na "zarządzanie danymi" w programie.
Mam to szczęście, że mój pracodawca dodatkowo za to (efekty nauki w postaci programu) mi płaci :) W efekcie powstało i działa całkiem dobrze narzędzie do kalkulowania ceny usługi.
Krokiem gdzieś tam kolejnym będzie baza danych i przechowywanie w niej efektów pracy wielu osób, jednak nie jestem na to jeszcze gotowy.

Chwilowo chcę usprawnić i ulepszyć program.
W efekcie, zamiast określenia w arkuszu na sztywno iluśtam pozycji możliwych do wprowadzenia (w przykładzie powyżej - działań serwisowych w samochodzie- choć samo narzędzie nie ma nic wspólnego z samochodami i serwisem) chcę dodawać je w miarę potrzeb.
W moim planie kolekcje wydają się odpowiednie (podkreślam wydają się osobie początkującej).
Chwilowo chcę w niej trzymać dane poukładane w tabelach.
W późniejszym "rozwoju" przejdę do stworzenia sobie klasy, obiektu, i przechowywania danych dla obiektu w kolekcji, ponownego ich przepychania do obiektu aby je "obsłużyć" w innych operacjach itp itd.
Problemem dla mnie było dla mnie to (tutaj opisuję mój tok rozumowania w tamtym czasie), że chcąc obsłużyć dodawanie pozycji jedną procedurą, muszę jakoś wprowadzone dane "zyndywidualizować" (Boże co za słowo), aby odnosiły się do konkretnej dodanej pozycji. Chciałem to zrobić z pominięciem zapisywania sobie tego w arkuszu. I dlatego wątek ma taki tytuł, a nie inny, gdyż zastanowiłem się czy istnieje możliwość aby zmienne (tablice czy inne takie) w których miałem przechowywać wyniki procedury, mogą być "nazwane w locie" - indywidualnie dla każdej z dodanych pozycji (sam siebie nie rozumiem, ale liczę że Wam się uda). Tutaj kolekcja jest jak najbardziej pomocna, za każdym dodaniem pozycji, uzyskane dane wrzucam o worka kolekcji identyfikując je w sposób dowolny i w wypadku potrzeby dalszej obróbki mam do nich bezproblemowy dostęp.
Ominę dzięki temu dotychczasowe działanie - przechowywania koniecznych danych w komórkach arkusza (co na początku było dobrym rozwiązaniem ze względu na łatwość ogarnięcia) i ciągłego pobierania ich, obrabiania i ponownego zapisywania.
Od teraz arkusz ma służyć do przechowywania wyników działania, a nie jako podręczny i łatwy (dla mnie) w obsłudze ze względu na wizualizację ram.

Czyli moja droga w rozwoju umiejętności to chwilowo:
---> kolekcje + podstawowe zmienne
---> kolekcje + Tablice
---> kolekcje + obiekt
Baza danych.

Opisałem jak umiałem ... i dlaczego i co chcę uzyskać.

W moim wczorajszym pytaniu chodzi mi o sens opisanego rozwiązania. Czy warto iść tą drogą, czy ma szansę działać (takie odnoszę wrażenie i kilka podstawowych prób podnosi mnie na duchu) w taki sposób.
Do baz dojdę, ale przede mną jeszcze kilka innych płotków do przeskoczenia.

Utwórz sobie arkusz, w którym będzie zdefiniowana tabela. Będzie to twoja baza danych. Jeśli nie chcesz aby był widoczny dla użytkownika to w jego właściwościach jest opcja ukrywania - vbveryhidden. Kolekcje są niewygodne w użytku, nie idź w tę stronę

Poukrywane, poblokowane iw każdej innej formie zaczarowane arkusze z danymi mam i używam. Działają i to dobrze, ale jak zawsze istnieje jakieś ale...

• Dużo operacji zapisu i odczytu danych to dużo zmarnowanego czasu. Gdy to się robi raz, aby zrzucić wynik (zapisać lub wczytać efekt pracy) to jeszcze ok, ale traktowanie arkusza jak podręcznej pamięci do obliczeń to już spore różnice w działaniu. Sprawdziłem sobie na przykładzie tabeli i arkusza - utworzenie kalendarza, sprawdzenie i oznaczenie konkretnych dni, porównanie kalendarzami pomocniczych dat (np. świąt, choć kalendarzy pomocniczych w sumie jest z 10) i odpowiednie działanie w razie gdy ... ). W wypadku arkusza dla okresu 3 lat trwa to około 7 sekund. Gdy te same dane przepchnę w tablice, to praktycznie działa w jednym kliknięciu myszki.

• Tablica dała mi możliwości, które dla arkusza są niedostępne - więcej wymiarów. Do tego samego kalendarza stworzyłem sobie tablicę 3d. rok/miesiąc/dzień, na skrzyżowaniu przechowuję sobie wartości "byte" określające "cośtam". Jasne że mogę w arkuszu i inaczej, ale okazało się to całkiem wygodne.

• Właśnie byłem 10 dni na urlopie i z marszu wróciłem do obróbki mojego projektu, potrzebowałem do tego tylko 10 minut na kawę, kiedy wcześniej musiałem sobie pół dnia przypominać co jest czym i po co. Dobrze przemyślana tablica ułatwia (to moje subiektywne wrażenie) działania. Wcześniej większość kodu odpowiadała za zapis danych w taki sposób aby później można było to odnaleźć. Było to upierdliwe, gdyż po kilku dniach robienia innych elementów zawsze wymagało to ponownej analizy co i jak się dzieje. teraz wystarczy pamiętać YY/MM/DD i co wartości oznaczają. Gdybym od razu zaczął od tablic, oszczędziłbym sobie masę roboty (za to niczego bym się nie nauczył).

Czy kolekcje są niewygodne? Być może, tylko teraz mam "awersję" do poprzedniej formy. Samo ogarnianie danych w projekcie tak, aby były gotowe do użycia później, to było 50% kodu. Teraz (szacunkowo, jak już całość przerobię) około 5%. Rząd wielkości to spory sukces. To mi się w głowie mieści, poprzednia metoda wysypywała się uszami.