Excel-Daten

[mkersch]

Hallo Forenmitglieder,

Für eine Applikation muss ich Daten von einer Excel Tabelle importieren, diese bearbeiten und wieder nach Excel exportieren.

Ich programmiere bereits einige Zeit mit Xbase++, bin aber noch nicht in die Verlegenheit gekommen auf Excel Daten zugreifen zu müssen.

Gibt es eine einfache Art mit Xbase++ Ver. 1.82 auf solche Daten zuzugreifen. ?
Sind Programmbeispiele verfügbar ?

Für Eure Hilfe im Voraus vielen Dank.

Mit freundlichen Grüßen.

Michael

[Martin Altmann]

Hallo Michael,
herzlich willkommen hier - eine kurze Vorstellung im entsprechenden Forum Guten Tag, mein Name ist ... und ich bin Programmierer wird immer gerne gesehen
Nun zu Deiner Frage - das Einfachste ist natürlich in Form einer .csv-Datei. Setzt aber voraus, dass Du die aus Excel heraus selber erzeugen kannst oder bekommst.
Komplizierter wird es dann schon mit ActiveX - da gibt es einige Diskussionen zu in der Alaska-Newsgroup.
Wenn möglich, würde ich den Weg mit der .csv-Datei gehen - ist kurz und schmerzlos.

Viele Grüße,
Martin

[Tom]

Hallo, Michael.

Es geht auch mit der ODBCDBE von Alaska, und meines Erachtens kommt die auch mit einem Beispiel dafür. Sehr viel eleganter, robuster und umfangreicher sind die Möglichkeiten von Boris Borzics "SQLexpress", das Du hier findest:

http://www.sqlexpress.net

Beides bietet Dir die Möglichkeit, auf Excel-Dateien zuzugreifen, sie zu manipulieren und zu schreiben. Alles ohne ActiveX und Datenex- und -reimport.

[Tom]

ODBCDBE: Die Samples heißen EXCEL.PRG und GENSHEET.PRG.

[brandelh]

Hallo,

wenn du die ODBCDBE oder SQLExpress hast, mach es über ODBC mit SQL. Wenn nicht, kann man auch in Excel eine DBF öffnen und schreiben. Nur die Feldnamen in der ersten Zeile (Überschriften) und die Feldlänge kann einem zum Verzweifeln bringen (Excel sieht das lockerer als der DBF Treiber).

Für reinen Export habe ich auch schon Textdateien folgendermaßen erzeugt:

Code: Alles auswählen

set codepage to ansi
set alternate to exec.txt
set alternate on 
? "Erste Zeile, erste Spalte (Titel)
?
? "Feld1"+chr(9)+"Feld2",nWert
set alternate to

und dann einfach in einen Editor (Notepad) alles markieren, kopieren und in Excel einfügen. Die chr(9) bewirken dann einen Sprung ins nächste Feld.

[olaf870]

Michael,

Daten von einer Excel Tabelle importieren, diese bearbeiten und
wieder nach Excel exportieren

Die vorstehenden Beiträge sind sicherlich gut gemeint .. glücklicherweise kenne ich mich aber etwas aus:

Exceldatei lesen:

Der in vielerlei Hinsicht beste Weg zum Einlesen einer Exceldatei funktioniert über eine ADODB-Connection, die Du via ActiveX aufbauen kannst. (Ich verwendete dazu eine fertige Xbase-Pur-Funktion auf ADODB-Basis, die heißt FUNCTION LoadSheet( oDlg, cFile, cSheetName). Der Returnwert ist ein Array mit den Excelspalten. Einfacher geht es nicht.) Außerdem ist es schneller als mit der ODBCDBE von Alaska, die sowieso nicht so richtig geht, spätestens sobald in der Exceldatei Formeln enthalten sind. Auch der Weg über die genannten CSV-Dateien ist dann nicht gangbar. Das ist außerdem sehr umständlich, da der Excelanwender, dann seine Exceldatei immer zusätzlich auch noch als CSV-Datei speichern müßte. Weitere Schwierigkeiten mit CSV-Dateien ergeben sich aus den in CSV fehlenden Datentypen.

