Wikipedia Diskussion:Technik/Text/Basic/EXCEL-Tabellenumwandlung
for an english Discussion of the tool please look here.
Version 12
[Quelltext bearbeiten]Das Makro kann keine EXCEL-Diagramme konvertieren (und wird es auch nie können)
[Quelltext bearbeiten]Hallo, ich habe versucht ein Excel-Diagramm (Excel 2000) auf die beschriebene Weise umzuwandeln. Das beschriebene Makro habe ich in die Visual Basic-Seite einfügen können. Als ich das Makro ausführen wollte, kam die Fehlermeldung: Laufzeitfehler 13: Typen unverträglich. Nach dem ich auf "Debuggen" klickte, wurde dieser Text gelb markiert: : Set selrange = Selection. Was kann ich tun? Viele Grüße Rabe19
- Hallo Rabe19, ein EXCEL-Diagramm ist kein Zellenbereich, sondern eine Grafik (Torten, Balken und was man halt so machen kann). Mit dem Makro kannst Du nur Bereiche mit nicht verbundenen Zellen in eine Wiki-Tabelle konvertieren, keine Diagramme. Mit der Wiki-Tabellensyntax kannst Du auch von Hand nur Wiki-Tabellen aber keine Grafiken erzeugen. Ergo wird das Makro nie in der Lage sein Deine diesbezügliche Erwartungen zu erfüllen. Natürlich wäre es eleganter eine solche Fehlmanipulation im Programm zu erkennen, den Laufzeitfehler abzufangen und einen Fehlerhinweis zu geben. Ist es Dir schon gelungen, das Makro bestimmungsgemäss anzuwenden? D.H. hast Du schon mal eine Tabelle konvertiert und ins Wiki stellen können? Freundliche Grüsse --ollio 00:23, 24. Jun 2006 (CEST)
- Version V12 hochgeladen. Es wird nun getestet, ob die Selektion ein Zellbereich ist - ist irgendwas anderes selektiert, wird eine Fehlermeldung ausgegeben und die Verarbeitung abgebrochen. --ollio 23:07, 27. Jun 2006 (CEST)
Wie installiert man das Makro als Add-in?
[Quelltext bearbeiten]kenne mich mit Excel leidlich aus. Mit Makros nicht. Mir ist die Kopiererei in verschiedene Tabellen einfach zu umständlich. Es funktioniert im großen und ganzen hervorragend. Trotzdem kann ich trotz deiner Beschreibung keine Add-ins einfügen. Bin zu doof. Bitte genauer beschreiben. --Calloberian 15:11, 26. Jul 2006 (CEST)
Frage/Antwort von allgemeinem Interesse und deshalb ins gleichnamige Unterkapitel auf der Projektseite verschoben.
Ich hoffe das hilft. Freundliche Grüsse --ollio 18:51, 26. Jul 2006 (CEST)
- Sieht klasse aus. Vielen Dank! --Calloberian 08:15, 27. Jul 2006 (CEST)
Version V13
[Quelltext bearbeiten]Problem mit Excel-Zeilenumbrüchen und Kalenderdaten
[Quelltext bearbeiten]Ein Super-Makro, leider habe ich zwei kleine Probleme festgestellt, mit denen ich wie folgt umgegangen bin.
Benutzerdefiniertes Datumsformat
[Quelltext bearbeiten]Aus für mich nicht nachvollziehbaren Gründen führt ein ursprünglich benutzerdefiniertes (Zell-) Datumsformat von TT.MM.JJJJ letztlich durch die Makrofunktionalität Numberformat zum (amerikanischen) Format m/d/yyyy. Das Beispieldatum 20.02.2006 wird dadurch konvertiert zu 2.20.2006 und so in den Wikitext übernommen.
Nach Umformatieren der Spalte in ein Standarddatumsfomat TT.MM.JJ funktioniert alles reibungslos.
Excel-Zeilenumbruch
[Quelltext bearbeiten]Enthält eine Excel-Zelle einen manuellen Zeilenumbruch (eingebbar mit Alt+Eingabe), so führte dies bei mir beim direkten Cut-and-Paste in den Wiki-Editor zur Zuordnung dieses Textes zur falschen Spalte und zum Verlust von Formatierungen, da ein Teil der Wiki-Syntax plötzlich in Gänsefüßchen eingekleidet wurde.
Umgehen ließ sich dies relativ einfach dadurch, dass man den Text von Excel zuerst nach Word kopiert, dort dann die entstandene Word-Tabelle in Text umwandelt, nochmal kopiert und erst dann in den Wiki-Editor einfügt. Andere "Umwege" führen leider nicht zu akzeptablen Ergebnissen (z.B. Speichern im TXT-Format oder ähnliches).
Am besten wäre es natürlich, wenn das Makro diesen problematischen "halben" Zeilenumbruch – VBA-seitig handelt es sich hier um ein Chr(10)-Zeichen ohne das in anderen Dateiformen normalerweise davorstehende Chr(13) – in einen "echten" Zeilenumbruch umsetzen würde → z.B. <br>.
Folgende Änderung wäre in process_cellcontent erforderlich (ganz am Ende):
'Excel-Zeilenumbrüche in <br>-Tag umsetzen process_cellcontent = Suchen_und_Ersetzen(process_cellcontent, vbLf, "<br>")
und zusätzlich die neue Function Suchen_und_Ersetzen mit dem Inhalt:
Function Suchen_und_Ersetzen(strUrsprungsstring As String, _ strSuchstring As String, _ strErsatzstring As String) As String On Error GoTo Err_ Dim iStartpos As Integer, iLänge As Integer Dim bSuchstringGefunden As Boolean Dim strTempString As String iStartpos = InStr(strUrsprungsstring, strSuchstring) If iStartpos = 0 Then 'nicht gefunden Suchen_und_Ersetzen = strUrsprungsstring Else iLänge = Len(strSuchstring) bSuchstringGefunden = True strTempString = strUrsprungsstring While bSuchstringGefunden strTempString = Mid(strTempString, 1, iStartpos - 1) & strErsatzstring & _ Mid(strTempString, iStartpos + iLänge) iStartpos = InStr(strTempString, strSuchstring) If iStartpos = 0 Then bSuchstringGefunden = False Wend Suchen_und_Ersetzen = strTempString End If Exit_: Exit Function Err_: MsgBox "Error - " & Err.Description & " (ErrNo=" & Err.Number & ")", vbOKOnly, _ "Suchen_und_Ersetzen" Resume Exit_ End Function
--ManWing2 16:05, 26. Sep 2006 (CEST)
- Hallo Manwing, danke für Dein Feedback. Bezüglich Excel-Zeilenumbruch habe ich Deinen fundierten Lösungsvorschlag gleich eingebaut und als V13 hochgeladen. Deine Funktion Suchen_und_Ersetzen habe ich durch die Standardfunktion REPLACE ersetzt. Freundliche Grüsse, Ollio --ollio 23:37, 26. Sep 2006 (CEST)
Problem mit Excel 97 (VB5)
[Quelltext bearbeiten]Hallo Ollio, leider gibt es die VB-Funktion Replace erst ab VB6 (=Excel2000) (siehe z.B. http://vb-helper.com/howto_replace.html); daher funktioniert das Makro in Excel 97 nicht. Da ich aus Lizenz-Gründen noch mit Excel97 arbeite, habe ich dadurch ein Problem.
Könntest du doch die Funktion von ManWing2 benutzen? Danke --Mjoppien 16:26, 3. Nov. 2006 (CET)
- Hallo Mjoppien,
- EXCEL-97 ist nun doch auch schon 9 Jahre alt und es ist nicht unbedingt mein erklärtes Ziel, mit EXCEL-97 auf alle Ewigkeit kompatibel zu sein. Natürlich verstehe ich auch Deine Beweggründe. Die beiden Funktionen sind aber vom Aufruf und der Parameterliste wirklich identisch, Du kannst also REplace ganz einfach durch einen <techtalk>Wrapper emulieren</techtalk>. Siehe hierzu die Anleitung unten.
- Die beiden Funktionen
- Function Replace(cellcontent, vbLf, "<BR>") as string
- Function Suchen_und_Ersetzen(strUrsprungsstring As String, strSuchstring As String, strErsatzstring As String) As String
- sollten mal das gleiche tun - ich setzte das voraus ohne Function Suchen_und_Ersetzen im einzelnen getestet zu haben.
- Du kannst Deinen Code also ganz einfach umbauen (bitte aber nicht hier auf der Projektseite), das verletzt auch nicht die GPL-Lizenz. :Vorgehen:
- Function Suchen_und_Ersetzen(strUrsprungsstring As String, strSuchstring As String, strErsatzstring As String) As String
- umbenennen in
- Function Replace(strUrsprungsstring As String, strSuchstring As String, strErsatzstring As String) As String
- Am besten
- lädest Du Dir den Text VBA-Code von Function Suchen_und_Ersetzen in einem Texteditor in eine leere Datei
- Mit suchen/ersetzen wird dann die Zeichenfolge Suchen_und_Ersetzen durch Replace ersetzt.
- Änderungen sind an folgenden Stellen notwendig
- Function Suchen_und_Ersetzen(
- Suchen_und_Ersetzen = strUrsprungsstring
- Suchen_und_Ersetzen = strTempString
- MsgBox "Error - " & Err.Description & " (ErrNo=" & Err.Number & ")", vbOKOnly, "Suchen_und_Ersetzen"
- den resultierenden Code kopierst Du Dir dann in Deinen EXCEL-VBA-Code unter EXCEL-97
- Testen, Fertig
- Freundliche Grüsse, --ollio 22:39, 5. Nov. 2006 (CET)
Version 14: conversion of vertical cell orientation
[Quelltext bearbeiten]Hallo, super macro, alles funktionert sehr gut wie beschrieben (incl. limitations bei combined cells etc.) allerdings habe ich es nicht geschafft, dass Zellen mit vertical orientation in Excel 2003 SP2 auch vertikal in Wiki dargestellt werden.
Habe getestet mit nur einer einzigen Zelle im sheet und expliziter Formattierung:
Right mouse menu - Format Cells ...
Number tab: Category: Text
Alignment tab: Horizontal: General, Vertical: Bottom, Indent: 0
Orientation: 90 (Degrees)
Ausgabe ist jedoch eine normale horizontale Ausrichtung (mit dann entsprechend zu grosser Breite):
{| {{prettytable}} <hiddentext>generated with [[:de:Wikipedia:Helferlein/VBA-Macro for EXCEL tableconversion]] V14</hiddentext> |- valign="bottom" | width="48" Height="57.75" | available (A) |}
Idealerweise wuerde ich mit den obigen Einstellungen auch Zellen mit Zeilenumbruch darstellen, also mehrere Woerter vertikal ausgerichtet und von links nach rechts nebeneinander in derselben Zelle angeordnet. Stattdessen wird aber ebenfalls nach "normal" konvertiert:
{| {{prettytable}} <hiddentext>generated with [[:de:Wikipedia:Helferlein/VBA-Macro for EXCEL tableconversion]] V14</hiddentext> |- align="center" valign="bottom" | width="48" Height="102" | available (A)<BR>work in progress (wip)<BR>to be determined (tbd) |}
Can you help ? Besten Dank, Volker
- ja ist so wird von derzeitiger Version nicht unterstützt. Aber Du kannst ein allfällige Implentierung unterstützen: Zeige mir bitte hier Deinen eigenen Wiki-Tabellencode der das kann. Gruss --ollio 21:38, 15. Jun. 2007 (CEST)
Version 17
[Quelltext bearbeiten]Width-, Heigth-Formatierung: Bitte modernisieren
[Quelltext bearbeiten]Das Macro generiert mit Verlaub gesagt etwas arg angestaubten Wikicode: height- und width-Attribute ohne Einheit und dazu noch mit Nachkommaanteil (width=12,75). Einheitenlose width und height-Werte werden als px interpretiert, wo jedoch 0,75 Pixel einfach nicht darstellbar sind. Das height-Attribut ist nebenbei meistens überflüssig und sollte nur in Ausnahmefällen genutzt werden. Ausserdem sollte die Formatierung weg von den missbilligten/deprecated width-, height- und valign-Attributen hin zu einer css-basierten Lösung gehen. So ists ehrlich gesagt nicht gut. --Professor Farnsworth 08:34, 19. Jul. 2007 (CEST)
- Hallo, diesem Wunsch schließe ich mich an. Dass width- und height-Attribute keine Einheit mitführen, ist die Regel, aber für einen Dezimaltrenner wäre der Punkt das richtige Zeichen, wobei Nachkommastellen hier überflüssig sind. Meiner Erfahrung nach werden hier die height- und sogar die width-Attribute nicht gebraucht, weil sich die Gestalt der Tabelle besser dem Inhalt anpassen sollte. Einzelne Breitenangaben, falls für übergreifende Ausrichtung gewünscht, können immer noch nachgetragen werden. Ebenso sollte die vertikale Ausrichtung nach unten weggelassen oder durch eine zeilenweise Ausrichtung nach oben ersetzt werden, in diesem Fall gerne in CSS-Notation. Vielen Dank und viele Grüße --Wiegels „…“ 12:07, 19. Jul. 2007 (CEST)
- Anmerkung: Laut CSS-Spezifikation müssen Größenangaben (horizontal or vertical measurements) immer eine Einheit haben (The format of a length value (denoted by <length> in this specification) is a <number> (with or without a decimal point) immediately followed by a unit identifier). Aber ansonsten stimme ich dir zu. --Professor Farnsworth 14:41, 19. Jul. 2007 (CEST)
- Hallo, für CSS-Werte in style-Attributen ist das sicher richtig, aber ich meinte die width- und height-Attribute von zum Beispiel td-Elementen. Dafür sind keine Einheiten außer Prozent vorgesehen. --Wiegels „…“ 15:05, 19. Jul. 2007 (CEST)
- M.E. sollten diese Attribute eh nicht mehr verwendet werden, da sie deprecated sind und durch äquivalente style-attribute ersetzt werden sollten. --Professor Farnsworth 15:13, 19. Jul. 2007 (CEST)
- Hallo, für CSS-Werte in style-Attributen ist das sicher richtig, aber ich meinte die width- und height-Attribute von zum Beispiel td-Elementen. Dafür sind keine Einheiten außer Prozent vorgesehen. --Wiegels „…“ 15:05, 19. Jul. 2007 (CEST)
- Dem habe ich nicht widersprochen. Aber wenn sie verwendet werden, bitte ohne Maßeinheiten, wie es korrekt ist. :-) --Wiegels „…“ 15:52, 19. Jul. 2007 (CEST)
Hallo, also die Massangaben von HEIGHT und WIDTH werden in V17 nun gerundet - eine eher kosmetische Aenderung, machte doch der Browser das vorher auf dem Client wohl auch schon so :-) Das Makro produziert übrigends Wikicode und keinen HTML-Code, also argumentiert doch bitte mit dem Wikicode-Standard und mit Links auf entsprechende Wikicode-Spezifikationen. Bitte führt eine allfällige HTML-Purismusdiskussion erstmal dort und sorgt dort für einen Consens und in der Doku für einheitliche Aktualisierung eurer Anliegen. Wenn etwas in HTML deprecated ist, bedeutet dass nicht, dass dies im Wikicode ebenso ist. Welchen HTML-Code aus dem Wikicode gerendert wird, könnt ihr auch mit den Entwickler der Wikisoftware unter Mediawiki diskutieren. Die Umsetzung der HEIGHT und WIDTH Angaben in Inline-CSS führt nicht zu einem kompakteren Code und scheint mir deshalb der Mühe nicht wert zu sein. Gestaltung der Tabelle und Anpassung der Zeilenbreiten und -höhen an den Inhalt erfolgt bereits in EXCEL. Dort wird auch die vertikale Textausrichtung in der Zelle gewählt, wobei in EXCEL Valign=Bottom der default ist. Wers anders haben will, stellt es einfach in EXCEL anders ein, dann wird es auch so übernommen. Das Makro hat zum Ziel - soweit es es möglich ist - die Tabellenformattierung von EXCEL 1:1 zu übernehmen. Es werden keine impliziten Formattierung auf Formatparametern vorgenommen, die in EXCEL explizit vorgegeben werden können. --ollio 10:33, 30. Jul. 2007 (CEST)
- Hallo Ollio, genaugenommen werden mit Komma abgetrennte Nachkommastellen eher abgeschnitten als gerundet, was bei anschließendem Prozentzeichen im MS Internet Explorer zu unerwarteten Ergebnissen führen kann, wie ich erfahren habe. Ich weiß nicht, warum wir eine Diskussion über die Art und den Umfang der Ausgabe deines Makros an einer anderen Stelle führen sollten als der, die es angeht. Dass die Wiki-Syntax in width- und height-Attributen (wie bei HTML) keine Pixel-Einheit vorsieht, ist nachzulesen, genauso wie der Hinweis, dass die Verwendung fester Spaltenbreiten nur beim Einbinden von Grafiken sinnvoll ist, nämlich auf der von dir genannten Hilfeseite. Darüber besteht anscheinend Konsens. Ich möchte dich nochmal darum bitten, auf die Ausgabe von width- und height-Attributen und gerne auch von valign-Attibuten, die von der Wiki-Software weitgehend durchgereicht werden, zu verzichten. Selbst wenn ein Excel-Benutzer einige der Einstellungen für seine Tabelle bewusst vorgenommen hat, sind wenigstens erstere für die Darstellung im Web, wo Tabellen sich variabel an Fensterbreiten anpassen können sollen, zumindest hinderlich. Pixel-genaue Abmessungen von Tabellenzellen wären zudem höchstens sinnvoll, wenn der Browser die selbe Schriftart verwendet wie der Ersteller der Tabelle, wovon man nicht einmal auf Windows-Systemen ausgehen kann. Beachte bitte auch das Projekt Wikipedia:BIENE. Vielen Dank --Wiegels „…“ 01:03, 31. Jul. 2007 (CEST)
- Hallo Wiegels, das mit der Schriftartenersetzung durch den Browser scheint tatsächlich ein stichhaltiges Argument zu sein. Allerdings kann man ja auch die Schriftgrösse vorgeben, die wird in EXCEL ja auch in pt angegeben. Es gibt da aber schon Unterschiede, allerdings liegt es in der Verantwortung des HTML-Clients und dem Bildschirmtreiber, hier möglichst weitgehende Kompatibilität in der Ersetzungsstrategie zu erreichen. Allenfalls wird sonst halt der Text etwas anders umgebrochen. Das ist weniger schlimm als wenn die Spaltenbreiten überhaupt nicht kontrolliert werden können. Ich weiss nicht wie Du das machst, bei mir sind in einer Tabelle höchst selten alle Spalten gleich breit. Deshalb möchte ich dem Anwender schon die Möglichkeit nicht nehmen, die Spaltenbreiten vorzugeben. Ebenfalls wird durch die Spaltenbreite ja auch die Breite der Tabelle auf dem ganzen Bildschirm vorgeben. Die Tabelle soll ja auch nicht in jedem Fall über die ganze Bildschirmbreite gehen. Natürlich kenne ich die Diskussion, ob Formattierungsangaben in absoluter oder relativer Bemassung gemacht werden sollen.. Das ist auch ein Dauerthema bei vielen CSS-Layoutern. Zusammenfassend halte ich Folgendes fest. Der Anwender vom diesem Tabellenmakro
- soll die Zeilenbreiten festlegen können.
- soll die Gesamtbreite der Tabelle festlegen können.
- Ob obige Formattierung absolut [in px] oder in relativen Verhältnissen [in %] erfolgen soll lasse ich mal offen. Derzeit ist erstere Variante realisiert. Wäre Dein Anliegen abgedeckt, wenn die WIDTH-Angaben mittels Umrechnung in Prozenten relativiert würden? Die selektierten Spalten würden dann automatisch zu 100% gesetzt. Die ganze Tabelle kann dann immer noch z.B. auf 75% der Seitenbreite skaliert werden können. Diese Bemassungen beziehen sich dann automatisch auf die Seitenbreiten des Clientfensters. Gruss --ollio 13:35, 1. Aug. 2007 (CEST)
- Hallo Wiegels, das mit der Schriftartenersetzung durch den Browser scheint tatsächlich ein stichhaltiges Argument zu sein. Allerdings kann man ja auch die Schriftgrösse vorgeben, die wird in EXCEL ja auch in pt angegeben. Es gibt da aber schon Unterschiede, allerdings liegt es in der Verantwortung des HTML-Clients und dem Bildschirmtreiber, hier möglichst weitgehende Kompatibilität in der Ersetzungsstrategie zu erreichen. Allenfalls wird sonst halt der Text etwas anders umgebrochen. Das ist weniger schlimm als wenn die Spaltenbreiten überhaupt nicht kontrolliert werden können. Ich weiss nicht wie Du das machst, bei mir sind in einer Tabelle höchst selten alle Spalten gleich breit. Deshalb möchte ich dem Anwender schon die Möglichkeit nicht nehmen, die Spaltenbreiten vorzugeben. Ebenfalls wird durch die Spaltenbreite ja auch die Breite der Tabelle auf dem ganzen Bildschirm vorgeben. Die Tabelle soll ja auch nicht in jedem Fall über die ganze Bildschirmbreite gehen. Natürlich kenne ich die Diskussion, ob Formattierungsangaben in absoluter oder relativer Bemassung gemacht werden sollen.. Das ist auch ein Dauerthema bei vielen CSS-Layoutern. Zusammenfassend halte ich Folgendes fest. Der Anwender vom diesem Tabellenmakro
€ to $
[Quelltext bearbeiten]Hallo, leider funktioniert der Export von € nicht. Es kommen ($) an. Gibt es da einen Trick? Grus, -- JW
- Ich habe ein paar Änderungen in der "Function process_cellcontent" gemacht, so dass mein Code nun so aussieht:
'If .NumberFormat <> "General" And .NumberFormat <> "Standard" Then ' ??? ' cellcontent = skip_underline(Format(.Value, .NumberFormat)) ' ??? 'Else ' ??? If cellcontent = "" Then '<< 15.2.2007 If Not emptyCell_nbsp Then '<< 05.3.2007 cellcontent = " " '<< 05.3.2007 Else '<< 05.3.2007 cellcontent = " " '<< 15.2.2007 End If '<< 05.3.2007 Else cellcontent = .Text ' was: cellcontent = cellcontent End If '<< 15.2.2007 'End If ' ???
damit funktieren € hier. Änderungen: Zeilen 1-3 und letzte Zeile auskommentiert; dritt-letzte Zeile nun: "cellcontent = .Text" . -- Michael Bednarek 12:21, 30. Sep. 2008 (CEST)
Excel 2007 / Fehler 400
[Quelltext bearbeiten]Bei der Ausführung des Makros läuft Excel 2007 auf den Fehler 400 (keine weitere Beschreibung). Das Output-Tabellenblatt wird zwar erzeugt, aber es enthält keinen Text. --Abnonta 14:56, 20. Sep. 2008 (CEST)
- Habe kein EXCEL 2007. Zu mindest die fehlergenerierende Programmzeile müsste bekannt sein. Mit einer so ungenauen Fehlerdarstellung kann ich gar nichts anfangen. Wer hat EXCEL-2007 und dem Makro Erfahrungen gemacht? --ollio 20:03, 20. Sep. 2008 (CEST)
Ich habe auch Excel 2007 und bei mir erscheint leider der Fehler "Laufzeitfehler '91': Objektvariable oder With-Blockvariable nicht festgelegt". --Ulli Ziegenfuß 14:29, 6. Mär. 2009 (CET)
- Wie ollio oben schon sagte: welches ist die fehlergenerierende Programmzeile? Michael Bednarek 01:23, 7. Mär. 2009 (CET)
- Zeile 608 "With selrange.Cells(iline, 1) 'take first column as reference". Gruß --Ulli Ziegenfuß 09:36, 7. Mär. 2009 (CET)
- Das ist in
Function formatstring_for_a_linecontent() As String
, nicht wahr? Welche Expertise im "Debuggen" von VBA Programmen has du denn? - Es scheint mir, dass "selrange" nichts zugewiesen wurde. Was wird angezeigt, wenn du im VBA Editor "Immediate" Fenster (sorry, das kenn' ich nur auf englisch) folgendes eingibst:
? selrange.Address
? iline- Die erste Zeile sollte den Bereich anzeigen, den du konvertieren willst, die zweite, bei welcher Zeile der Eingabetabelle sich das Programm gerade befindet. Michael Bednarek 10:17, 7. Mär. 2009 (CET)
- Das ist in
- Das liegt daran, dass du das Makro falsch ausführst. Nicht auf den Play Button klicken sondern auf Extras->Makros->Ausführen. Dann läuft das Skript auch richtig Jakob 10:17, 7. Jul. 2009 (CET) -- 129.217.184.247 14:43, 7. Jul. 2009 (CEST)
Gibt's das auch für Calc/OpenOffice?
[Quelltext bearbeiten]- Hallo OpenSourcegemeinde, gibt's das gleiche auch für StarOffice/OpenOffice Calc? In Excel klappt das spitze, aber ich hab hier nur OpenOffice auf meinem Asus Eee installiert. Martin
- hallo hallo, schupps. Weiss jemand was? Martin 194.114.62.39 14:45, 24. Feb. 2009 (CET)
- google dein freund..
- http://de.wikipedia.org/wiki/Hilfe:Tabellen#Hilfen
Verbesserungsvorschlääge
[Quelltext bearbeiten]Ich würde mir noch wünschen:
- wählbar: a) Code mit Formatierungen etc, b) Code nur mit Tabellenkopf formatiert, Zeilen/Zellen ohne
- Tabelle sortierbar (class="wikitable sortable")
- Tabellenkopf mit Standard-Wiki-Format ( |- class="hintergrundfarbe5" ! Spalte1 ! SpalteX
Gruss, --Markus 12:01, 12. Mär. 2009 (CET)
Hallo Markus, die Aenderung class="wikitable sortable" kann man von Hand in den Output einfügen. Sollte kein Problem sein. Die Farbgebung der Zellen erfolgt mit den Farben die in EXCEL verwendet werden. Wenn z.B für Zellen keine Formattierung erwünscht ist, kannst Du diese in Deinem EXCEL-Input entfernen. Das Makro soll einfach zu handhaben sein. Es gibt deshalb nicht zig Steuerparameter, mit denen das Verhalten des Makros verändert werden kann. Eine EXCEL-Tabelle als Eingabeparameter ist aber denke ich schon mal recht flexibel. Anschliessend kann der Output auch noch manuell bearbeitet werden, wenn man unbedingt noch was anderes haben will. Freundliche Grüsse, ollio 18:26, 1. Jul. 2010 (CEST)
Wiki zu Excel
[Quelltext bearbeiten]Hallo Olli, danke für das tolle Tool! Ich habe damit eben ene komplexe Tabelle ins Wiki gestellt.
Nun ist es ja aber so, dass die Tabelle im Wiki natürlich weiter bearbeitet und ergänzt wird. Und wenn ich nun meine Exceltabelle bearbeite, sind dabei die bereits getätigten Wiki-Bearbeitungen nicht berücksichtigt. Ich müsste also erst die aktuelle Wikitabelle nach Excel konvertieren, damit ich sie bearbeiten kann, um sie dann mit Deinem Tool wieder als Ganzes hochladen zu können.
Kannst Du dafür ein Tool schreiben? Wäre super! --Markus 12:01, 12. Mär. 2009 (CET)
Hallo Markus, dazu brauchst Du kein Tool. Mit Copy/Past geht das schon jetzt enifach un komfortabel.
- Copy von Wiki nach Zwischenablage
- Paste von Zwischenanlage nach leerem EXCEL Arbeitsblatt
Gruss, ollio 16:53, 1. Jul. 2010 (CEST)
Problem (Excel 2007)
[Quelltext bearbeiten]Die Beschreibung sollte mal auf Excel 2007 geändert werden. Ich finde das Menü "Extras" nicht. Wo ist das? Στε Ψ 17:31, 26. Apr. 2009 (CEST)
- Alt-F11 tut's nicht? Michael Bednarek 03:25, 27. Apr. 2009 (CEST)
- Nicht, wenn ich unter der Überschrift "Optional: Makro als Add-in installieren" den vierten Punkt ausführen will: Unter Extras > Addins erscheint nun das neue XLA. Dieser wird durch Ankreuzen aktiviert. Στε Ψ 15:43, 27. Apr. 2009 (CEST)
- Verstehe; vielleicht hilft dieser Artikel?
- "Excel 2007: Click the Office button, choose Excel Options, and then click Add-Ins. Choose Excel Add-Ins from the Manage section at the bottom of the Add-Ins window as shown in Figure 1, and then click Go. As shown in Figure 2, select any add-ins that you wish to include."
- Da ich ausschließlich Office V-11 in englisch benutze, kann ich leider keine sinnvollen Suchbegriffe für Office V-12 in deutsch formulieren. Viel Glück, -- Michael Bednarek 06:59, 28. Apr. 2009 (CEST)
- Ok, danke, das sollte man jetzt vllt noch auf der Projektseite ergänzen. Στε Ψ 15:22, 28. Apr. 2009 (CEST)
- Nicht, wenn ich unter der Überschrift "Optional: Makro als Add-in installieren" den vierten Punkt ausführen will: Unter Extras > Addins erscheint nun das neue XLA. Dieser wird durch Ankreuzen aktiviert. Στε Ψ 15:43, 27. Apr. 2009 (CEST)
Objektvariable
[Quelltext bearbeiten]Die Objektvariable ist nicht festgelegt. --Verwaltungsgliederung 11:11, 6. Jun. 2009 (CEST)
- Welche? In welcher Programmzeile (Nummer & Text)? Unter welcher Excelversion? -- Michael Bednarek 14:39, 6. Jun. 2009 (CEST)
- Zeile 608: With selrange.Cells(iline, 1) 'take first column as reference Excelversion 10.2614.2625 Oder die With-Blockvariable ist nicht festgelegt. --Verwaltungsgliederung 12:25, 27. Jun. 2009 (CEST)
- Das scheint derselbe Fehler wie weiter oben (#Excel 2007 / Fehler 400) zu sein; siehe dort für diagnostische Hilfe. Ansonsten stelle sicher, dass du auch die zu konvertierende Tabelle in Excel selektiert (deutsches Wort?) hast. -- Michael Bednarek 03:53, 28. Jun. 2009 (CEST)
- Zeile 608: With selrange.Cells(iline, 1) 'take first column as reference Excelversion 10.2614.2625 Oder die With-Blockvariable ist nicht festgelegt. --Verwaltungsgliederung 12:25, 27. Jun. 2009 (CEST)
Problem Zeilenkopf Farbe
[Quelltext bearbeiten]Hallo, ich hatte Probleme mit der Farbe des Tabellenkopfs. Diese wurde nicht richtig übernommen (Excel 2003) Habs gelöst. Wenn's Dich interessiert kann ich den Code reinstellen. Wo? Wie? -- Alexander
Support für EXCEL 2007, 2010
[Quelltext bearbeiten]Ich sehe dass es ev. diverse Probleme und Anpassungsbedarfe gibt, die auf dem Releasewechsel von EXCEL auf 2007, 2010 basieren. Das ursprüngliche Makro wurde für ECEL 2003 geschrieben und getestet. Wenn Anpassungen für 2007 vorzunehmen sind, die auf 2003 nicht ebenfalls laufen und getestet worden sind, sollte der bestehende Code auf die Seite Wikipedia:Textverarbeitung/EXCEL-2007 Tabellenumwandlung VBA kopiert und dort für 2007 weitergepflegt werden. Habe derzeit 2007 nicht installiert und werde dies auch so lange wie möglich noch hinauszögern. Auch ich bin auf Anhieb noch kein Fan der neuen Menüsteuerung und für Office-2007 müsste ich auch noch definitiv meine Hardware aufrüsten. Der Wunsch ist aber auch noch in der grösseren Warteschleife. Wer kann und will, darf aber schon mal vorspuren. Gruss. ollio 22:54, 26. Nov. 2010 (CET)
Kannst Du denn den bestehenden Teil schonmal auf die Seite kopieren Wikipedia:Textverarbeitung/EXCEL-2007 Tabellenumwandlung VBA? Dann kann ich mal schauen wie hier eine 2010 Variante aussehen könnte... --Immo we (Diskussion) 15:46, 13. Mai 2013 (CEST)
- @Ollio: Wie siehts mittlerweile aus? Ich hab das Makro soeben für Office 2016 getestet, und es läuft problemlos. Kannst du die Anleitung eventuell mal anpassen? Kleine Syntax-Änderung am Wiki-Output müssten auch vorgenommen werden, z. B. style='xy' ist heutzutage style="xy". 129.13.72.197 14:16, 7. Jul. 2016 (CEST)
Hallo Ollio, ich habe heute die Version Microsoft® Excel® für Microsoft 365 MSO (Version 2306 Build 16.0.16529.20100) 64 Bit verwendet. Die Tabelle wurde scheinbar richtig und ohne weitere Anpassung übersetzt, einschließlich funktionierender Permalinks als Quellennachweis, was mit .csv nicht möglich war. siehe: https://www.stadtwikidd.de/wiki/Fechtvereine Danke für das Tool (nicht signierter Beitrag von ThieleUwe (Diskussion | Beiträge) 18:39, 15. Jul. 2023 (CEST))
Anleitung für den benutzerdefinierten Menüeintrag
[Quelltext bearbeiten]Habe mir erlaubt, die Anleitung zu ändern, so dass sie auf mein Excel 2002 passt ... weiß nicht, ob spätere Versionen genauso funktionieren, dann müsste man das im Text entsprechend unterscheiden. --BRFR 17:30, 18. Feb. 2011 (CET)
Dank an den Aut(h)or
[Quelltext bearbeiten]Vielen Dank, das Makro ist erste Sahne! (Schade, dass es so etwas nicht für OO/LO gibt.)--Zuviele Interessen 22:41, 11. Sep. 2011 (CEST)
Excel 2003, Einfügen von Links abhängig von Formatierung
[Quelltext bearbeiten]Hallo, erst mal vielen Dank an den Autor dieses Makros, ich sitze gerade an einem Projekt, das durch dieses Makro sozusagen erst ermöglicht wird bzw. durch die Möglichkeit der Tabellenumwandlung in ganz anderen Dimensionen realisierbar ist.
Ich muss dazu allerdings ein paar Änderungen am Quelltext machen und habe dazu ein paar Fragen, da mein Visual Basic schon ein paar Jahre zurückliegt:
Und zwar habe ich hier eine Menge Excel Dateien, in denen vereinfacht gessagt Inventar verwaltet wird. Die Tabellen in den Dateien bestehen aus 2 Spalten, Bezeichnung und Anzahl. Sie existieren schon seit über 10 Jahren und nun will ich diese in ein internes Wiki einfügen und gleichzeitig auf jeden Gegenstand einen Link setzen, um dann zu jedem Gegenstand eine neue Seite mit Detailinformationen anlegen zu können. Dazu muss dann erst mal für die erste Spalte außer dem Text noch die Zeichen für einen Link vor und hinter dem Text ausgegeben werden, also jeweils 2x eckige Klammer. Kann mir jemand sagen an welcher Stelle man das ändern müsste bzw eigentlich müsste ich nur wissen wie der VBA Ausdruck für den Textinhalt einer Zelle in Excel lautet, da müsste ich ja dann einfach davor und dahinter die eckigen Klammern ausgeben lassen.
Außerdem sind die existierenden Excel Tabellen so angelegt, daß in der ersten Spalte auch Unterteilungen der Gegenstände in Kategorien o.ä. stehen, also zb steht in einer Zeile Raum 1 und darunter dann die Auflistung Gegenstand und Anzahl und irgendwann dann Raum 2 usw. Bei diesen Kategorieüberschriften soll dann kein Link erstellt werden, Vorteil ist, dass diese Kategorieüberschriften in Excel in fett geschrieben sind, ich müsste also nur wissen, wie man in VBA überprüfen kann ob der Zellinhalt in Excel fett formtiert ist und wenn nicht werden eben die eckigen Klammern für Wiki-Links hinzugefügt.
Also in Kurzform: Bei der Umwandlung von Excel nach Wiki sollen in der 1. Spalte immer Links auf den Zellentext angelegt werden, wenn der Zelltext in Excel nicht fett formatiert ist.
Kann mir da jemand helfen? Danke im voraus
- I suggest to leave this macro unchanged; after conversion, run the code below instead.
- (Ich schlage vor, dieses Tabellenumwandlungsmakro nicht zu verändern; statt dessen kann das folgende Makro über selected Zellen ausgeführt werden.)
Sub AddBrack()
' Surround non-bold text in selected area with a pair of square brackets: [[…]]
Dim rngCell As Range
Application.ScreenUpdating = False
For Each rngCell In Selection
If Not rngCell.Font.Bold Then
rngCell.Value = "[[" & rngCell.Value & "]]"
End If
Next rngCell
Application.ScreenUpdating = True
End Sub
Danke, habe auch schon selber etwas testweise geändert was auch funktioniert. Habe mir einfach einen globalen Merker gesetzt, ob der Zellinhalt fett ist, dieser wird beim ersten aufrufen des Makros auf False gesetzt (in der Funktion Format_as_wikitable) und in der Funktion formatstring_for_a_cellcontent an der Stelle auf True gesetzt, an dem auf .bold überprüft wird und auchd er wiki-Code für die Tabellenformatierung erzeugt wird. In der Funktion process_cellcontent wird ann einfach überprüft ob der Merker auf True steht und es in der ersten Spalte steht (mit der sowieso vorhandenen globalen Variable icolumn=1) und entsprechen die eckigen Klammern vor und hinter cellcontent eingefügt, ansonsten bleibt cellcontent wie es ist. Danach wird der Merker wider auf False gesetzt für den nächsten Durchlauf.
Funktioniert super, ich habe nur das Problem wenn ich einmal eine fette Überschrift habe und danach wieder die normalen Aufzählungen losgehen, macht er bei der ersten keinen Link, ebenso bei der allersten Zeile, wo in fett die Spaltenüberschriften stehen, da macht er komischerweise inen Link obwohl es fett ist, wobei ich das vorher schon anders hatte das die erste Zeile mit den Spaltenüberschriften immer fest ausgegeben wurde.
Weiß jemand ob in der jeweils ersten Zeile nach einer Leerzeile (bzw einer leeren Zelle) eine andere Funktion aufgerufen wird als die sonst? Dann müsste ich da wahrscheinlich einfach auch den Merker einfügen.
Noch ein zweites Makro ausführen zu lassen ist leider nichth für meine Zwecke geeignet, da später damit Leute arbeiten sollen, die nicht so viel mit PC zu tun haben (altersbedingt) und es denen schwierig zu erklären wäre vorher ein anderes Makro auszuführen, zumal mit diesem ja die Inhalte der eigentlichen Excel-Tabelle geändert werden und sie dann auf keinen Fall auf speichern drücken dürften.
EDIT: Funktioniert jetzt, hatte das Rücksetzen des Merkers ein paar Zeilen zu früh gemacht, so daß es in einer If-Struktur drinsatnd und bei leeren Zellen nicht ausgeführt wurde. Funktionert jetzt super. Danke nochmal an den ursprünglichen Autor.
Problem mit der Anleitung
[Quelltext bearbeiten]Ich habe versucht, eine einfache Excel-Tabelle (... zu Testzwecken) in eine WP-Tabelle umzuwandeln. Bis Punkt 6. hat alles gut geklappt. Ab Punkt 7 bin ich nicht mehr weitergekommen; ich verstehe nicht, was mit "Quelltext UNTEN einfügen" gemeint ist. Den Quelltext aus Abschnitt "VBA-Makro"? Das habe ich versucht, aber kein Ergebnis erzielt. Kann mir jemand weiterhelfen? Viele Grüße--Dryhand58 (Diskussion) 17:34, 20. Sep. 2015 (CEST)
- Ich habe den Quelltext anderswo gefunden (Kasten rechts oben "Excel2Wiki") und damit hat´s funktioniert. Ich bin begeistert!!--Dryhand58 (Diskussion) 18:06, 20. Sep. 2015 (CEST)
- @Dryhand58: Ja, das ist doof organisiert.
- Eigentlich sollte man umseitig besser auf Wikipedia:Technik/Text/Basic #Installation in speziellen Paketen verweisen.
- Dort steht eine zentrale Anleitung für alle Pakete, und es sind auch alle bekannten Quellcodes versammelt.
- Die Sache mit VBA ist schon etwas älter, und es gibt nur sehr wenige Benutzer, die das anwenden, neu installieren oder pflegen und aktualisieren würden.
- Die umseitige Anleitung ist inhaltlich uralt. Als sie geschriebenn wurde, stand der Quellcode vielleicht mal irgendwo unten; mittlerweile aber immer auf gesonderten Seiten, damit sich Änderungen der Programmierung besser nachvollziehen lassen.
- LG --PerfektesChaos 23:10, 20. Sep. 2015 (CEST)
- @Dryhand58: Ja, das ist doof organisiert.