Microsoft Excel

Herbers Excel/VBA-Archiv

Objektvariablen - Ein bisschen Theorie


Betrifft: Objektvariablen - Ein bisschen Theorie von: Daniel
Geschrieben am: 28.03.2018 12:04:43

Geschätzte Excel Liebhaber

Ich bin gerade daran, in einem grösseren Projekt geschätzte 70 Variablen als Objektvariablen zu definieren. Dazu habe ich folgende zwei Fragen, bei denen mir weder die Excel-Hilfe noch die Internetsuche bisher behilflich ist:

1) Gibt es eine Möglichkeit, die Dimensionierung von 70 Objektvariablen einfacher zu gestalten, als 70x Dim [Name Objektvariable] As [Range/Object/Worksheet]? Oder müsste ich dafür ein eigenes Makro erstellen und dann aufrufen?

2) Was ist genau der Unterschied zwischen Dim As Range, Dim As Object und Dim As Worksheet? Ich sehe da ganz verschiedene Herangehensweisen; was würde ihr weshalb empfehlen?

Bin gespannt auf Eure Antworten

Daniel

  

Betrifft: AW: ohne explicit von: Fennek
Geschrieben am: 28.03.2018 12:12:48

Hallo,

auch wenn dies gleich einen Aufschrei verurschen dürfte: das Einfachste ist es, auf Option explicit und alle Dim zu verzichten.

Meisten geht das und in den wenigen Problemfällen kann man immer noch dimensionieren.

mfg


  

Betrifft: Aufschrei!!!!! von: Daniel
Geschrieben am: 28.03.2018 12:49:18

ich halte diese Empfehlung für kompletten Bullshit.
ich sprech nur mal zwei Themenbereiche an:
- Vermeidung von ansonsten schwer auffindbaren Schreibfehlern
- Nutzung der IntelliSense auch mit Variablen.
das spart bei gerade bei längeren Codes viel mehr Tipparbeit, als ein paar Variablen zu deklarieren.

Gruß Daniel


  

Betrifft: reiß dich ma zusammen!..--> bullshit von: Oberschlumpf
Geschrieben am: 28.03.2018 12:56:47




  

Betrifft: AW: reiß dich ma zusammen!..--> bullshit von: Daniel
Geschrieben am: 28.03.2018 13:03:56

ok, wenns kein Bullshit ist?
was sind denn die Vorteile des Verzichts auf deine Deklaration, die so groß sind, dass die den Verlust er Intellisense und automatischen Rechtschreibprüfung für Variablennamen aufwiegen?
ein paar gesparte Codezeilen sind mir da zu wenig. Den Tippaufwand hole ich durch die IntelliSense schnell wieder rein.

Gruß Daniel


  

Betrifft: AW: reiß dich ma zusammen!..--> bullshit von: Oberschlumpf
Geschrieben am: 28.03.2018 13:44:40

es geht nicht darum, ob Option Explicit = sinnvoll oder nicht sinnvoll ist.
Mich ärgerte deine beleidigende Art, auf Fennek's Antwort zu reagieren.
Ich selbst finde es auch - immer - besser, Option Explicit zu verwenden...aus den von dir genannten Gründen. Aber deswegen schreib ich nicht, dass irgdwer BULLSHIT von sich gibt.


  

Betrifft: AW: reiß dich ma zusammen!..--> bullshit von: Daniel
Geschrieben am: 28.03.2018 13:59:25

kann sein.
aber Fennek schrieb "auch wenns gleich nen Aufschrei gibt"
was mich dann veranlasst hat, meine Meinung entsprechend deutlich und seinem Wunsch nach zu formulieren.
Außerdem bleibe ich dabei.
Die Empfehlung auf Option Explicit zu verzichten darf man gerade einem Anfänger nicht geben.
In sofern habe ich mich mit der Formulierung "Bullshit" eigentlich schon zusammengerissen.
klar kann man es höflicher formulieren. Wird aber nicht besser, wenn es inhaltlich das gleiche bleiben soll.


  

Betrifft: Empathie von: lupo1
Geschrieben am: 30.03.2018 20:40:32

Wenn jmd. sein "Vergehen" im Vorfeld einräumt, richtet ein anderer nicht mehr über das Vergehen.