Dito: Das Speichern von Exceldateien im DBase-Format. Dies kommt schon für mich schon garnicht in Betracht, weil alle mir bekannten ODBC-Treiber Schwierigkeiten mit den Spaltenüberschriften (sollte es doch noch Leute geben, die eine Spaltenbezeichnung wie KUNDENNUMM oder FAELLIGKEIT normal finden), Umlauten und Datentypen haben

Mit ADODB geht das Lesen der Exceldatei schnell, einfach und perfekt, erwartest Du sonst noch etwas?

Auf ADODB-Basis ist es außerdem am billigsten, da Du so von der Beschaffung von Blackbox-Tools wie SqlExpress oder gar der Xbase-Professional Version entbunden bist. Gleichzeitig vermeidest Du, wegen dieser Lapalie - ich meine den R/W Zugriff auf Exceldateien - gleich 20 MByte Dll´s zusätzlich beim Kunden und bei Dir installieren zu müssen.

Exceldatei schreiben:

Wenn man davon ausgeht, daß die Exceldatei formatiert ist und das Format beim Schreiben wieder hergestellt werden soll, dann ist die Fernsteuerung von Excel über AktivX (Excel-Automation) der einzige gangbare Weg. Das dauert bei größeren Sheets zwar etwas länger, aber es geht eben nicht anders.

Ich verwende eine Excel-Bibliothek die Funktionen wie
FUNC Excel97Open( lVisible )
FUNC Excel97OpenRunningApp()
FUNC Excel97OpenMsg()
PROC Excel97Close( oExcel )
PROC Excel97Quit( oExcel ) // No Excel more on screen
PROC Excel97OpenWorkBooks( oExcel )
PROC Excel97CloseWorkBooks( oExcel )
FUNC Excel97OpenFile( oExcel, xFile )
func Excel97SaveAs( oExcel, xFile )
PROC Excel97Save( oExcel )
PROC Excel97CloseActiveWindow( oExcel ) // ActiveWindow ?
func Excel97GetSheet( oExcel, cSheet ) // cSheet == NIL
FUNC Excel97GetActiveSheet( oExcel )
FUNC Excel97GetActiveSheetName( oExcel )
PROC Excel97SheetClose( oSheet )
PROC Excel97SetValue( oSheet, nRow, nCol, xValue, cFormat )
proc Excel97AddComment( oSheet, nRow, nCol, cText )
proc Excel97ClearComments( oSheet, nRow, nCol )
FUNC Excel97GetValue( oSheet, nRow, nCol, cType )
PROC Excel97InsName( oExcel, cName, nRow, nCol, cSheet ) // Erlaubt Verweise wie z.B kWh := R37C3
PROC Excel97Font( oSheet, cName, nSize ) // Ganzes Blatt
PROC Excel97FontCell( oSheet, nRow, nCol, cName, nSize, lBold )
PROC Excel97ColAutoFit( oSheet, nCol )
PROC Excel97ColFormatAsNumber( oSheet, nCol )
PROC Excel97ColFormatAsCurrency( oSheet, nCol )
PROC Excel97ColFormatAsDate( oSheet, nCol )
PROC Excel97CellFormatAsDate( oSheet, nRow, nCol )
PROC Excel97ColAlignRight( oSheet, nCol )
PROC Excel97ColAlignLeft( oSheet, nCol )
PROC Excel97ColAlignCenter( oSheet, nCol )
PROC Excel97CellBorder( oSheet, nRow, nCol, nStyle )
PROC Excel97CellBorderRemove( oSheet, nRow, nCol, lLeft, lTop, lBottom, lRight )
PROC Excel97RowBorder( oSheet, nRow, nStyle )
PROC Excel97RangeBorderUnderline( oSheet, nRowStart, nRowStop, nColStart, nColStop, nStyle, nWeight )
PROC Excel97RowRangeBorder( oSheet, nRow, nStyle ) // Noch korreekturbedürftig
FUNC Excel97RowColor( oSheet, nRow, nColor )
FUNC Excel97CellColor( oSheet, nRow, nCol, nColorIndex ) // Possible colors in "excel.ch"
FUNC Excel97CellColorBG( oSheet, nRow, nCol, nColorIndex ) // Possible colors in "excel.ch"
PROC Excel97CellDarkBG( oSheet, nRow , nCol )
PROC Excel97CellNormalBG( oSheet, nRow , nCol )
proc Excel97OutOpen( oExcel ) // Quicky Show of all opened spreadsheets with QOut()
Proc Excel97SelectWorkSheet( oExcel, cSheetName, cBookName ) // Selects a specified worksheet
Proc Excel97SelectRow( oSheet, nRow ) // Selects specified row
Proc Excel97SelectRange( oSheet, nDataStart, nDataStop ) // Selects a specified range
Proc Excel97SelectCell( oSheet, nRow, nCol ) // Selects ONE only cell
func Excel97WorkSheetsInArray( oExcel )
PROC Excel97ImportDbf( oSheet, aStruct, lWithHeader )
FUNC ExcelScript( cOrigen, cFilexls, cFont )
Func Excel97GetRangeString()
Func Excel97GetRowAddress()
Func Excel97GetColAddress()

