Office: Dateien in unterschiedliche Tabellenblätter kopieren.

Hallo!

 

Hallo!

Du hast in den Zeilen mit den PASTE-Methoden das ACTIVEWORKBOOK-Objekt verwendet, was bedeutet, dass Du damit auf das Excel-WORKBOOK der jeweils geöffneten Excel-CSV-Datei zugreifst. Um aber auf das WORKBOOK der Excel-Datei, in der sich das Makro und die dazugehörigen Arbeitsblätter "NEG_HT", "NEG_NT", usw. befinden, zuzugreifen, musst Du die THISWORKBOOK-Methode verwenden.

Nachfolgend habe ich Dir beispielhaft die beiden Inhalte der FULLNAME-Eigenschaften vom ACTIVEWORKBOOK bzw. THISWORKBOOK in der 1. PASTE-Zeile dargestellt (wie sie im DIREKT-Bereich des VBA-Editors angezeigt werden, wenn man beim 1. PASTE einen Breakpoint setzt):
?activeworkbook.FullName
C:\Forum\Quellen\ERGEBNISLISTE_ANONYM_SRL_2011-01-01 (Done).CSV
?thisworkbook.FullName
C:\Forum\Denjiro_Quellen.xlsm

 

die Syntax von copy ist, grob gesagt:

Code:

range1.copy destination:=range2

Du könntest also etwas in der Art machen (und damit den Code etwas vereinfachen):

Code:

.Range(.Cells(2, 1), .Cells(loCounterNEGHT, loLetzteSpalteCSV)).Copy _ 
destination:=ActiveWorkbook.Worksheets("NEG_HT").Cells(loLetzteZeileNEGHT + 1, loSpalteNEGHT)

Ich würde eigentlich sogar noch weiter gehen und Objekt-Variablen für die Ranges setzen, damit der ganze Kladderadatsch übersichtlicher wird:

Code:

dim r1 as range
dim r2 as range
[...]
set r1 = .Cells(loCounterNEGHT, loLetzteSpalteCSV))
set r2 = ActiveWorkbook.Worksheets("NEG_HT").Cells(loLetzteZeileNEGHT + 1, loSpalteNEGHT)
r1.copy destination:= r2

Dafür braucht es dann aber mindestens die Voraussetzung: Das Blatt "NEG_HT" muß bereits existieren, denn der Range-Copy legt kein neues Blatt an. (Das Worksheet-Copy würde ein neues Blatt anlegen...) Wenn also das "paste" versucht, das Blatt "NEG_HT" anzusprechen und es existiert nicht, kommt es zu dem von Dir genannten Fehler.

Im Übrigen ist es auch ein bißchen bedenklich, eine globale Variable (strFile) zu benutzen, damit die 2. Routine weiß, welche Datei die 1. Routine geöffnet hat. Da würde ich lieber den Aufruf der 2. Routine mit dem Dateinamen als Parameter erweitern. Aber das ist mehr stilistisch...

Gruß, Michael

 

Vielen Dank für die Hilfe! Ich werde es am Freitag ausprobieren und Rückmeldung geben.

 

Hallo Michael,

Du weißt, dass ich gerne dazu lerne. Deshalb bitte als Wissensfrage und nicht als ... (keine Ahnung, Kindergarten halt) verstehen. (den Code hatte ich damals geschrieben)
;O)

Der erzielte Gewinn erschließt sich mir nicht, das ist doch kein Bisschen kürzer oder übersichtlicher als die andere Variante.
Wär lieb wenn Du das noch ein wenig genauer erklären würdest.



Hingegen dieses:

ist mir sofort eingängig.




Kannst Du dies:

eventuell auch noch ein wenig genauer ausführen?
Warum bedenklich? (Ich habe damit bisher nie Probleme gehabt.. okay, ich achte aber auch immer peinlich auf meine Variablen...)
Wie wäre es Deiner Meinung nach besser?


Im Voraus schon mal Danke.

 

Hallo Denjiro,

Du brauchst mich nicht per PM zu bitten. Wenn ich Zeit (und Lust) habe, sehe ich Deine Frage auch im Forum.
;O)

Für den Fall dass Du es nicht selber hinbekommst, habe ich den ursprünglichen Code wie folgt abgeändert:
1. wird überprüft ob die 4 Tabellenblätter existieren, wenn nicht werden sie erstellt, allerdings wird die Blattreihenfolge nicht sortiert, da ich nicht weiß wie Du es brauchst und was sonst noch alles in der Datei ist
2. werden die Daten entsprechend auf die 4 Blätter verteilt

Den Anhang SRL 2011.xlsm betrachten



@all
Verbesserungsvorschläge oder Vereinfachungen sind gerne gesehen.

 

Hallo Achim!

 