Es sei denn, der Einräumer hätte den Umfang seines "Vergehens" gar nicht ganz erfasst (hat Fennek aber) ... dann kann man diese Argumente sachlich hinzufügen.


  

Betrifft: AW: Empathie von: Daniel
Geschrieben am: 31.03.2018 11:42:38

sicher?
würde das auch gelten, wenn dir jemand die Brieftasche klaut und und dies vorher ankündigt hätte?


  

Betrifft: Lieber: Bockmist, Humbug oder leeres Gerede ? von: EtoPHG
Geschrieben am: 28.03.2018 14:09:58

Hallo Thorsten,

Was bitte stört dich an Bullshit?
Schliesslich redet VBA auch english. Würdest du dann die deutschen Wörter:
Bockmist, Humbug oder leeres Gerede vorziehen?

Gruess Hansueli


  

Betrifft: AW: Lieber: Bockmist, Humbug oder leeres Gerede ? von: Oberschlumpf
Geschrieben am: 28.03.2018 14:11:38

Hi

mich stört die beledigende Art zu antworten!

Ciao
Thorsten


  

Betrifft: AW: Lieber: Bockmist, Humbug oder leeres Gerede ? von: Daniel
Geschrieben am: 28.03.2018 14:18:12

Ich danke jedenfalls für die deutlich geäusserte Warnung und bin - obwohl (noch) in den Anfängerschuhen - auch selber der Überzeugung, dass die Deklaration meistens sinnvoll ist. Und auch Fennek danke ich für die Zeit die er sich genommen hat und die Lösungsvorschläge.


  

Betrifft: AW: Lieber: Bockmist, Humbug oder leeres Gerede ? von: Daniel
Geschrieben am: 28.03.2018 14:37:48

naja, was heißt beleidigend?
das Bullshit war ja nicht an Fennek gerichtet, sondern personenunabhängig an die Empfehlung, auf OE zu verzichten. Außerdem habe ich meine Meinung fachlich begründet.
Mich würden eher unbegründete abwertende Aussagen stören.
Gruß Daniel


  

Betrifft: AW: Objektvariablen - Ein bisschen Theorie von: EtoPHG
Geschrieben am: 28.03.2018 12:42:30

Hallo Daniel,

In der Zeit, in der du auf eine Antwort wartest, hättest du das doch schon lang erledigt.
Darum verstehe ich Pkt 1) nicht.

2) Was ist genau der Unterschied... Das die Variable jeweils nur den definierten Typ von Daten aufnehmen kann, also eine Range = 1 oder mehrere Zellen des gleichen Blatts, ein Worksheet = 1 ein Tabellenblatt. Ein Objekt wird erst beim Set vom Typ her festgelegt.

Gruess Hansueli


  

Betrifft: AW: Objektvariablen - Ein bisschen Theorie von: Daniel
Geschrieben am: 28.03.2018 12:44:12

Hi
zu 1) meines Wissen nach nein.
du kannst aber den Code zum Dimensioneren in irgend einem anderen Textsytem erstellen, wenn dir das die Arbeit erleichtert.
du schreibst bspw in einem Tabellenblatt in Zelle A1:A70 "DIM " und in Zelle C1:C70 " as Range (mit ziehen)
dann trägst du dazwischen in Spalte B die Variablennamen ein und kopierst A1:C70 in den Code hinein.
spart zumindest schon mal Schreibarbeit, ggf fallen einem auch ein paar Formeln ein, die helfen den Code zu generieren.

zu 2) ich würde empfehlen, so genau wie möglich zu deklarieren.
wenn du eine Variable als Object deklarierst, kannst du ihr jedes Objekt zu weisen (Range, Worksheet, Workbook, Shape usw)
Wenn du eine Variable als Range(beispielsweise) kannst du ihr auch nur Range-Objekte zuweisen und bekommst ansonsten eine Fehlermeldung.

die Vorteile der genauen Deklaration sind:

1. der VBA-Editor hat die sog. IntelliSense als Eingabehilfe. Dh wenn du beim Schreiben des Codes STRG+LEER drückst (oder manchmal auch automatisch) dann geht eine Klappliste auf, welche dir alle an dieser Stelle möglichen Eingabeoptionen anzeigt, so dass du nicht tippen musst, sondern nur auswählen brauchst.
Dh wenn du die IntelliSense nach einem Worksheet-Objekt aufrufst, sieht die Liste anders aus als wenn du sie nach einem Range-Objekt aktiviert. Dazu muss die IntelliSense natürlich wissen, welcher Objekttyp gerade am Start ist.