bereitstellt und mich vom Arbeiten mit den umständlich und teilweise schwer rauszukriegenden Excel-Methoden und IVars entbindet. Diese Bibliothek arbeitet auch unter Xbase 1.82 (dito auch die ADODB-Connection).

Wenn die Exceldatei unformatiert geschrieben werden kann, können auch andere (schnellere) Methoden als Excel-Automation zum Einsatz kommen. So wäre wieder der Zugriff über ADODB zu empfehlen, unter Umständen kann auch der Weg über das CSV-Format gewählt werden. Wobei beim CSV-Format zu beachten ist, daß über eine CSV-Datei nur jeweils ein einziges (unbenanntes) Sheet pro Exceldatei erzeugt werden kann.

Excel-Automation ist zwar auch zum Lesen der Daten geeignet, dabei ist jedoch zu berücksichtigen, daß das vergleichsweise zum Lesen der Spalten über eine ADODB-Connection sehr lange dauert.

Eine witzige Variante wäre, den Bearbeitungsvorgang, der mit den Exceldaten vorgenomen wird, (auch) in einem excelähnlich aussehendem "OWC-Spreadsheet", das in der drawingArea eines Xbase-Fenster dargestellt wird, durchzuführen und so visuell darzustellen.

Auch hierfür habe ich entsprechende Funktionen bereits geschrieben ...

Bei Einsatz obengenannter Lösung mit der Version 1.82 brauchst Du noch eine zu ActiveX in Xbase 1.9 syntaxkompatible "ExcelOle"-ActiveX Bibliothek. Diese bekommst Du von mir und wird bei dann bei Einsatz von Xbase 1.9 komplett durch Xbase-Pur-Funktionalität ersetzt. Preis VS.

Gruß
Olaf870

[mkersch]

Hallo Forenmitglieder,

vielen Dank für Eure schnelle Untertsützung. Ich werde diese Woche einige Vorschläge testen.

Noch ein paar Worte zu meiner Person.

Mein Name ist Michael. Bin bereits seit Clipper Sommer 87 in der Clipper Gemeinde.

Meine Hauptaufgabe ist eigentlich die Automatisierungstechnik, Dort erstelle ich maschinenahe Programme für SIMATIC S7, Roboter,
NC-Achsen und Prüfanlagen.

Zur Parametervorgabe mittels PC bzw. Auswertungen von Prüfautomaten setzen wir zum Teil VBASIC und XBASE++ ein.

Ich finde es gut, dass es endlich ein deutschsprachiges XBase++ Forum gibt, und hoffe das ich in Zukunft ein wenig dazu beitragen kann dieses Forum zu unterstützen.

Mit freundlichen Grüßen

Michael

[brandelh]

Michael,

Daten von einer Excel Tabelle importieren, diese bearbeiten und
wieder nach Excel exportieren

Die vorstehenden Beiträge sind sicherlich gut gemeint .. glücklicherweise kenne ich mich aber etwas aus:

Hallo Olaf,

gut das du dich damit auskennst,
könntest du uns Unwissenden die Quellen deiner Infos (Dokus, Bibliothek etc.) kund tun

[Tom]

Hallo, Olaf.

glücklicherweise kenne ich mich aber etwas aus

