Heute habe ich gleich 3 Fragen auf einmal zu Excel - das geht nun wirklich nicht *g*...
"Einmal Makro - immer Makro"? Wenn ich ein Makro nicht mehr benötige und es im Visual-Basic-Editor allergründlichst mit Strunk und Stiel entferne, so erscheint trotzdem in Zukunft immer bei jedem Öffnen des Excel-Sheets die Frage "Diese Datei enthält Makros, sollen diese aktiviert werden?" - ist das normal so? Muss man erst ein neues Sheet aufmachen und die Daten aus dem alten dort hineinkopieren? Oder wo setzt Excel dieses "Makro-Flag"?
Um die Nachkommastellen einer Zahl zu berechnen, nehme ich immer die Formel =A1-GANZZAHL(A1) - aber gibt es da keine elegantere Methode? In der Excel-Hilfe konnte ich jedenfalls keinen eigenen Befehl dafür finden.
Zahlen aus Zeichenketten auslesen - auch hier wieder die Frage, ginge es auch eleganter? Z.B. Wenn ich eine Zeichenkette habe wie "10:12:15" und die - übrigens nicht zwangsläufig immer *zwei*stelligen! - Zahlen dort auslesen möchte, um sie auf jeweils eine eigene Zelle zu verteilen, geht das nur mit den String-Befehlen LINKS, RECHTS und FINDEN (=> nämlich den ":" als Trennzeichen?) Ich vermute stark "ja", aber fragen kostet ja nichts.
Ihr wisst bestimmt wie immer gut Bescheid, deswegen gleich im Vorwege:
"Einmal Makro - immer Makro"? Wenn ich ein Makro nicht mehr benötige und es im Visual-Basic-Editor allergründlichst mit Strunk und Stiel entferne, so erscheint trotzdem in Zukunft immer bei jedem Öffnen des Excel-Sheets die Frage "Diese Datei enthält Makros, sollen diese aktiviert werden?" - ist das normal so? Muss man erst ein neues Sheet aufmachen und die Daten aus dem alten dort hineinkopieren? Oder wo setzt Excel dieses "Makro-Flag"?
Ist das so? Ist mir noch gar nicht aufgefallen.
Eine Lösung habe ich dementsprechend nicht.
Was mir allerdings auffällt ist, dass die weitaus meisten "Excelianer" von "Makros" reden obwohl es sich dabei um waschechte VBA-Scripte handelt; die alte Makrosprache gibt es in Excel nicht mehr. Das letzte Office-Programm, das noch die alte Makrosprache enthält, ist Access.
Um die Nachkommastellen einer Zahl zu berechnen, nehme ich immer die Formel =A1-GANZZAHL(A1) - aber gibt es da keine elegantere Methode? In der Excel-Hilfe konnte ich jedenfalls keinen eigenen Befehl dafür finden.
Nö, gyps nicht.
Zahlen aus Zeichenketten auslesen - auch hier wieder die Frage, ginge es auch eleganter? Z.B. Wenn ich eine Zeichenkette habe wie "10:12:15" und die - übrigens nicht zwangsläufig immer *zwei*stelligen! - Zahlen dort auslesen möchte, um sie auf jeweils eine eigene Zelle zu verteilen, geht das nur mit den String-Befehlen LINKS, RECHTS und FINDEN (=> nämlich den ":" als Trennzeichen?) Ich vermute stark "ja", aber fragen kostet ja nichts.
Was mir allerdings auffällt ist, dass die weitaus meisten "Excelianer" von "Makros" reden obwohl es sich dabei um waschechte VBA-Scripte handelt; die alte Makrosprache gibt es in Excel nicht mehr.
Seit Excel 5 werden Makros mit der Sprache VBA aufgezeichnet. Deswegen sind es doch trotzdem Makros. Ob nun VBA oder eine andere Makrosprache verwendet wird, ist doch für die Bezeichnung "Makro" egal.
Natürlich kann man mit VBA auch selbständig programmieren, ohne irgendwelche Schritte in Excel aufzuzeichnen. Dann spricht man eher von VBA-Scripten statt von Makros.
Seit Excel 5 werden Makros mit der Sprache VBA aufgezeichnet.
Ach, das ist ja mal ganz was neues.
Deswegen sind es doch trotzdem Makros. Ob nun VBA oder eine andere Makrosprache verwendet wird, ist doch für die Bezeichnung "Makro" egal.
Mag sein. Das meinte ich aber nicht.
Und n enin, MIR ist das nicht egal. Ich weigere mich eine VBA_Sequenz "Makro" zu nennen, nur weil sie mit dem Excel-Macrorecorder aufgezeichnet wurde (mal ganz abgesehen davon, dass der nur bedingt taugt).
Und davon ganz abgesehen nennen viele Excelianer auch komplexere VBA-Programme "Makro" obwohl das sachlich völlig falsch ist.
Und genau hier erschliesst sich mir nicht, warum die das tun.
Lösch mal im VB Project das Dokument, hilft vielleicht.
Für mich ist Formel und Makro das gleiche.
Eine VBA Funktion wird zu einem Makro wenn ich sie aus der Zelle mit =MyVBAFunc() aufrufe.
Rufe ich die Funktion als Makro auf bedeutet das auch diverse Einschränkungen
innerhalb dieser Funktion.
Wenn du ein globales Modul hinzufügst im VBA Project kannst du öffentliche Funktionen die du dort
schreibst auf die Art in Excel Zellen nutzen. Einige Leute in meiner Firma nennen das Makros andere Formeln und wiederum andere wahrscheinlich wieder anders.
Mit einer Formel können bestimmte Berechnungen ausgeführt werden.
Mit einem Makro werden Bearbeitungsschritte in Excel aufgezeichnet, um sie zu einem späteren Zeitpunkt mit wenig Aufwand ausführen zu können. Ein Makro wird (seit Excel 5) immer mit VBA aufgezeichnet, insofern ist ein Makro im Prinzip so etwas wie ein "Programm". Eine Formel ist kein Programm...
Es gibt allerdings einen Berührungspunkt zwischen beidem: Wenn Du in Excel eine benutzerdefinierte Funktion erstellen willst, erstellst Du die ebenfalls mit VBA. Anschließend steht die Funktion dann auch über "Einfügen" > "Funktion" zur Verfügung.
Dann ergibt sich auch automatisch die von Olaf beschriebene Sicherheitsabfrage (es sei denn, die Sicherheit wurde vorher auf niedrig gesetzt oder Du arbeitest mit signierten VBA-Scripten).
Japp - genau so etwas meinte ich mit "Strunk und Stiel ausrotten". Hat aber nichts genützt.
Übrigens, wenn ich in einem Excelsheet Formeln benutze - und die gibt es in praktisch allen Sheets in sehr reicher Zahl - dann erhalte ich keinerlei Makro-Warnung. Das ist wirklich nur dann, wenn ich eine Kette von Maus- und Tastaturereignissen aufgezeichnet habe.
[Ich beziehe mich jetzt auf Excel 2003; in den direkten Vorgängerversionen sollte es ähnlich sein; wie es in Excel 2007 ist, habe ich noch nicht ausprobiert.]
Das Löschen über "Extras" > "Makro" > "Makros" reicht nicht, es bleibt dann immer noch das (leere) Modul übrig, in dem das Makro ursprünglich stand. Und das reicht, um beim Start von Excel die Sicherheitsabfrage zu provozieren.
Du musst im VBAProject (Projektexplorer) das Modul löschen, in dem das aufgezeichnete (oder selbst programmierte) Makro steht (oder stand).
Das Löschen dieses Moduls geht über einen rechten Mausklick und dann "Entfernen von Modul...". Du kannst dann wahlweise das Modul vor dem Löschen auch noch exportieren.
=A1-GANZZAHL(A1) - aber gibt es da keine elegantere Methode?
Ich finde das doch schon ziemlich elegant - mir ist nichts Eleganteres dafür bekannt.
Wenn ich eine Zeichenkette habe wie "10:12:15" und die - übrigens nicht zwangsläufig immer *zwei*stelligen! - Zahlen dort auslesen möchte
Kommt darauf an, in welchem Zusammenhang Du die Trennung dieser Inhalte brauchst. Es geht zunächst mit den beschriebenen Zeichenkettenfunktionen.
Möglich wäre aber auch die Verwendung von "Daten" > "Text in Spalten...". Dann erscheint der Textkonvertierungsassistent, der Dir verscheidene Fragen stellt und mit dem Du solche Angaben wie in Deinem Beispiel spielend trennen kannst. (Trennzeichen "Andere" und dort ":" eingeben)
Voraussetzung ist allerdings, dass die Zellen rechts neben den zu trennenden Inhalten leer sind, sonst werden evtl. vorhandene Daten überschrieben.
...ihr habt euch ja fast noch mehr reingekniet in das Thema als ich selber *schäm*...!
A1-GANZZAHL(A1) ist deswegen nicht elegant, weil ich die eine Funktion (Nachkommastellen) wünsche, in Wirklichkeit aber in deren Ermangelung eine andere benutze. Ich hatte vor zig Jahren einen programmierbaren Taschenrechner, der hatte eine FRAC-Funktion zur Lieferung aller Zahlen nach dem Punkt. Ich dachte, so etwas gäbe es vielleicht auch in Excel.
Sehr pfiffig ist aber die Idee mit dem Textkonvertierungsassistenten, da bin ich mir 99% sicher, dass das funktioniert. Ich kann ja einfach den ":" als Trennzeichen festsetzen, anstelle von Semikolon oder Komma.
ahlen aus Zeichenketten auslesen - auch hier wieder die Frage, ginge es auch eleganter? Z.B. Wenn ich eine Zeichenkette habe wie "10:12:15" und die - übrigens nicht zwangsläufig immer *zwei*stelligen! - Zahlen dort auslesen möchte, um sie auf jeweils eine eigene Zelle zu verteilen, geht das nur mit den String-Befehlen LINKS, RECHTS und FINDEN (=> nämlich den ":" als Trennzeichen?) Ich vermute stark "ja", aber fragen kostet ja nichts.
Mir fällt dazu noch die VBA-Funktion "Split" ein; Split trennt einen String beliebiger Länge am angegebenen Trennzeichen auf und schreibt die entstehenden Teile in ein Array; du musst daher die Ergebnisvariable als nichtdimensioniertes Array vorab deklarieren.
Aus der Hüfte geschossen, da ich hier kein Excel habe:
Obiges sollte dir von oben nach unten 10, 12, 15 in das Direktfenster des VBA-Editiors schreiben.
Das Problem ist, dass du dir damit keine benutzerdefinierte Funktion erstellen kannst, denn die darf nur exakt einen Wert zurückgeben.
Oder doch; du musst halt nur die Möglichkeit einbauen, selber anzugeben, welche Zahl dir die Funktion zurückgeben soll; wieder aus der Hüfte geschossen, wie du das für eine benutzerdefinierte funktion genau machen musst, musst du selber herausfinden (alternativ schaue ich das für dich am Montag nach ;) )
Public Function ZahlAusString(string, zahlposition)
Dim A() as String
A=Split(string,":")
ZahlAusString=a(zahlposition-1) 'so kannst du oben als Position "3" eingeben
beachte: Arrays fangen immer mit Index 0 an.
Aufgerufen mit deinem Beispiel sähe das z.B. so aus:
ZahlAusString("10:12:15",3)
Rückgabe sollte "15" sein
Teste das mal durch, bei Fragen: immer zu, ich lese auch in der 4ma hier mit ;)
Sorry Volker, aber das werde ich nicht probieren - das ist mir zu wirr...
Ich wollte jetzt nicht tief in die VBA-Programmierung einsteigen, mir ging es nur darum, "verborgene" Excelfunktionen zu finden, die mir die Suchfunktion bisher verschwiegen hat. Wenn es da eh nichts gibt und ich sowieso etwas basteln müsste, dann kann ich auch gleich die bisherige Methodik weiter verwenden. Zumal, wenn man einmal mit Links-Finden-Rechts klargekommen ist, kann man die Formel ja immer weiterkopieren.
Trotzdem THX für deine sehr ausführlichen Antworten, den Link mit der Formelsammlung muss ich noch studieren!
Nee, da sind keine anderen Makros drin. Wenn ich ein leeres Excelchart aufmache, erscheint die Warnung nicht. Wenn ich ein Makro aufgezeichnet habe, dann erscheint sie. Wenn ich dieses lösche, erscheint die Meldung *trotzdem* noch - und das ist einfach nur unlogisch. Falls wirklich noch für mich unsichtbare Makros irgendwo herumschwirrten, dann hätte die Warnung ja schon kommen müssen, bevor ich zum ersten Mal ein Makro aufgezeichnet habe.
Eigene Nachkomma-Funktion: könnte ich zwar kreieren, aber dadurch wird die Sache nicht unbedingt einfacher. Ist aber auch nicht weiter schlimm, wenn ich weiß, dass Excel keine eigenständige Funktion zur Verfügung stellt, kann ich mit dem kleinen Workaround leben, so oft brauche ich das dann auch nicht.
hallo Olaf,
warum willst du deine vom Taschenrechner bekannte FRAC-Funktion nicht einfach so erstellen?
Dann bräuchtest du nachher einfach nur FRAC angeben, wie du es gewohnt warst.
Und du hast damit direkt eine Basis für andere selbst geschriebene Funktionen, z.B. für dein Zeichenketten Problem.
Eigene Nachkomma-Funktion: könnte ich zwar kreieren, aber dadurch wird die Sache nicht unbedingt einfacher.
Du solltest auch folgendes beachten:
Wenn nicht sowieso auch andere Makros in der Datei sind, würde ich die benutzerdefinierte Funktion auch deswegen vermeiden, weil sie ja wieder die Sicherheitsabfrage beim Öffnen provoziert.
Solange man nur selbst damit arbeitet, ist das nicht so tragisch. Aber wenn man die Datei anderen Nutzern gibt, kommt natürlich beim Hinweis auf potentielle Makroviren schnell ein ungutes Gefühl auf.
Vermeiden könnte man das, wenn man die Sicherheitsstufe auf "Niedrig" setzt, was man beim eigenen Rechner ja noch machen kann, nicht aber bei Fremdrechnern.
Oder man verwendet digitale Signaturen, was aber auch ein umständliches Prozedere ist.
Fazit: Solange keine großartigen Vorteile davon zu erwarten sind, sind Makros (oder VBA-Scripte) incl. benutzerdefinierte Funktionen eher zu vermeiden. Dein Workaround ist da die bessere Alternative.
Wenn nicht sowieso auch andere Makros in der Datei sind, würde ich die benutzerdefinierte Funktion auch deswegen vermeiden, weil sie ja wieder die Sicherheitsabfrage beim Öffnen provoziert.
Deswegen zielte meine Frage nur in die Richtung, ob mit den "Bordmitteln" von Excel so etwas möglich ist. Klar, man selber kann sich abgedrehte Funktionen stricken ohne Ende, keine Frage.
Und hast Du nun auch das Modul gelöscht? Solange das Modul existiert, existiert auch die Makromeldung.
Was mir allerdings auffällt ist, dass die weitaus meisten "Excelianer" von "Makros" reden obwohl es sich dabei um waschechte VBA-Scripte handelt; die alte Makrosprache gibt es in Excel nicht mehr. Das letzte Office-Programm, das noch die alte Makrosprache enthält, ist Access
Dieses Thema hatten wir doch schon. Siehe Makro auf Wikipedia. Hier mal ein Auszug:
Zitat:
Makro stammt aus dem Griechischen (μακρος makros) und bedeutet „groß“ oder „weit“.
Unter einem Makro versteht man ein Programm, das eine fest vorgegebene Folge von Befehlen, Aktionen oder Tastaturcodes enthält. Alle Anweisungen des Makros werden automatisch ausgeführt, wenn das Makro entweder mit Hilfe eines Tastenschlüssels oder mit Hilfe eines Menünamens aufgerufen wird.
Zitatende:
Die Bezeichnung "Makro" ist korrekt, die Bezeichnung "Script" ist hier falsch. Obwohl es sich bei VBA um kleine Programme handelt. Man könnte also sagen dass weder "Makro" noch "Skript" richtig sind.
Hast Du Verweise auf Bibliotheken drin? Auch die Verweise müssen raus, falls das nicht automatisch geschieht. Bis auf die Standardverweise, die lassen sich nicht deaktivieren.
Dürfte eigentlich nicht sein - das Makro war selbst geschrieben und bestand im Wesentlichen aus dem Herauslöschen nicht benötigter sowie Umgruppieren und Umformatieren der verbliebenen Spalten mit abschließender Sortierung aller Daten. Also ganz simpel... daran kann es nicht gelegen haben.
Allerdings kann ich die Datei nun nicht mehr weiter untersuchen, da ich ihren Inhalt damals gleich in eine neue umkopiert hatte und die alte Datei gelöscht habe. Ich wollte nur wissen, ob ich in Zukunft evtl. etwas besser machen kann.
Wenn ich mir jedoch ein komplexes Programm schreibe und auf einen button lege, ist das definitv kein Makro mehr.
Laut MS-Definition sind es Makros. Auch OOo spricht teilweise von Makros. Wenn es kein Makro ist oder sein soll, dann ist es aber auch kein Script mehr. Denn auch Skripte sind makroähnliche Gebilde mit minimalen Codezeilen. Eines meiner Add-Ins hat 2651 Zeilen VBA-Code, 336 Zeilen Code in zwei customUI-Dateien (RibbonX) und 17 Zeilen Code in der userCustomization (QAT). Das größte "Makro" hat 337 Zeilen. Da kann man weder von Makros noch von Scripts bzw. Scriptlets sprechen. Das ist schon ein mittelgroßes Programm.
Aber egal wie man es nennt, funktionieren muss es. Solange es wie gewünscht funktionert kann man es nennen wie man will. Der Begriff "Makro" hat sich in VBA und Starbasic eingebürgert. Ist wie mit dem Finanzamt. Eigentlich müsste es "Steuerabrechnungs-Agentur" heissen, da Finanzamt IMHO nicht wirklich passt. ;-)
Der Begriff "Makro" hat sich in VBA und Starbasic eingebürgert
Ich kenne nicht einen einzigen Access-Entwickler, der seine VBA Routinen "Makro" nennen würde. Diese Eigenart beobachte ich nur bei den Word und Excel Leuten.
Ich kenne nicht einen einzigen Access-Entwickler, der seine VBA Routinen "Makro" nennen würde. Diese Eigenart beobachte ich nur bei den Word und Excel Leuten.
Ist ja auch klar: In Access sind MAKROS ja auch keine VBA-Routinen; die stecken ja in den sog. MODULEN. Hier ist ein Makro ja etwas ganz anderes, als in Word oder Excel.
ich bin mir sicher: Wir werden uns wohl nie einig werden!
(Muss ja auch nicht...)
Soweit ich weiß, sind Makros in Access Listen, in denen irgendwelche Aktionen verzeichnet sind. (Einen Makrorecorder gibt es in Access ja nicht.) Diese Makros kann man in VBA-Code umwandeln. Aber bevor ich das tue, haben die noch nichts mit VBA zu tun.
Jetzt bin ich gespannt, was Du daran wieder auszusetzen hast!
Soweit ich weiß, sind Makros in Access Listen, in denen irgendwelche Aktionen verzeichnet sind. (Einen Makrorecorder gibt es in Access ja nicht.) Diese Makros kann man in VBA-Code umwandeln. Aber bevor ich das tue, haben die noch nichts mit VBA zu tun.
So, ich war vorgestern etwas zu schnell.
Access ist das einzige Programm der MS office Suite, das tatsächlich noch zwischen "Makros" und VBA unterscheidet.
Richtig, einen Makrorecorder gibt es nicht - und gab es nie.
Ebensowenig wie es je einen Grund gab, unter Access Makros anzufassen ;)
(Nicht ganz: unter Access 2.0 waren verschiedene Dinge, z.B. selbsterstellte Benutzermenü, nur mit Makros möglich - die dann von VBA aus aufgerufen wurden. Das hat sich mittlerweile aber drastisch geändert; seit Access 97 gibt es keinen Grund mehr, noch irgendwas mit Makros zu machen)
Makros lassen sich tatsächlich nach VBA umwandeln - wer noch damit arbeitet, sollte das auch tun, denn Makros stehen bei MS schon länger auf "deprecated" und es ist eigentlich nur eine Frage der zeit, wann sie aus Access verschwinden
Jetzt bin ich gespannt, was Du daran wieder auszusetzen hast!
Makros stehen bei MS schon länger auf "deprecated" und es ist eigentlich nur eine Frage der zeit, wann sie aus Access verschwinden
Hoffentlich wird es dann in Access endlich auch Dialoge (Userformen), "echte" Autostartmakros (wie z.B. Workbook_open) und Add-Ins bzw. Vorlagendateien geben wie in Excel und Word.
Seit wann bitte sind irgendwelche "Definitionen" die MS von sich gibt, von irgendeiner Relevanz?
Wenn du eine komplette Applikation in Excel-VBA schreibst, dann sind die VBA-Routinen dahinter definitiv keine Makros mehr - unabhängig vom MS-Geschwafel.
Und ich selbst weigere mich grundsätzlich, VBA-Routinen Makros zu nennen
Seit wann bitte sind irgendwelche "Definitionen" die MS von sich gibt, von irgendeiner Relevanz?
Naja: Wir sprechen ja hier von einer Software, die von Microsoft stammt.
Und ich selbst weigere mich grundsätzlich, VBA-Routinen Makros zu nennen
Das ist ja alles OK, das kannst Du ja machen. Ich finde es auch grundsätzlich gut, wenn man unterschiedliche Standpunkte in solchen Fragen hat. Hinter jedem persönlichen Standpunkt steckt ja eine mehr oder weniger lange persönliche Entwicklung.
Trotzdem musst Du zugeben: Das ist jetzt auch ein ziemlich unwichtiger Nebenkriegsschauplatz, auf dem wir hier kämpfen!
Der eine sagt Makros, der andere sagt VBA-Routinen, was soll's??
An einem einzigen Punkt ist es natürlich wichtig, die konkreten Begriffe zu benutzen, nämlich, wenn man (z.B. in einem Kurs) die Thematik anderen Leuten vermitteln soll!
Und da muss ich dem Anfänger eben sagen: Geh im Menü "Extras" auf "Makro" und dort findest Du alles Weitere.
Würde ich demjenigen sagen: Geh im Menü "Extras" auf "VBA-Routinen", dann würde der Anfänger sich dumm und dusselig suchen und nichts finden. Insofern ist die "Definition" von Microsoft eben doch relevant!
Und da muss ich dem Anfänger eben sagen: Geh im Menü "Extras" auf "Makro" und dort findest Du alles Weitere.
Würde ich demjenigen sagen: Geh im Menü "Extras" auf "VBA-Routinen", dann würde der Anfänger sich dumm und dusselig suchen und nichts finden.
auch nicht so ganz. Das trifft nämlich nur solange zu, wie du denn Anfänger nur dazu befähigen willst, mit dem Makrorekorder Abläufe aufzuzeichnen.
Spätestens wenn das nicht reicht und du dem zeigst, dass er mit ALT+F11 in den VBA-Editor kommt und was er dort tun kann, ist das alles Makulatur
Dann zeigst du ihm noch, wie er Userforms erstellt und danach hat das alles mit Makros im ursprünglichen Sinn exakt *nichts* mehr zu tun
Insofern ist die "Definition" von Microsoft eben doch relevant!
Nein. MS-Definitionen sind per definitionem irrelevant.
Also wenn's schon unabhängig von meiner Fragestellung um die "ganz reine Lehre" geht...
"Makro" heißt für mich: Ich drücke auf Aufnahme - ich mache irgendetwas über die Tastatur und/oder über die Maus - Ich drücke auf Stop - das Makro ist fertig. Später kann ich es über das Extras-Menü oder eleganter über eine Tastenkombination aufrufen.
Wenn das falsch gedacht ist - was ist dann wirklich ein Makro?
nur dann, wenn sie für mit dem Makrorekorder aufgezeichnete Abläufe verwendet wird.
Jepp - und genau darum, und wirklich nur darum ging es in diesem Thread.
Genau deswegen war ich ja auch so verwundert, dass dieses Makro anscheinend so viele unauffindbare Rückstände hinterlassen hatte - es waren doch nur ein paar Maus- und Tastatur"gesten", die ich da aufgezeichnet hatte...
Mit folgenden Code kannst Du alles Code inklusive Module aus einer Arbeitsmappe löschen. Zuerst musst Du in den Makroeinstellungen einen Haken bei "Zugriff auf Visual-Basic-Projekt vertrauen" setzen. Die folgenden Makros in ein Modul der persönlichen Makroarbeitsmappe kopieren. Das Makro "Alles_löschen" dann in die gewünschte Symbolleiste legen.
Sub Alles_löschen()
Call Lösche_Module
Call Lösche_Userformen
Call Lösche_Ereignisprozeduren
End Sub
Sub Lösche_Module()
'Löscht Module:
For n = ActiveWorkbook.VBProject.VBComponents.Count To 1 Step -1
If ActiveWorkbook.VBProject.VBComponents(n).Type = 1 Or _
ActiveWorkbook.VBProject.VBComponents(n).Type = 2 Then
ActiveWorkbook.VBProject.VBComponents(n).Collection.Remove _
ActiveWorkbook.VBProject.VBComponents(n)
End If
Next
End Sub
Sub Lösche_Userformen()
'Löscht Userforms:
For n = ActiveWorkbook.VBProject.VBComponents.Count To 1 Step -1
If ActiveWorkbook.VBProject.VBComponents(n).Type = 3 Then
ActiveWorkbook.VBProject.VBComponents(n).Collection.Remove _
ActiveWorkbook.VBProject.VBComponents(n)
End If
Next
End Sub
Sub Lösche_Ereignisprozeduren()
'Löscht Ereignisprozeduren:
For n = ActiveWorkbook.VBProject.VBComponents.Count To 1 Step -1
For i = 1 To ActiveWorkbook.VBProject.VBComponents(n).CodeModule.CountOfLines
If ActiveWorkbook.VBProject.VBComponents(n).Type <> 1 And _
ActiveWorkbook.VBProject.VBComponents(n).Type <> 3 Then _
ActiveWorkbook.VBProject.VBComponents(n).CodeModule.DeleteLines 1
Next
Next
End Sub
Wenn Du dann alles VBA-Code aus der aktiven Arbeitsmappe löschen möchtest, dann musst Du nur noch das Makro "Alles_Löschen" ausführen. Dann sollten solche Probleme nicht mehr auftreten.
*Thumbs up*... ich hoffe, das hast du nicht alles extra nur für mich aufgeschrieben ;-)
Diese Antwort werde ich mir gut bookmarken, ich werde sie bestimmt bald einmal brauchen. Oder anders: Ich erstelle eine Dummy-Datei, setze ein paar Makros rein und lösche diese zunächst manuell. Wenn dann immer noch die blöde Meldung kommt, lasse ich dein Makro drüberlaufen.
Zahlen aus Zeichenketten auslesen - auch hier wieder die Frage, ginge es auch eleganter? Z.B. Wenn ich eine Zeichenkette habe wie "10:12:15" und die - übrigens nicht zwangsläufig immer *zwei*stelligen! - Zahlen dort auslesen möchte, um sie auf jeweils eine eigene Zelle zu verteilen, geht das nur mit den String-Befehlen LINKS, RECHTS und FINDEN (=> nämlich den ":" als Trennzeichen?) Ich vermute stark "ja", aber fragen kostet ja nichts.
Moin Olaf.
Wenn in A5 dein Feld mit z.B. 10:12:15 ist, dann muss es als Text formatiert sein, sonst findet Excel die Doppelpunkte nicht. Beim Umwandeln macht Excel direkt eine Kommazahl daraus, und man muss die Zahl neu eingeben. Aber da gibt es bestimmt eine andere Lösung, vielleicht findest du was.
So, das vor der ersten Stelle findest du mit
= LINKS(A5;(FINDEN(":";A5;1))-1)
Das zwischen den Doppelpunkten geht hiermit:
= TEIL(A5;(FINDEN(":";A5;1))+1;(FINDEN(":";A5;4))-(FINDEN(":";A5;1))-1)
Und das dahinter mit
= TEIL(A5;(FINDEN(":";A5;4))+1;(LÄNGE(A5))-(FINDEN(":";A5;4)))
Hi Timbo, da haste dich aber mächtig in Arbeit gestürzt...
Nur - ehrlich gesagt - genau so mache ich es jetzt schon, und die Formeln sind ja relativ komplex. Ich war eher auf der Suche nach der Vereinfachung, und da halte ich den Textassistenten mit dem ":" als Trennzeichen für eine absolut geniale Lösung. Das ist so eine Idee aus der Rubrik "genial einfach - hätte man selber drauf kommen müssen".
neanderix
Olaf19
mawe2
PaoloP
st.lu
mumpel1
Timbosteron