hast du deine Variable also mit einem speziellen Objekttypen deklariert (Range, Worksheet, Workbook), dann kannst du die IntelliSense auch bei dieser Variable nutzen.
ist deine Variable nur allgemein deklariert (Object, Variant), dann steht dir die IntelliSense nicht zur Verfügung und du musst selber wissen, was du eingeben kannst.

2. wenn du versuchst einer speziell deklarierten Variablen einen falschen Objekttpyen zuzuweisen, bekommst du sofort eine Fehlermeldung (Typenunverträglichkeit). Das ist ein gewisser Schutz vor Programmier- und Logikfehlern, die ansonsten nur schwer auffindbar wären.
Deklarierst du nur allgemein (Object oder Variant) bekommst du dann bei der Zuweisung keine Fehlermeldung.

du solltest also wenn möglich die Variablendeklaration insbesondere bei den Objektvariablen so genau wie möglich machen, gerade bei "VBA bescheiden" ist die IntelliSense eine große Erleichterung.
"As Object" nur dann verwenden, wenn du es nicht besser weißt oder wenn du tatsächlich einer Variblen mehrere verschieden Objekttypen zuweisen willst.

Gruß Daniel


  

Betrifft: AW: Objektvariablen - Ein bisschen Theorie von: Daniel
Geschrieben am: 28.03.2018 13:03:06

Herzlichen Dank für Eure Antworten!

@ Fennek: Ist selbstverständlich möglich, aber gerade aus den bereits genannten Gründen für mich keine Option. Trotzdem danke für den Denkanstoss.

@ Hansueli: Danke für die Erklärung, das hilft mir sehr. Da liegst du natürlich richtig mit Deiner Antwort zu Frage 1, aber es geht mir ja auch darum, für zukünftige Projekte etwas zu lernen und so möglicherweise effizienter zu arbeiten. Deshalb bin ich immer für Inputs und Gedankenanstösse froh, manchmal hat man ja wirklich das sprichwörtliche Brett vor dem Kopf.

@ Daniel: Ganz herzlichen Dank auch Dir für die ausführliche und sehr hilfreiche Erläuterungen, das werde ich so beherzigen.

Vielen Dank Euch und noch "e schöns Tägli" - Daniel


  

Betrifft: AW: warum so viele? von: Fennek
Geschrieben am: 28.03.2018 13:11:13

Hallo,

warum werden so viele Variable gebraucht? Kann man das mit "Type declaration" vereinfachen?

mfg

_____________

type Adresse
    Name as string
    PLZ  as string
    Ort  as string
end type

sub MeinCode()
dim Adr(1000) as Adresse

...

end sub



  

Betrifft: AW: warum so viele? von: Daniel
Geschrieben am: 28.03.2018 13:26:32

Salü Fennek