Schön, daß sich ein Einäugiger in den trüben, feuchtnassen Keller herabläßt, in dem wir Blinden hier hausen.

Damit kein falscher Eindruck entsteht: Ich nutze die Excel-Anbindung (zunächst per ODBCDBE, jetzt via SQLexpress), was beides sauber und sicher funktioniert - Daten lesen, verändern, schreiben. Allerdings, und hier gebe ich Olaf recht, sollte man derlei nur tun, wenn die Excel-Tabelle tatsächlich nur aus Daten besteht.

[olaf870]

Hallo Brandelh

ich beziehe mein Excel-Knowhow aus langjähriger Arbeit mit Excel (auch Excel-Makroprogrammierung).

Wenn Du also mal einen Spezialisten für Excel suchst ...

Gruß
Olaf870

[brandelh]

Hallo Olaf,

du darfst gerne Hubert zu mir sagen

Steuerst du Excel mit ActiveX ?
Oder welche Funktionen nutzt du in Xbase++ ?

Ich gebrauche Excel zur Zeit nur zur Präsentation von Auswertungsergebnissen, welche meine Xbase++ Programme erzeugen, dazu reichts. Mit ODBC habe ich mit Excel nur mal so gespielt, das brauche ich aber nur für ACCESS Daten bzw. für meine privaten MySQL Zugänge in PowerBasic (andere Bibliothek).

Grundsätzlich meide ich Abhängigkeiten so gut es geht. (EXE hat alles selbst und braucht keine ActiveX etc.)

[olaf870]

Hallo Hubert,

Steuerst du Excel mit ActiveX ?
Oder welche Funktionen nutzt du in Xbase++ ?

Ich steuere Excel über ADO und das wieder über ActiveX, als auch direkt über ActiveX.
Apropo Abhängigkeit: Deine Unabhängigkeit ist NICHT da. Abhängig bist Du - wei alle anderen Xbase-Anwender von der win32.lib wie ein Baby von seiner Mutter. Deswegen ist es wohl ziemlich egal, ob Du dann auch noch ActiveX oder andere MS-Produkte benutzt.
Gruß
Olaf870

[brandelh]

Deswegen ist es wohl ziemlich egal, ob Du dann auch noch ActiveX oder andere MS-Produkte benutzt.

Hallo Olaf,

wenn diese standardmäßig installiert sind schon, aber ich z.B. habe noch Win2000 und kenne einige mit Win98. Soll ich jedesmal die M$ Bibliotheken mitliefern ?
Wenn ich in meinem Programm z.B. Funktionen von Access benutze, zwinge ich den Anwender sich die passende Access Version zu kaufen, das ist es was ich mit Abhängigkeiten meine. Bei meinen ODBC Versuchen bin ich noch unabhängig von der Version von Access, was für meinen speziellen Fall von großem Vorteil ist, da die Anwendung aktiv auf einer älteren Access Version läuft. Ist ADO da genauso frei (welche Version von z.B. Excel installiert ist) ? Da ich bis jetzt nur 1.82 Code habe, konnte ich das aber auch noch nicht machen.
Wenn ja schön, aber ich will niemand Excel aufzwingen wenn er es nicht hat, daher programmiere ich meine Auswertungen nicht mit Excel oder Access sondern mit meiner eigenen Druckerklasse (inkl. Grafiken, welche aber noch Handarbeit sind).

Aber viele Wege führen nach Rom und ich wollte nicht sagen, dass du einen Fehler machst.

[olaf870]

Hallo Hubert,
wenn man Excel oder Access für den Ausdruck aus Xbase benutzt, ist das ungefähr so, als verwendet man eine Lastwagen zum Einkauf von einem Pfund Kaffee. Obwoh das ja durch aus funktioniert, gibt es weitaus bessere Möglichkeiten, wie ich meine.
Gruß
Olaf870

[Jan]

Hallo Olaf,

