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.