Der Unrterschied ist marginal, kann aber in besonderen Fällen entscheidend sein. Aber grundsätzlich haste Recht: Der Unterschied ist minimal und die Auswirkung in 99 und mehr Prozent nicht zu spüren. Es hat in erster Linie was mit Timing-Problemen, quer einschießenden Prozeduren usw. zu tun. zwischen "r1.copy" und "r2.paste", also in 2 Source-Zeilen, kann es passieren, daß irgendein anderer Prozess Dir die Zwischenablage löscht oder sogar so verändert, daß es Dir die Mappe zerschießt. Mit "r1.copy destination:=r2" in einer Zeile kann das nicht passieren.

Naja, das ist eine grundlegende Geschichte... globale Variablen sind per se böse und gehören in den gleichen Sack wie GOTO. ;-) Vermeide sie, wo immer es möglich ist. Ansonsten wird sich der Himmel blutrot färben, die Wolken reißen auf, 7 Reiter der Apok... ach ne, halt, das war bei GOTO... Bei globalen Variablen gibt's nur schlechtes Wetter. ;-)

Das Problem bei diesen globalen ist, daß man sich zu leicht verhauen kann und eigentlich eine Prozedur-lokale Variable benutzen möchte, die man nur im DIM vergessen hat. Schwupps hat man sich die Modul-globale Variable zerhauen und wundert sich, wieso die Routine in Modul3 nicht c:\temp\*.txt sondern c:\windows\*.dll löscht...

Es ist, ganz banal gesagt, eine Frage der Notwendigkeit. Wenn ich eine Variable (Das gilt für SUBs übrigens auch...)nicht zwingend global brauche, dann mach ich sie eben auch einfach nicht global. Klar, die Zählervariable "x" brauche ich vielleicht in 23 SUBs und muß sie dann immer und immer wieder neu DIMen. Mit einer globalen "x" könnte ich mir das sparen. Aber quer diagonal laufende Schleifen machen die Sache auch nicht unbedingt besser. ;-)

Wobei, technisch gesehen schätze ich, daß VBA beim Zählschleifen-Start mit einer Kopie der Laufvariablen und Endbedingung arbeitet, hab's aber noch nicht explizit ausprobiert. Setz mal bei "for x=1 to 10 ... next x" eine Zeile "x = 2" in die Schleife. Läuft das Ding endlos, dann könnte Dir das mit einer globalen auch passieren. Nächster Test wäre dann "y = 10 : for x=1 to y ... next x" mit einer Zeile "y = x+2" dazwischen. Auch hier könnte VBA endlos (naja, bis "overflow") laufen, wenn irgendeine andere Prozedur die globale "y" verändert.

Also statt

Code:

dim x as long

public sub schwatzbrabbel
    msgbox x
end sub

public sub laber
    x = 15
    schwatzbrabbel
end sub

[...]

laber

dann doch lieber

Code:

private sub schwatzbrabbel([byval] n as long)
    msgbox n
end sub

public sub laber
    dim x as long
    x = 15
    schwatzbrabbel x
end sub

[...]

laber

Gruß, Michael

 

Hallo Michael,

danke für die Erklärung, klingt einleuchtend.
Wobei ich manchmal schon den Fall hatte, dass ich etwas kopiere, dann noch ein - zwei andere Befehle ausführen lasse, und dann erst wieder einfüge. Einfach um den Code etwas übersichtlicher zu halten, oder weil es (für mich) sonst einen Sinn gemacht hat.
In dem Fall wäre es natürlich schwierig von zwei- auf einzeilig zu wechseln, bzw. man müsste seine Code-Struktur überdenken.
(wobei ein Profi nach einem Blick auf meine Strukturen wohl eh nur noch am Haareraufen wäre...)
;O)

Okay, wenn man nicht haargenau aufgepasst, und das geht schneller als wir es wahrhaben wollen..., passieren plötzlich "lustige Dinge".
Leider habe ich nie strukturiert programmieren gelernt, von daher weiß ich nicht wie es als sinnvoll angesehen wird einen komplexen Code aufzubauen.
Für mich selber habe ich mir inzwischen angewöhnt ein "Ablauf-Steuerungs-Sub" zu benutzen, wo fast ausschließlich nur andere Subs und Funktionen aufgerufen werden.
Die meisten Aufgaben vor denen ich bisher stand konnte ich gut in eine Reihenfolge "zwängen" und diese mit dem genannten Sub schön und übersichtlich steuern.
Dadurch konnte ich mir auch globale Variablen "leisten", denn ich konnte gut nachvollziehen wann eine Variable wo und wofür gebraucht wird, konnte mir das ständige "dim" sparen, und bequem Werte von einem zum anderen Sub übergeben.
Allerdings, ich sehe den Sinn hinter Deiner Erklärung, sehe meine eigene Faulheit und die Gefahr...

Danke auch für diese erhellenden Worte.
;O)

 