wenn ich Hubert richtig verstanden habe will er ja gerade das umgehen. Nämlich aus Xbase++ Daten drucken, ohne das die eigentliche Anwendungssoftware (Access, Excel) extra dafür installiert ist. Was ich ebenfalls für einen richtigen Weg halte. Ich selber mag die MS-Programme nicht so sonderlich, auch wenn sie unbestreitbar einige Vorteile haben. Aber dadurch habe ich oftmals das Problem einige Dateien nicht bearbeiten zu können, nur weil der Daten-Bereitsteller zwangsmäßig voraussetzt, jeder Mensch auf der Welt müsste genau dieses Programm installiert haben.

Insbesondere im Industriebereich, aber auch bei vielen Büro-PC ist es ja so, daß man wirklich nur spezielle Software laufen lassen möchte/muß. Und wenn das eben gerade das Xbase++-Programm ist, die Daten aber aus welchem Grund auch immer Access oder Excel sind, dann halte ich es für sehr kostenintensiv und kontraproduktiv, nur zum Lesen dieser Daten auch diese Software installieren zu müssen.

Wenn also der Weg über ODBC performancemäßig in Ordnung ist würde ich das vermutlich ebenso machen.

Jan

[brandelh]

wenn ich Hubert richtig verstanden habe will er ja gerade das umgehen.

Genau !

Und für das Lesen der Daten anderer Dateien (Access, Excel) habe ich mit ODBC gute Erfahrungen gemacht, es sind ja nicht die Mengen.

Wenn ich die Datei selbst öffnen muß (auf meinem Entwicklungsrechner) nehme ich dazu OpenOffice. Aber meine Anwendungen selbst kommen ohne das alles aus. Ich drucke z.B. mit reinem Xbase++ Code.

[olaf870]

Hallo Jan,

ich hatte Hubert so verstanden, daß er nicht davon redet, proprietäre MS-Formate mit Xbase zu lesen oder zu schreiben, sondern lieber in Xbase geschriebene Routinen statt Excel oder Access zum Ausdruck benutzt. Und Excel oder Access zum Drucken zu benutzen, lag für mich sehr fern, da muß man ja erst einmal kommen, zumal das doch mit Xbase-pur auch wunderbar geht.
Wenn jetzt jetzt immer noch nicht klar ist, was ich meine, erlaube mir eine kleine Analogie: "Ich wohne weniger als 1 km von meinem Büro in Berlin entfernt. Ich wähle nun um in mein Büro zu kommen nicht eine Verbindung über Australien, sondern nehme lieber den kürzeren direkten Weg." Was ich normalerweise auch nicht für sonderlich erwähnenswert halten würde, weil mein Weg ins Büro eigentlich kein Problem darstellt (solange ich nicht über Australien dahin will). Das wollte ich eigentlich ausdrücken.
Gruß
Olaf870

[brandelh]

Hallo Olaf,

ich hatte Hubert so verstanden, daß er nicht davon redet, proprietäre MS-Formate mit Xbase zu lesen oder zu schreiben, sondern lieber in Xbase geschriebene Routinen statt Excel oder Access zum Ausdruck benutzt

Ich nutze und meinte sowohl den ODBC-Zugriff auf Accessformate und Excel-Formate, als auch, dass ich diese Anwendungen nicht für z.B. Druckaufgaben mißbrauche. Ich hatte nicht den Eindruck, dass du das tust, soweit sind wir völlig gleicher Meinung.

Ich kenne aber schon Leute die das tun, teilweise aus sehr unterschiedlichen Gründen (z.B. Serienbriefe, die der Anwender ändern können soll mit Word).

Mit der 1.90 und ActiveX ist die letzte Aufgabe sicherlich leichter und auch direkt aus Xbase heraus möglich geworden. Ich habe hauptsächlich Ausdrucke, die der Anwender nicht ändern soll (Rechtssicherheit) und werde das deshalb auch nicht nutzen.

Im übrigen ist es gut möglich, dass ich mich mißverständlich ausgedrückt habe, das kommt ab und zu vor

[AUGE_OHR]

hi,

Proc Excel97SelectCell( oSheet, nRow, nCol ) // Selects ONE only cell

sehe ich richtig das damit die "Cell" auch optisch "aktive" wird, als wenn ich mit der Maus in die Cell geclickt hätte ?

@Olaf : würdest du die Proc veröffentlichen ?

dazu suche ich noch das "umgekehrte", also eine Methode die mir zurück gibt welche "Cell aktive"
ist, also wo der User geclickt hat ?