Das ist eine gute Idee, probiere ich mal aus. Weshalb ich so viele Variablen brauche, hat mit dem Aufbau des Programmes zu tun: Mittels einer UserForm zu Beginn werden sehr viele Eingaben betätigt, die dann in verschiedentlicher Hinsicht auf die Tabelle Einfluss haben. Die vorzunehmenden Änderungen betreffen immer wieder ähnliche Zellen, so dass der Code unübersichtlich geworden ist. Insbesondere kann es sich auch ergeben, dass dereinst noch Zeilen oder Zellen gelöscht werden, weshalb ich durch die Definition von Objektvariablen einfach Änderungen vornehmen kann (z.B. ist objVariable nicht mehr = Sheets("Tabelle1").Range("A2") sondern .Range("A1"). Ansonsten müsste ich jede entsprechende Codezeile ändern.

Beste Grüsse - Daniel


  

Betrifft: AW: Erkläre das bitte besser von: Fennek
Geschrieben am: 28.03.2018 14:02:43

es ist möglich, dass man das anderst lösen kann (with sheets(1)), aber die Beschreibung ist zu ungenau für eine klare Empfehlung.


  

Betrifft: AW: Erkläre das bitte besser von: Daniel
Geschrieben am: 28.03.2018 14:10:37

Eine Lösung mit With habe ich auch schon probiert, jedoch passt es nicht. Eure Lösungsvorschläge und -erklärungen genügen mir vollauf, da will ich Dich nicht mehr mit der komplizierten Tabelle belästigen.


  

Betrifft: AW: Erkläre das bitte besser von: Daniel
Geschrieben am: 28.03.2018 14:10:39

Eine Lösung mit With habe ich auch schon probiert, jedoch passt es nicht. Eure Lösungsvorschläge und -erklärungen genügen mir vollauf, da will ich Dich nicht mehr mit der komplizierten Tabelle belästigen.


  

Betrifft: ....und wieder voll daneben! von: EtoPHG
Geschrieben am: 28.03.2018 13:27:00

Hallo Fennek,

Wieviel weniger Variablen definierst du denn mit deiner erneuten "Miss-Empfehlung" ?
Du machst Fruchtsalat und merkst es nicht. Also bitte von solchen Empfehlungen Abstand nehmen.

Gruess Hansueli


  

Betrifft: AW: suche nach guten Ansätzen von: Fennek
Geschrieben am: 28.03.2018 14:11:42

ich habe weder Lust noch Absicht, mich hier mit irgendjemand zu "fetzen", sondern bin auf der Suche nach guten Ansätzen.


  

Betrifft: AW: Objektvariablen - Ein bisschen Theorie von: Peter(silie)
Geschrieben am: 28.03.2018 13:31:51

Hallo,

ich geb auch noch meinen Senf dazu.

Was du willst ist ein Object Array, ich rate aber dringend davon ab.
In einem halben Jahr weiß niemand mehr, was was ist in dem Array.

Hier ein paar Beispiele:
(Dein Object Array findest du in: Sub FauleUndSchlechteVariante())

Option Explicit '<-- wer zu faul ist dafür sollte keinen Code schreiben

'Ein Enum ist ein Long Integer
'ist super für Zeilen und Spalten
'referenzen die Konstant sind
'Auch perfekt für IDs
Private Enum BeispielEnum
    Bsp_1
    Bsp_2
    Bsp_3
    ID = 100101001
End Enum

'Super wenn man mit Datensätzen arbeitet
'oder wenn man viele Spezielle Informationen
'in einem kleinen Objekt speichern möchte
Private Type BeispielType
    Bsp_1 As String
    Bsp_2 As Long
    Bsp_3 As Object
End Type


Sub BeispieleEnumUndType()
    Dim bt As BeispielType
    
    Debug.Print BeispielEnum.Bsp_1
    Debug.Print BeispielEnum.Bsp_2
    Debug.Print BeispielEnum.Bsp_3
    Debug.Print BeispielEnum.ID
    
    bt.Bsp_1 = "Hallo"
    bt.Bsp_2 = 1
    Set bt.Bsp_3 = ThisWorkbook.Sheets(1)
    
    DisplayType bt
    
End Sub

Private Sub DisplayType(ByRef bspT As BeispielType)
    
    Debug.Print bspT.Bsp_1
    Debug.Print bspT.Bsp_2
    Debug.Print bspT.Bsp_3.Name
    
End Sub



Sub FauleUndSchlechteVariante()
    Dim objArr() As Object
    
    ReDim objArr(1 To 70)

    'Keiner weiß was es ist
    '70 Objekte gespeichert in einem Objekt array...
    'na super, wenn ich mich später im Code wundere
    'was objArr(1) für ein Objekt ist, muss ich
    'dessen Initialisierung erst wieder Suchen.
    'Wartbarkeit auf gut Deutsch beschissen.
    Set objArr(1) = ThisWorkbook.Sheets(1)
    Set objArr(2) = objArr(1).Range("A1")
    
    Debug.Print objArr(1).Name
    Debug.Print objArr(2).Address
    
End Sub

Sub GuteVarianteInDenMeistenFaellen()
    Dim ws As Worksheet
    Dim rg As Range
    
    'Leute wissen was es für ein Object ist
    'IntelleSens funktioniert
    'Gut für Standard Objekte die von Anfang an
    'mitgeliefert werden
    'Kann griffigen Namen bekommen der sofort verrät
    'um was es sich handelt
    'Bsp.:
    'Worksheet mit Datensätzen = shData/ shDatasets
    'oder                      = wsData/ wsDatasets
    'Namen je nach belieben natürlich
    Set ws = ThisWorkbook.Sheets(1)
    Set rg = ws.Range("A1")
    
    Debug.Print ws.Name
    Debug.Print rg.Address
    
End Sub

Sub LatebindingVonObjekten()
    Dim xlApp   As Object
    Dim dict    As Object
    Dim arList  As Object
    Dim fso     As Object
    
    'Gut für Objekte aus fremden Libs
    'verhindert dass komplette Libs importiert werden
    'ich hatte heute ein Problem wegen einer Lib
    'wodurch der Client eine Access Runtime installieren wollte...
    'durch Latebinding wieder gefixt, da dann nur das gewollte
    'Objekt geholt wird aus der Lib
    '
    'Während du den Code schreibst, kannst du auch ruhig die
    'Libs importieren, aber am Ende wenn der Code fertig ist
    'solltest du die Referenzen durch Latebinding der Objekte
    'ersetzen
    Set xlApp = CreateObject("Excel.Application")
    Set dict = CreateObject("Scripting.Dictionary")
    Set arList = CreateObject("System.Collections.ArrayList")
    Set fso = CreateObject("Scripting.FileSystemObject")
    
    xlApp.Quit
    Set dict = Nothing
    Set arList = Nothing
    Set fso = Nothing
    
End Sub




  

Betrifft: AW: Objektvariablen - Ein bisschen Theorie von: Gerd L
Geschrieben am: 28.03.2018 18:32:51

Hallo Daniel,

neben Objekten gibt es Namen.

Gruß Gerd


  

Betrifft: AW: Objektvariablen - Ein bisschen Theorie von: snb
Geschrieben am: 30.03.2018 22:55:11

Ich verwette das (zu) viele Variabelen verwenden ein Indiz ist für ein mangelhaftes strukturiert Problem: 'structuring precedes coding'.
So lange der TS seine Datei (und Problem) verheimlicht ist es nur raten.
Und Fennek hat natürlich völlig recht: VBA is eine Sprache, kein Glaube. Option Explicit ist redundant.


  

Betrifft: AW: Objektvariablen - Ein bisschen Theorie von: Daniel
Geschrieben am: 30.03.2018 23:49:30

Salü snb, mir geht es keineswegs um das verheimlichen, sondern folgender Gedanke hat mich geleitet: Das hier ist ein Hilfe-Forum, d.h. es geht nicht darum, andere ein Programm für sich erstellen zu lassen. Ausserdem ist das Projekt ungemein umfangreich, das möchte ich niemandem zumuten.

Deinen Gedanken nehme ich gerne auf, denke aber, dass ich es gut durchdacht habe. Das Problem ist eher, dass ich gewisse, womöglich die Sache vereinfachende Programmierstrukturen, einfach noch nicht kenne.

Beste Grüsse - Daniel


  

Betrifft: AW: Objektvariablen - Ein bisschen Theorie von: Daniel
Geschrieben am: 31.03.2018 00:18:53

c = Range(...).value

erzeugt ebenfalls eine Redundanz.

Der Verzicht auf Option Explicit ist ein Indiz dafür, dass jemand unstrukturiert programmiert, weil es ohne Option Explicit nicht erforderlich ist, sich vorher Gedanken darüber zu machen welche Variablen benötigt werden und welche Werte sie aufnehmen sollen, sondern man einfach drauflos programmieren kann.
Die Verwendung von Option Explicit macht solche Vorüberlegungen erforderlich und fördert daher die strukturierte Problemlösung.


  

Betrifft: AW: Objektvariablen - Ein bisschen Theorie von: snb
Geschrieben am: 31.03.2018 10:48:14

Wass evident ist sollte man nie vernachlässigen. Dazu braucht man kein 'Option Explicit'. Die Strukturierung muss geschehen bevor man überhaupt etwas programmiert, also bevor von 'Option Explicit' die Rede sein kann.


  

Betrifft: AW: Objektvariablen - Ein bisschen Theorie von: Daniel
Geschrieben am: 31.03.2018 11:31:42

naja, wenn man sein problem sauber strukturiert hat und die Variablen kennt, die man verwenden will, dann ist es ja kein Problem, die im Code nochmal aufzuschreiben, Option Explicit zu aktvieren und die Vorteile zu nutzen, die diese Option mit sich bringt.