hi hi hi... Zumindest früher, als BASIC noch unter DOS in elend langen Sourcecodes mit haufenweise GOTO ausartete, nannte man diese Hin- und Her-Spring Abläufe dann "Spaghetti-Code", weil es nahezu unmöglich war, den Ablauf wieder zu entwirren. Aber andererseits, auch heute, im Zeitalter der (sehr viel mehr) strukturierten Programmierung ist es immer noch eine Herausforderung, sich den Source eines anderen anzusehen und zu verstehen, was der eigentlich machen soll.

Code:

Für mich selber habe ich mir inzwischen angewöhnt ein "Ablauf-Steuerungs-Sub" zu benutzen, wo fast ausschließlich nur andere Subs und Funktionen aufgerufen werden.

Das ist auch, mal so ganz generell, eine gute Idee. Denn letztendlich, auch wenn man in Schulungen heute eher sagt, daß das "EVA"-Prinzip nicht mehr aktuell ist, läuft es trotzdem doch immer noch nach genau dem ab: (E)ingabe, (V)erarbeitung, (A)usgabe...

Und ich habe in meinen Pascal-Schulungen den Leuten meist genau über dieses Prinzip den Sinn und den Vorteil von Aufteilungen des Haupt-Programms in einzelne Prozeduren deutlich gemacht. Auch dort bestand das "Hauptprogramm" dann meist nur noch aus:

Code:

begin
  eingabe;
  verarbeitung;
  ausgabe;
end.

Ok, mit Ereignis-gesteuerten Abläufen geht das dann natürlich nicht mehr ganz so strikt, zumindest nicht auf den ersten Blick. Aber wenn man es genau nimmt, folgt jedes einzelne Ereignis, das ausgelöst wird, dann auch wieder EVA.

Code:

Dadurch konnte ich mir auch globale Variablen "leisten", denn ich konnte gut nachvollziehen wann eine Variable wo und wofür gebraucht wird, konnte mir das ständige "dim" sparen, und bequem Werte von einem zum anderen Sub übergeben.

Das Problem ist, daß man es eben nicht mehr unbedingt nachvollziehen kann, wenn Ereignisse ausgelöst werden. Während Deine Routine gerade die Zeilen 1..12000 (mit einer Zählvariablen "y") durchackert und in einer Spalte (Variable "x") etwas berechnet, kann das Ereignis "SelectionChange" die aktuelle Cursorposition in "x" und "y" ermitteln, um z.B. ein rotes Stern-Shape um die Zelle zu platzieren. Wenn x und y jetzt global sind...

Ok, der "unschöne" Weg ist, in der Berechnungs-Schleife andere Ereignisse zu unterbinden. Wenn man noch das ScreenUpdating ausschaltet, denkt der User dann wahrscheinlich endgültig, daß Excel sich aufgehangen hat. Aber zumindest zerhackt's Dir nicht mehr Deine Variablen. ;-)

Ein anderes Argument gegen globale Variablen fällt mir zumindest mit Pascal-Begründung ein, ich weiß aber jetzt aus'm Stegreif nicht, wo die Grenzen bei VBA sind: In Pascal darf jede "unit" (entspricht quasi einem Modul in VBA) nur eine Gesamt-Menge an globalen Variablen von 64 kb haben (ja, kb, nicht mb oder gb). Allerdings: Jede Prozedur darf für sich ebenfalls wieder 64 kb lokale Variablen haben. Da überlegt man sich schon sehr genau, welche globalen Variablen man wirklich braucht. ;-) So blöde eng diese Beschränkung also auch sein mag, sie zwingt einen zu etwas mehr "Sauberkeit" im Code.

Gruß, Michael

 

Solchartiges weise ich denn dann doch entschieden von mir und bestreite dieses Unwort jemals benutzt zu haben!
;O)))
Nee, hast ja recht, ist mir dann ja auch selber viel zu viel Wirrwar.
Haber "Goto" bisher nur ganz spärlich benutzt, wenn durch Abfragen bestimmter Bedingungen geklärt wird, das man sich den nächsten Teil des Codes schenken kann, er nur Zeitverzögerung wäre.
Alles innerhalb der gleichen Prozedur und auch keine großen Sprünge.

Ich hab ja schon Probleme bei dem was ich selber vor zwei Jahren geschrieben habe.

Prinzipiell geb ich Dir recht, es birgt Gefahren.
Andererseits, wenn man es wirklich konsequent durchzieht, "select" u.ä. vermeidet, den Source auch wirklich mal im Einzelschrittmodus durchläuft... und... und ... und.... finde ich persönlich es teilweise einfach bequemer und lebe mit der Gefahr.
Ich benutze ja nicht nur globale, aber eigentlich doch gerne und häufig.

Immerhin darfst Du Dir jetzt anrechnen, dass ich so einige Dinge nocheinmal überdenken und beim nächsten Mal vielleicht anders machen werde.
;O)


Übrigens, eine Beschränkung der variablen habe ich bisher noch nicht festgestellt.
Wenn da jemand etwas zu wüsste, würde mich das sehr interessieren.