Name mit array

Question

Hallo,

ich möchte gern einer Liste mit Strings einen Namen geben, ohne diese Liste irgendwo im Tabellenblatt speichern zu müssen.

Dazu habe ich den Name-Manager geöffnet,
einen neuen Namen eingetragen : _BNummern
und folgende Matrix zugewiesen:
={"86"."20"."19"."21"."30"."32A"."32B"."52A"."53A"."57A"."58A"."72"}

Der Sinn der Übung ist, diese Liste dann in VBA abrufen zu können.
mein Versuch:

Dim sID
For each sid in Nemes(_BNummern)

Next

Es gelingt mir aber nicht. Weiß jemand, wo der Fehler liegt?

Gruß Rudi

Answer 1

Hi Rudi,

nur die Steuerelemente auf einem UserForm besitzen eine Tag-Eigenschaft - die im Tabellenblatt leider nicht. Außerdem: die Tag-Eigenschaft ist nur zur Laufzeit aktiv, ihre Inhalte "verschwinden" also, sobald die Arbeitsmappe geschlossen wird. Hinzu kommt: wie soll ein ungeübter Benutzer dort Änderungen vornehmen? Dann kannst du das Array auch gleich im Code definieren, sodass es dort geändert werden muss.

Ich würde dir da eine ganz andere Lösung vorschlagen: schreibe die Daten in ein ausgeblendetes Tabellenblatt und schreibe ein extra Programm mit einem UserForm, sodass damit Änderungen vorgenommen werden können.

Bis später,
Karin

Answer 2

Hallo Karin,
ich danke dir für deine Hilfe. Eine UF hatte ich auch im Hinterkopf. Da muss ich dann wohl durch. Mit den UF's und den Steuerelementen stehe ich so'n bischen auf Kriegsfuss, weil das nicht so einfach ist sie zu programmieren. Gut das ich es damit nicht eilig habe.

Ein Wort noch zu den versteckten Tabellen: Ich bin dagegen, weil eine versteckte Tabelle auch vergessen werden kann(wie auch eine separate Datei), wenn man mal die Datei wechselt. An den Code denkt man noch, an die Tabelle nicht. Dann ärgert man sich, weil man noch nacharbeiten muss. Und dann erweckt etwas Verstecktes auch immer Misstrauen.

Danke auch für deine Info zur Tag-Eigenschaft. Das spart wieder Zeit. Is doch gut, wenn man Ahnung hat, oder eine kennt, der Ahnung hat. :)

Gruß Rudi

Answer 3

Hi Rudi,

das "Problem" mit versteckten Tabellen beim Umzug in eine neue Arbeitsmappe ist durchaus kleiner als du denkst, denn da du sowieso in den VBA-Editor gehen musst, um Code zu übernehmen, wird dir sofort auffallen, dass da noch mehr als nur 1 Tabellenblatt vorhanden ist. Außerdem: ehe du ein Projekt, welches in eine andere Arbeitsmappe umgezogen ist, für den Allgemeingebrauch freigbst, wirst du als vorsorglicher Programmierer doch das neue Projekt auf jeden Fall erst einmal selbst testen - und dann fällt dir garanteirt auf, dass da doch etwas fehlt... ;-)

Bis später,
Karin

Answer 4

Hallo Karin,

nein, nein, mit Umziehen meine ich nicht mich, sondern den User.
Der hat alle Makros im Klassenmodul der Tabelle mit den Ursprungsdaten.
Da wird nix dran formatiert.

Die Makros schreiben dann die Daten um in andere Tabellenblätter.
Dort wird dann verschiedentlich formatiert was das Zeug hält,
ausgedruckt und in den Papierkorb... :)

Irgendwann ist dann die Datei voll(viele Blätter), bei den Formatierungen
sieht keiner mehr durch - also fängt man eine neue Datei an.
Dann braucht der User nur das Ur-Blatt mit den Makros kopieren
in eine neue Datei und schon ist er wieder jungfreundlich.

Gruß
Rudi

Answer 5

Hi Rudi,

ich habe für mich selbst und auch für andere nicht erst ein Projekt erstellt und die Erfahrung hat mich folgendes gelehrt:

1. je gründlicher man den/die Benutzer in die Handhabung einweist (z.B. auch in die Verfahrensweise im Falle eines "Umzuges" in eine neue Arbeitsmappe), desto weinger Probleme gibt es mit dem Projekt

2. wenn es Probleme nach einem "Umzug" in eine neue Arbeitsmappe gibt, kommt der/die Benutzer sowieso zum Autor des Projektes und als Ersteller weiß man dann schon, wo man ansetzen muss

3. man kann es dem/den Benutzer(n) dahingehend erleichtern, dass man den "Umzug" in eine neue Arbeitsmappe in das Projekt integriert und per VBA ausführen lässt, sodass beim Umzug nichts vergessen wird. Der/die Benutzer ist/sind meist sowieso dankbar, wenn alles auf "Knopfdruck" ohne großes eigenes Zutun geschieht.

Klar, entscheiden musst letztendlich du, aber man kann es sich und dem Benutzer auch schwer oder leicht machen... ;-)))

Bis später,
Karin

Answer 6

Hallo Karin,

klar man kann es sich und dem Benutzer auch schwer oder leicht machen.
Aber ich bitte dich, was ist daran schwer, ein Blatt zu kopieren.

Jedes zusätzliche Makro macht mir nur Arbeit und erhöht die Anfälligkeit.
Ja wenn man das professionell sieht, dann kommen vielleicht noch andere Beweggründe ist Spiel. Je mehr 'Dienstleistung' ich dem Kunden aufschwatzen kann, um so abhängiger mache ich ihn von mir. Dabei wäre es für ihn leichter, wenn er erstmal die "Gebrauchsanwendung" liest, bevor er Excel startet. Es gibt ja auch die, die meinen Excel wäre ein Malprogramm für Tabellen. Rechnen tun sie mit dem Taschenrechner und tragen die Ergebnisse in die Wordtabelle ein. Aber das kennst du sicher auch.

Mein Grundsatz ist: "Der kürzeste Weg zum Ziel ist der beste" Ich bilde mir ein, dem User auch behilflich zu sein, wenn ich ihm von einem Umweg abbringen kann. Du musst nicht über Rom nach Madrid fahren, auch wenn es dir die Leute empfehlen. Es gibt auch eine Straße über Paris. Das spart Zeit und Kosten.

Aber ich komme langsam vom Thema ab. Wenn du nicht 419 Kilometer weit weg wohnen würdest, würde ich zum Kaffee kommen und wir könnten gern weiter reden.

bis es so weit ist
Liebe Grüße
Rudi

Answer 7

Hi Rudi,

nur mal zur Klarstellung, damit hier keine falschen Vorstellung aufkommen:

Ja wenn man das professionell sieht, dann kommen vielleicht noch andere Beweggründe ist Spiel. Je mehr 'Dienstleistung' ich dem Kunden aufschwatzen kann, um so abhängiger mache ich ihn von mir.

Excel ist mein Hobby und nicht mein Beruf, mit dem ich meinen Unterhalt verdienen muss... ;-)

Bis später,
Karin