Excel-Daten
Moderator: Moderatoren
Excel-Daten
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
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
- Foren-Administrator
- Beiträge: 16517
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
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.
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.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
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:
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.
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
Gruß
Hubert
Hubert
-
- Rekursionen-Architekt
- Beiträge: 128
- Registriert: Mi, 26. Okt 2005 18:41
- Wohnort: Berlin
- Kontaktdaten:
Michael,
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
Die vorstehenden Beiträge sind sicherlich gut gemeint .. glücklicherweise kenne ich mich aber etwas aus:Daten von einer Excel Tabelle importieren, diese bearbeiten und
wieder nach Excel exportieren
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
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
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
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Hallo Olaf,olaf870 hat geschrieben:Michael,Die vorstehenden Beiträge sind sicherlich gut gemeint .. glücklicherweise kenne ich mich aber etwas aus:Daten von einer Excel Tabelle importieren, diese bearbeiten und
wieder nach Excel exportieren
gut das du dich damit auskennst,
könntest du uns Unwissenden die Quellen deiner Infos (Dokus, Bibliothek etc.) kund tun
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Hallo, Olaf.
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.
Schön, daß sich ein Einäugiger in den trüben, feuchtnassen Keller herabläßt, in dem wir Blinden hier hausen.glücklicherweise kenne ich mich aber etwas aus
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.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
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.)
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.)
Gruß
Hubert
Hubert
-
- Rekursionen-Architekt
- Beiträge: 128
- Registriert: Mi, 26. Okt 2005 18:41
- Wohnort: Berlin
- Kontaktdaten:
Hallo Hubert,
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
Ich steuere Excel über ADO und das wieder über ActiveX, als auch direkt über ActiveX.Steuerst du Excel mit ActiveX ?
Oder welche Funktionen nutzt du in Xbase++ ?
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
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Hallo Olaf,olaf870 hat geschrieben:Deswegen ist es wohl ziemlich egal, ob Du dann auch noch ActiveX oder andere MS-Produkte benutzt.
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.
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14655
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
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
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
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Genau !Jan hat geschrieben:wenn ich Hubert richtig verstanden habe will er ja gerade das umgehen.
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.
Gruß
Hubert
Hubert
-
- Rekursionen-Architekt
- Beiträge: 128
- Registriert: Mi, 26. Okt 2005 18:41
- Wohnort: Berlin
- Kontaktdaten:
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
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
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Hallo Olaf,
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
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.olaf870 hat geschrieben: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 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
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re:
hi,
@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 ?
sehe ich richtig das damit die "Cell" auch optisch "aktive" wird, als wenn ich mit der Maus in die Cell geclickt hätte ?olaf870 hat geschrieben:Proc Excel97SelectCell( oSheet, nRow, nCol ) // Selects ONE only cell
@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 ?
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Re:
ich habe es rausbekommenAUGE_OHR hat geschrieben:sehe ich richtig das damit die "Cell" auch optisch "aktive" wird, als wenn ich mit der Maus in die Cell geclickt hätte ?olaf870 hat geschrieben:Proc Excel97SelectCell( oSheet, nRow, nCol ) // Selects ONE only cell
@Olaf : würdest du die Proc veröffentlichen ?
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
hm ... es gibt zwar einen BeforeDoubleClick Event, aber ich möchte ja schon eine "einfach" Click ...AUGE_OHR hat geschrieben: dazu suche ich noch das "umgekehrte", also eine Methode die mir zurück gibt welche "Cell
aktive" ist, also wo der User geclickt hat ?
Frage : könnte man, mit activeX, ein Sheet "so disable"n das ein User nicht mehr in das Sheet
reinclicken kann ... ?
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Excel-Daten
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)
gruss by OHR
Jimmy
Jimmy
- Koverhage
- Der Entwickler von "Deep Thought"
- Beiträge: 2470
- Registriert: Fr, 23. Dez 2005 8:00
- Wohnort: Aalen
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Excel-Daten
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.
// 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.
Gruß
Klaus
Klaus
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Excel-Daten
hi,
Diese "wirkt" auch bei CreateObject("Excel.Application") aber leider nicht mit dem DSOframer
JA das ist die Property dafür.Koverhage hat geschrieben:// 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.
Diese "wirkt" auch bei CreateObject("Excel.Application") aber leider nicht mit dem DSOframer
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Excel-Daten
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
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
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Excel-Daten
dachte ich auch ... aber dem ist nicht so.brandelh hat geschrieben: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
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 ...
gruss by OHR
Jimmy
Jimmy