[AUGE_OHR]

Proc Excel97SelectCell( oSheet, nRow, nCol ) // Selects ONE only cell

sehe ich richtig das damit die "Cell" auch optisch "aktive" wird, als wenn ich mit der Maus in die Cell geclickt hätte ?
@Olaf : würdest du die Proc veröffentlichen ?

ich habe es rausbekommen

Code: Alles auswählen

PROCEDURE GoToPos(oExcel,cPos)
LOCAL oSheet
   // only 1 Worksheets
   //
   oSheet := oExcel:Worksheets(1):cells
   //
   oSheet:Range(cPos):Select
   oSheet:Range(cPos):Activate
RETURN

dazu suche ich noch das "umgekehrte", also eine Methode die mir zurück gibt welche "Cell
aktive" ist, also wo der User geclickt hat ?

hm ... es gibt zwar einen BeforeDoubleClick Event, aber ich möchte ja schon eine "einfach" Click ...

Frage : könnte man, mit activeX, ein Sheet "so disable"n das ein User nicht mehr in das Sheet
reinclicken kann ... ?

[AUGE_OHR]

Code: Alles auswählen

DOSframer Beispiel

   ::oControl := XbpActiveXControl():new(...)
...
   ::oControl:CreateNew("Excel.Sheet")
   ::oExcel  := ::oControl:ActiveDocument()
   ::oExApp  := ::oExcel:Application
   // Load document need to pass full qualified filename
   ::oControl:Open( cTour )
..

::oPB01:activate := {|| TEST(::oControl,::oExcel,::oExApp) }

PROCEDURE TEST(oControl,oExcel,oApp)
LOCAL a
LOCAL b
   a := oExcel:Worksheets(1):activate()
   b := oApp:ActiveCell:Address()
   MSGBOX("Position "+b)

damit bekommt man die "aktuelle" Cell Address() z.b. $A$10

[Koverhage]

Jimmy,

// Also ensure the Excel application is Visible and block keyboard and mouse
// macht das ganze ein wenig schneller
oExcel:Interactive := .F.

wie oben steht, ist das Problem, das die Mouse und Keyboard abgeschaltet wird.

[AUGE_OHR]

hi,

// Also ensure the Excel application is Visible and block keyboard and mouse
// macht das ganze ein wenig schneller
oExcel:Interactive := .F.

wie oben steht, ist das Problem, das die Mouse und Keyboard abgeschaltet wird.

JA das ist die Property dafür.
Diese "wirkt" auch bei CreateObject("Excel.Application") aber leider nicht mit dem DSOframer

[brandelh]

Hi,

so wie ich das verstanden habe, soll der DSOFramer doch die Eventsteuerung "vereinfachen",
also müsste dieser selbst die Steuerung übernehmen und man muss "ihn" steuern ... aber wie

[AUGE_OHR]

so wie ich das verstanden habe, soll der DSOFramer doch die Eventsteuerung "vereinfachen",
also müsste dieser selbst die Steuerung übernehmen und man muss "ihn" steuern ... aber wie

dachte ich auch ... aber dem ist nicht so.

DSOframer hat nur "wenige" Events, Methoden und Property und die sind fast alle nur auf öffen,
sichern und so vorhanden. Für die einzelnen Office Produkte gibt es keinen einzigen Befehl.

Ich denke DSOframer soll "verhindern" das Programmieren das machen was ich gerade tue und
es in einen XbpDialog einbinde. Wenn ich die Toolbar und Menuleiste "abschalte" hab ich praktisch
nur noch einen "Viewer" und kann "fast nichts" machen.

so wie ich jetzt Excel verwende könnte ich auch darüber nachdenken das Array per XbpBrowse
zu bearbeiten ... die Anzeige unterscheidet sich optisch nicht so sehr.

Der wesentliche Unterschied ist das der User Excel verwenden kann "wie er will", aber das ist
eben nicht unbedingt "Maschinen-lesbar".

Ich bin aber strikt dagegen etwas "doppelt" zu machen, also erst Excel, ausdrucken und dann
wieder per Hand die Daten als Lieferschein erfassen ... NEIN das muss in einem Gang gehen ...