Mit VBA Excel-Datei erkennen
Guido Hesterberg
gibt es eine Möglichkeit, mit VBA eindeutig zu erkennen, ob eine Datei
eine wirkliche Excel-Datei ist?
Hintergrund: Meine Anwendung erlaubt das Importieren von Dateien. Es
kann aber sein, daß die zu importierende Datei
1.
zwar eine Excel-Datei ist, aber eine falsche Endung hat (dann prüfen,
ob es eine Update-Datei für meine Anwendung ist) und
2.
zwar die richtige Endung hat, aber der Benutzer aus Versehen auf
irgendeine falsche Excel-Datei geklickt hat (wiederum prüfen, ob es
denn eine Update-Datei ist).
Vor dem wirklichen Öffnen "schnüffelt" meine Anwendung hinein, indem
sie die gesamte Datei als Text in eine Variable einliest, die dann als
Text vorliegt. So möchte ich unerwünschte Effekte umgehen, falls es
eine falsche Datei ist und ich nicht weiß, was Excel so alles
anstellt, wenn mit Open eine falsche Datei geöffnet wird.
Ich habe mir zur Überprüfung, ob es eine Update-Datei ist, damit
beholfen, daß ich festgestellt habe, daß bestimmte Namen im Klartext
in diesem String vorkommen. Wenn bestimmte Zeichenfolgen vorkommen (die
ich angemessen eindeutig für meine Anwendung festgelegt habe), ist es
eine Update-Datei, und sie wird auf normalem Weg importiert.
Was ich aber bräuchte, wäre eine etwas sicherere Lösung zur
Feststellung der Dateiart. Unter anderem sollen folgende Dateien
importiert werden:
a) .bas (Das sind normale Textdateien, oder? Hier möchte ich an eine
bestimmte Stelle einen eindeutigen Kommentar schreiben, der erkannt
wird)
b) .frm (auch Textdateien, wenn ich mich nicht irre, die zudem den
Fenstercode enthalten, also wäre auch hier ein Kommentar mit
erkennbaren Schlüsselwörtern möglich)
c) .frx (schon schwieriger, aber ich habe festgestellt, daß die
Bezeichnungen der Steuerelemente im Klartext vorhanden sind, also
möchte ich z. B. ein unsichtbares Label einfügen mit einer
eindeutigen .Name-Eigenschaft)
d) .cls (sind wohl auch Textdateien, sollte so funktionieren wie .bas
und .frm)
e) .xls (Hier habe ich am meisten Zweifel, ob Excel nicht mal eben
intern seine Dateistruktur umwirft und meine Namen zerhackt...)
f) .chm (etwas off-topic, aber wenn jemand eine Lösung weiß...) :-)
Die .xls-Dateien können auch von anderen Personen gepflegt werden,
daher ist der Dateiname nicht vorhersagbar. Für den Inhalt könnte ich
gewisse Regeln vorschreiben (z. B. keine Tabellenblätter umbenennen,
damit die Namen erkennbar bleiben), aber eine Zuweisung von
Dateieigenschaften durch andere Personen kommt nicht in Frage, da zu
fehleranfällig.
Bin gespannt auf Eure Ideen...
Danke im voraus und viele Grüße
Guido
Reiner Wolff
leider habe ich trotz Deiner ausführlichen Beschreibung lediglich
verstanden, dass Du irgendwelche Dateien importieren willst.
Nicht verstanden habe ich allerdings, wohin, warum und woher sie kommen :-(
*Guido Hesterberg* schrieb:
> gibt es eine Möglichkeit, mit VBA eindeutig zu erkennen, ob eine Datei
> eine wirkliche Excel-Datei ist?
Normaler Weise sind Excel-Dateien an Ihrer Endung zu erkennen ;-)
Inhaltlich ansonsten daran, dass der Zugriff problemlos klappt.
> Hintergrund: Meine Anwendung erlaubt das Importieren von Dateien.
Deine Anwendung ist ein in Excel geschriebenes Programm?
Was macht Deine Anwendung?
> Es kann aber sein, daß die zu importierende Datei
> 1. zwar eine Excel-Datei ist, aber eine falsche Endung hat (dann prüfen,
> ob es eine Update-Datei für meine Anwendung ist) und
Update-Dateien kommen von Dir oder macht die irgendwer anders?
Warum werden Update-Dateien mit normalen Dateien vermischt?
Wie funktioniert überhaupt Dein Import?
> 2. zwar die richtige Endung hat, aber der Benutzer aus Versehen auf
> irgendeine falsche Excel-Datei geklickt hat (wiederum prüfen, ob es denn
> eine Update-Datei ist).
Falsche Excel-Dateien sind Dateien, die nicht zu Deiner Anwendung passen?
Mach Deine Excel-Dateien eindeutig. Dazu kannst Du die Datei mit eigenen
Properties oder Variablen ausstatten, oder die Tabellenstruktur zB mit ADO
vor dem Öffnen abfragen.
> Vor dem wirklichen Öffnen "schnüffelt" meine Anwendung hinein, indem sie
> die gesamte Datei als Text in eine Variable einliest, die dann als Text
> vorliegt.
Das Einlesen einer XLS-Datei als Text macht imho nicht wirklich viel Sinn.
> Was ich aber bräuchte, wäre eine etwas sicherere Lösung zur Feststellung
> der Dateiart. Unter anderem sollen folgende Dateien importiert werden:
> a) .bas
> b) .frm
> c) .frx
> d) .cls
Dabei handelt es sich nicht um eine Excel-Dateien.
Was macht Deine Anwendung mit diesen Dateien denn?
> e) .xls (Hier habe ich am meisten Zweifel, ob Excel nicht mal eben intern
> seine Dateistruktur umwirft und meine Namen zerhackt...)
ThisWorkbook.CustomDocumentProperties
oder Tabellenstruktur via ADO überprüfen
Dazu könnten Dir folgende Links weiterhelfen:
How To Use ADO with Excel Data from Visual Basic or VBA
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q257819
How To Transfer Data from ADO Data Source to Excel with ADO
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q295646
> f) .chm (etwas
> off-topic, aber wenn jemand eine Lösung weiß...) :-)
Was willst Du mit diesen Dateien machen?
Normaler Weise kann man sich auf die Dateiendung verlassen.
> Die .xls-Dateien können auch von anderen Personen gepflegt werden, daher
> ist der Dateiname nicht vorhersagbar.
Ok.
> Für den Inhalt könnte ich gewisse
> Regeln vorschreiben (z. B. keine Tabellenblätter umbenennen, damit die
> Namen erkennbar bleiben), aber eine Zuweisung von Dateieigenschaften
> durch andere Personen kommt nicht in Frage, da zu fehleranfällig.
Aber Dein Programm oder eine Funktion von Dir könnte doch die Pflege von
Dateieigenschaften übernehmen, oder?
> Bin gespannt auf Eure Ideen...
Ohne weitere Hintergrundinfos über das globale Ziel, fällt mir und meiner
Glaskugel dazu leider nichts weiter ein.
Gruß aus Kiel
Reiner
--
Wenn irgendwas mit deinem Computer nicht stimmt, sag deiner Sekretärin,
dass sie die EDV-Abteilung anrufen soll. Wir lieben das Spielchen,
mit einer dritten Person ein Problem zu klären,
von dem Sie absolut überhaupt nichts weiss.
Helmut Weber
theoretisch wohl nicht entscheidbar,
was eine richtige Datei für eine Anwendung ist.
Wenn ich in einer Word-Datei mit einem Editor
ein einziges Zeichen ändere, und Pech habe,
oder wie man es nennen will, erkennt Word die Datei
nicht mehr. Ist es dann keine Word-Datei mehr?
Oder ist es nur eine fehlerhafte Word-Datei?
Dürfte mit Excel nicht anders sein.
Man könnte dem Workbook eine Customdocumentproperty mitgeben:
Etwa so:
ActiveWorkbook.CustomDocumentProperties.Add _
Name:="Test", LinkToContent:=False, _
Type:=msoPropertyTypeString, _
Value:="109238190238109238190238"
Und dann in dem eingelesenen String nach
"109238190238109238190238" suchen.
Was aber im Prinzip auch nichts anders ist
als irgendwohin was zur Identifizierung schreiben.
Nur kommt der Normalverbraucher an die
CustomDocumentProperties nicht ran.
Allerdings kann jeder Schlüssel durch Zufall geknackt werden.
--
Gruß
Helmut Weber, MVP WordVBA
"red.sys" & chr$(64) & "t-online.de"
Win XP, Office 2003 (US-Versions)
Helmut Weber
mit ziemlich viel rumklicken kommt er schon ran.
Gibt's in Excel keine Docvariables wie in Word?
Guido Hesterberg
vielen Dank für Deine Antwort. Zu Deinen Ausführungen im einzelnen:
> leider habe ich trotz Deiner ausführlichen Beschreibung lediglich
> verstanden, dass Du irgendwelche Dateien importieren willst.
> Nicht verstanden habe ich allerdings, wohin, warum und woher sie kommen :-(
> Normaler Weise sind Excel-Dateien an Ihrer Endung zu erkennen ;-)
> Inhaltlich ansonsten daran, dass der Zugriff problemlos klappt.
> Deine Anwendung ist ein in Excel geschriebenes Programm?
> Was macht Deine Anwendung?
Meine Anwendung ist eine .xls-Datei mit sehr viel VBA-Code für
verschiedene Aktionen mit Kundendaten. Außerdem verwaltet sie neben
den Kundendaten z. B. auch Daten von Gesellschaften, mit denen die
Kunden Verträge schließen können.
Die Anwendung (ich nenne sie jetzt mal so, um sie von den anderen
.xls-Dateien abzugrenzen) wird später von einer Vielzahl von Kollegen
in unserer Firma benutzt, jeder mit einem eigenen Kundenstamm. Für
alle möglichen Updates meiner Anwendung gibt es nur eine einzige
Schaltfläche, um es für den Benutzer so einfach wie möglich zu
machen. Diese öffnet ein Dialogfeld, mit dem der Benutzer die Datei
auswählen kann. Aufgrund der Dateiart (die aber nicht unbedingt an der
Dateiendung festgemacht sein muß), entscheidet die Anwendung dann, was
zu tun ist, nach einer Sicherheitsabfrage. Mögliche Importe:
- Geänderte Gesellschaftsdaten (.xls). Die zu importierende Datei
enhält nur ein Tabellenblatt mit den neuen Daten. Das alte Blatt in
der Anwendung wird gelöscht und durch das neue ersetzt.
Gesellschaftsdaten werden (noch) von mir, später von anderen gepflegt
und verteilt.
- Geänderte Kundendaten (.txt). Kundendaten werden von einer anderen
Anwendung generiert, auf die ich keinen Einfluß habe. Da nicht klar
ist, wieviele Spalten diese Kundendaten enthalten (das lege nicht ich
fest, sondern die Firma), MUSS ich vorher reinschnüffeln und die
Anzahl der Spalten bestimmen, sonst komme ich mit dem vordefinierten
Excel-Import für .txt-Dateien nicht klar, weil ich dort den
Array-Cluster mit angeben muß. Da ich die Datei aber dann sowieso
schon in einer Textvariable habe, importiere ich erst gar nicht weiter,
sondern ziehe die Daten aus der Variablen in ein Array.
- Software-Updates, die ich geschrieben habe, sowohl für
VBA-Funktionserweiterungen als auch Schönheitskorrekturen (.bas, .cls,
.frm, .frx). Software-Updates kommen immer von mir. Diese Dateien
werden über das VBE-Objekt importiert, die bisher vorhandenen Module
und Forms ersetzt.
- Updates der Hilfedatei (.chm). Hilfe-Updates kommen immer von mir.
Die vorhandene Hilfedatei wird durch die zu importierende ersetzt.
> Update-Dateien kommen von Dir oder macht die irgendwer anders?
s. o.
> Warum werden Update-Dateien mit normalen Dateien vermischt?
Weil sie in der Regel per E-Mail an die Benutzer verteilt werden und
der Benutzer sie gottweißwohin speichern kann, bevor er sie mit der
Anwendung importiert.
> Wie funktioniert überhaupt Dein Import?
s. o.
> Falsche Excel-Dateien sind Dateien, die nicht zu Deiner Anwendung passen?
Ja, genau.
> Mach Deine Excel-Dateien eindeutig. Dazu kannst Du die Datei mit eigenen
> Properties oder Variablen ausstatten, oder die Tabellenstruktur zB mit ADO
> vor dem Öffnen abfragen.
Hm, ja, Properties und Variablen, das wär noch was... Würde aber
wieder voraussetzen:
- Sich auf .xls-Dateiendung verlassen
- Datenverbindung herstellen oder Variablen abfragen
Bei jedem dieser Vorgänge müßte ich gesonderte Fehler abfangen. Das
Einlesen als Text funktioniert dagegen immer, völlig egal, welche
Datei eingelesen wird, und ohne komplexere Excel-Importroutinen oder
Datenverbindungen zu aktivieren, die fehleranfälliger als bitweises
Einlesen sind.
> Das Einlesen einer XLS-Datei als Text macht imho nicht wirklich viel Sinn.
s. o. Das kommt daher, weil ich auch andere als .xls-Dateien mit
derselben Funktion importiere. Zum Beipiel kann die Firma morgen auf
die Idee kommen, die Kundendaten nicht mehr als .txt, sondern als .csv
zu speichern, ohne daß ich sofort was davon mitbekomme. Da meine
Anwendung erst den Inhalt der Datei auf bestimmte Schlüsselwörter
überprüft, die abgefahren genug sind, daß sie mit hoher
Wahrscheinlichkeit nicht in "falschen" Dateien vorkommen, kann mir
sowas wie Dateiendungen egal sein.
> > Was ich aber bräuchte, wäre eine etwas sicherere Lösung zur Feststellung
> > der Dateiart. Unter anderem sollen folgende Dateien importiert werden:
> > a) .bas
> > b) .frm
> > c) .frx
> > d) .cls
>
> Dabei handelt es sich nicht um eine Excel-Dateien.
> Was macht Deine Anwendung mit diesen Dateien denn?
Naja, in gewisser Weise sind es schon Excel-Dateien, wenn auch eher
Office-VBA-Dateien, die aber in die Excel-Datei eingebaut werden. S. o.
> > e) .xls (Hier habe ich am meisten Zweifel, ob Excel nicht mal eben intern
> > seine Dateistruktur umwirft und meine Namen zerhackt...)
>
> ThisWorkbook.CustomDocumentProperties
Das wär vielleicht wirklich eine Lösung. Muß ein Workbook geöffnet
sein, um die CustomDocumentProperties abzufragen? Ich hätte sie gern
VOR dem Öffnen abgefragt, da auf unseren Rechnern zum Teil extrem
große Dateien rumschwirren, die Excel erstmal aus der Bahn werfen
würden, wenn es versucht die auf konventionelle Art zu importieren.
> Aber Dein Programm oder eine Funktion von Dir könnte doch die Pflege von
> Dateieigenschaften übernehmen, oder?
Bei allen, die ich selbst schreibe, ja, bei den anderen nicht. Das sind
teilweise auch Leute, die mit Programmierung und Dateieigenschaften
nichts am Hut haben.
> Ohne weitere Hintergrundinfos über das globale Ziel, fällt mir und meiner
> Glaskugel dazu leider nichts weiter ein.
Oh, hat mir schon sehr geholfen. Da Du keinen Vollalarm wegen des
zeichenweisen Einlesens gegeben hast und außerdem noch den Hinweis mit
den CustomProps, bin ich schon sehr zufrieden... :-)
Gruß
Guido
Guido Hesterberg
>
> mit ziemlich viel rumklicken kommt er schon ran.
>
> Gibt's in Excel keine Docvariables wie in Word?
Hallo Helmut,
es ist nicht so sehr eine Sicherheitsfrage, meine Anwendung wird
ohnehin nur innerhalb der Firma verteilt und der Code wird
höchstwahrscheinlich offen sein, weil ich zur Laufzeit Änderungen am
Codemodul vornehmen muß.
Ich möchte nur verhindern, daß versehentlich eine falsche Datei
importiert wird und Schaden anrichtet. Wenn jemand rumklicken will,
darf er das tun. Das einzige, was meine Anwendung können muß, ist,
verschiedene Dateiarten, die mit ein und derselben Funktion importiert
werden, auseinanderzuhalten - unabhängig von der Dateiendung.
Das mit den Docvariables entspricht wohl den CustomProps, die Reiner
beschreiben hat. Wäre einen Versuch wert, aber .bas-, .cls-, .frm-,
.frx- und .chm-Dateien haben mit Sicherheit keine - jedenfalls nicht,
daß ich wüßte.
Danke und Gruß
Guido
Helmut Weber
hm... ob sich da in jeder der Dateien ein Plätzchen finden,
an das man einen Code schreiben kann?
Bei bas und frm gleich an den Anfang,
dann kann man die Prüfung schnell abbrechen.
Aber bei den anderen?
Ich würde mal bei den Hardcore-Programmierern fragen.
Eigentlich ist es ja nichts anderes als eine primitive Signatur.
Guido Hesterberg
> hm... ob sich da in jeder der Dateien ein Plätzchen finden,
> an das man einen Code schreiben kann?
> Bei bas und frm gleich an den Anfang,
> dann kann man die Prüfung schnell abbrechen.
>
> Aber bei den anderen?
Auf die Idee bin ich noch gar nicht gekommen, die Datei gleich schon
während des Binary-Einlesens auf Bezeichner zu prüfen und dann
abzubrechen, wenn falsch.
Coole Idee eigentlich... Aber gerade weil bei xls, chm und frx nicht
steuerbar ist, an welcher Stelle meine Bezeichner stehen, muß ich die
Datei trotzdem ganz einlesen. Das verläuft aber auch bei großen
Dateien völlig problemlos bisher. Und da ein String lauf Onlinehilfe
bis zu 2^31 Zeichen aufnehmen kann und ich niemals 2 GB große
Updatedateien haben werde, sehe ich auch kein Problem bei der
Dateigröße.
Wie gesagt, ich habe halt bemerkt, daß bei xls, chm und frx bestimmte
Bezeichner immer im Klartext drinstehen, nur weiß ich halt nicht, ob
das wirklich immer so ist (xls: hab ich gerade vergessen, chm: Namen
von Topic-Dateien, frx: Bezeichner von Steuerelementen).
> Ich würde mal bei den Hardcore-Programmierern fragen.
> Eigentlich ist es ja nichts anderes als eine primitive Signatur.
Hm, in welcher Newsgroup tummeln die sich denn? Ich hatte es hier
gepostet, weil ich dachte, über die Struktur von Excel-Dateien wißt
am ehesten Ihr Bescheid. Und eine .frx-Datei ist ja auch irgendwie
Office-spezifisch. Ob VB-Leute über Excel-Dateiaufbau Bescheid wissen?
Wäre dankbar für einen Tip
Viele Grüße
Guido
Helmut Weber
>> Ich würde mal bei den Hardcore-Programmierern fragen.
>> Eigentlich ist es ja nichts anderes als eine primitive Signatur.
fürs Deutsche würde ich in ...de.vb fragen.
Dort habe ich schon viel gelernt.
Es ist allerdings so, dass man in
den englischsprachigen Groups zehnmal soviele Leute erreicht,
mindestens, die jedoch auch alle nur mit Wasser kochen.
Wüsste nicht, dass ich dort was entscheidend anderes
oder besseres als in den deutschen Gruppen gelesen hätte.
Reiner Wolff
*Guido Hesterberg* schrieb:
> vielen Dank für Deine Antwort.
Büdde.
>> Deine Anwendung ist ein in Excel geschriebenes Programm?
>> Was macht Deine Anwendung?
> Meine Anwendung ist eine .xls-Datei mit sehr viel VBA-Code für
> verschiedene Aktionen mit Kundendaten. Außerdem verwaltet sie neben
> den Kundendaten z. B. auch Daten von Gesellschaften, mit denen die
> Kunden Verträge schließen können.
> Die Anwendung (ich nenne sie jetzt mal so, um sie von den anderen
> .xls-Dateien abzugrenzen) wird später von einer Vielzahl von Kollegen
> in unserer Firma benutzt, jeder mit einem eigenen Kundenstamm.
Danke für die Erläuterung.
> Für alle möglichen Updates meiner Anwendung gibt es nur eine einzige
> Schaltfläche, um es für den Benutzer so einfach wie möglich zu machen.
Demnach ist dir Durchführung eines Updates nicht Pflicht.
Wäre es trotzdem denkbar Update-Dateien an einem Zentralen Ablageort (zB
UNC-Pfad) abzulegen und das Update beim Start der Anwendung automatisch und
ohne Knopfdruck durchzuführen?
Nur so als Hinweis zu "um es für den Benutzer so einfach wie möglich zu
machen."
> Diese öffnet ein Dialogfeld, mit dem der Benutzer die Datei auswählen
> kann. Aufgrund der Dateiart (die aber nicht unbedingt an der Dateiendung
> festgemacht sein muß), entscheidet die Anwendung dann, was zu tun ist,
> nach einer Sicherheitsabfrage. Mögliche Importe:
Verstehe ich das richtig? Der Benutzer muss jede Datei (XLS-Update, cls,
frm, cls) für ein Update einzeln anwählen?
> - Geänderte Gesellschaftsdaten (.xls). Die zu importierende Datei
> enhält nur ein Tabellenblatt mit den neuen Daten. Das alte Blatt in
> der Anwendung wird gelöscht und durch das neue ersetzt.
> Gesellschaftsdaten werden (noch) von mir, später von anderen gepflegt
> und verteilt.
Ok, sind derzeit kein Problem, oder?
> - Geänderte Kundendaten (.txt). Kundendaten werden von einer anderen
> Anwendung generiert, auf die ich keinen Einfluß habe. Da nicht klar
> ist, wieviele Spalten diese Kundendaten enthalten (das lege nicht ich
> fest, sondern die Firma), MUSS ich vorher reinschnüffeln und die
> Anzahl der Spalten bestimmen, sonst komme ich mit dem vordefinierten
> Excel-Import für .txt-Dateien nicht klar, weil ich dort den
> Array-Cluster mit angeben muß. Da ich die Datei aber dann sowieso
> schon in einer Textvariable habe, importiere ich erst gar nicht weiter,
> sondern ziehe die Daten aus der Variablen in ein Array.
Läuft demnach auch gut und rund.
> - Software-Updates, die ich geschrieben habe, sowohl für
> VBA-Funktionserweiterungen als auch Schönheitskorrekturen (.bas, .cls,
> .frm, .frx). Software-Updates kommen immer von mir. Diese Dateien
> werden über das VBE-Objekt importiert, die bisher vorhandenen Module
> und Forms ersetzt.
Solltest Du meine Meinung zu einer derartigen Vorgehensweise nicht kennen:
Ich halte von derartigen Importen oder CodeÄnderungen zur Laufzeit
überhaupt nichts.
Prinzipiell würde ich Dir dafür empfehlen, den Code in den Arbeitsdateien
einmal generell zu schreiben und von dort aus die Programmsteuerung an eine
weitere Datei zu übergeben, die Du dann unabhängig von den Daten
aktualisieren kannst.
Es macht insbesondere das Update ungleich einfacher, wenn Du einfach eine
Datei austauschen kannst und nicht erstmal den Dateityp erkennen musst, um
sie dann einzeln zu importieren.
> - Updates der Hilfedatei (.chm). Hilfe-Updates kommen immer von mir.
> Die vorhandene Hilfedatei wird durch die zu importierende ersetzt.
Ja, so könnte es auch mit der Programm.xls laufen.
Hast Du schonmal über die Benutzung eines Setup-Programmes nachgedacht?
Ich arbeite bei soetwas entweder mit einer AutoUpdate-Routine oder verteile
dergleichen mit InnoSetup.
>> Warum werden Update-Dateien mit normalen Dateien vermischt?
> Weil sie in der Regel per E-Mail an die Benutzer verteilt werden und
> der Benutzer sie gottweißwohin speichern kann, bevor er sie mit der
> Anwendung importiert.
Das klingt nicht nach einem gemeinsamen Netzwerk.
Damit kämen wir zu einer Setup-Routine. ;-)
>> Mach Deine Excel-Dateien eindeutig. Dazu kannst Du die Datei mit eigenen
>> Properties oder Variablen ausstatten, oder die Tabellenstruktur zB mit ADO
>> vor dem Öffnen abfragen.
Ich ziehe diesen Vorschlag nach den erhaltenen Infos zurück.
Deine Dateien sind ja schon eindeutig (entweder nur ein Blatt mit
bestimmten Inhalten an bestimmten Stellen oder Text-Dateien eines
Drittanbieters).
Sind in Deinen Bezeichnung eigentlich Programmupdate-Dateien und
Datenupdate-Dateien beide einfach nur Update-Dateien?
> Bei jedem dieser Vorgänge müßte ich gesonderte Fehler abfangen. Das
> Einlesen als Text funktioniert dagegen immer, völlig egal, welche
> Datei eingelesen wird, und ohne komplexere Excel-Importroutinen oder
> Datenverbindungen zu aktivieren, die fehleranfälliger als bitweises
> Einlesen sind.
Tja, Du weißt bloß nicht, ob Du Dich darauf verlassen kannst.
Was nützt Dir eine Variante, auf die Du Dich nicht verlassen willst.
Auch hier wirst Du ggf. Fehlerabwehr betreiben müssen (zB das Benutzer
unnütze Dateien ausgewählt haben).
>> Das Einlesen einer XLS-Datei als Text macht imho nicht wirklich viel Sinn.
> s. o. Das kommt daher, weil ich auch andere als .xls-Dateien mit
> derselben Funktion importiere. Zum Beipiel kann die Firma morgen auf
> die Idee kommen, die Kundendaten nicht mehr als .txt, sondern als .csv
> zu speichern, ohne daß ich sofort was davon mitbekomme.
Wenn der Drittanbieter lediglich seine Dateiendung von txt auf csv ändert,
kann es Dir egal sein.
Wenn er aber inhaltlich an seinen Dateien grundlegend etwas ändert, wirst
Du Dein Programm eh daran anpassen müssen.
>>> Was ich aber bräuchte, wäre eine etwas sicherere Lösung zur Feststellung
>>> der Dateiart. Unter anderem sollen folgende Dateien importiert werden:
>>> a) .bas
>>> b) .frm
>>> c) .frx
>>> d) .cls
>> Dabei handelt es sich nicht um eine Excel-Dateien.
>> Was macht Deine Anwendung mit diesen Dateien denn?
> Naja, in gewisser Weise sind es schon Excel-Dateien, wenn auch eher
> Office-VBA-Dateien, die aber in die Excel-Datei eingebaut werden. S. o.
Ich weiß ja was Du meinst, aber ich sag' dazu auch mal s.o. ;-)
>> Ohne weitere Hintergrundinfos über das globale Ziel, fällt mir und meiner
>> Glaskugel dazu leider nichts weiter ein.
> Oh, hat mir schon sehr geholfen. Da Du keinen Vollalarm wegen des
> zeichenweisen Einlesens gegeben hast und außerdem noch den Hinweis mit
> den CustomProps, bin ich schon sehr zufrieden... :-)
Dank
Gruß aus Kiel
Reiner
--
So weit wir wissen, hatte unser Computer nie einen unentdeckten Fehler.
Guido Hesterberg
> Demnach ist dir Durchführung eines Updates nicht Pflicht.
> Wäre es trotzdem denkbar Update-Dateien an einem Zentralen Ablageort (zB
> UNC-Pfad) abzulegen und das Update beim Start der Anwendung automatisch und
> ohne Knopfdruck durchzuführen?
> Nur so als Hinweis zu "um es für den Benutzer so einfach wie möglich zu
> machen."
Wär natürlich einen Lösung, aber ich bin selbst nur einer der
"Kollegen" ohne Schreibrechte für zentrale Datenbanken usw. Kann aber
gut sein, daß meine Anwendung später mal auch "offiziell" wird, nur
vorerst eben nicht.
> Verstehe ich das richtig? Der Benutzer muss jede Datei (XLS-Update, cls,
> frm, cls) für ein Update einzeln anwählen?
Er kann - er kann ja auch mehrere gleichzeitig markieren, die dann
importiert werden. Aber ich weiß, worauf Du anspielst, wäre mühsam,
wenn ich 10 Dateien schicke und er jede einzeln anklicken muß. Meine
Updates werden sich aber im Rahmen halten, denke ich. Nur mal ein Modul
oder ein verbessertes Fenster oder so... Du bringst mich aber auf eine
Idee... So eine Art Update.xls, die dann die anderen Dateien nachlädt,
falls es mal mehrere sein sollten.
> > - Geänderte Gesellschaftsdaten (.xls). Die zu importierende Datei
> > enhält nur ein Tabellenblatt mit den neuen Daten. Das alte Blatt in
> > der Anwendung wird gelöscht und durch das neue ersetzt.
> > Gesellschaftsdaten werden (noch) von mir, später von anderen gepflegt
> > und verteilt.
>
> Ok, sind derzeit kein Problem, oder?
Doch, schon, deswegen war ich überhaupt darauf gekommen, schon vor dem
Öffnen in eine Datei zu schnüffeln. Es gibt auf der Festplatte der
Benutzer .xls-Dateien, die einen kompletten Stillstand meiner Anwendung
beim "normalen" Öffnen verursachen, weil sie ihrerseits wieder Makros
und so'n Zeugs in sich haben... Code ist aber nicht offen, so daß ich
nicht weiß, was genau das verursacht. Ich habe auch keine Lust, alles
abzufangen, was unsere IT-Abteilung so geschrieben hat. Daher dachte
ich, der einfachste Weg ist, in dem binär eingelesenen Text nach
meinen eindeutigen Wörtern zu suchen und überhaupt nur zu öffnen,
was den Test bestanden hat.
> > [...]
> > Array-Cluster mit angeben muß. Da ich die Datei aber dann sowieso
> > schon in einer Textvariable habe, importiere ich erst gar nicht weiter,
> > sondern ziehe die Daten aus der Variablen in ein Array.
>
> Läuft demnach auch gut und rund.
Ja, geht prima.
> > - Software-Updates, die ich geschrieben habe, sowohl für
> > VBA-Funktionserweiterungen als auch Schönheitskorrekturen (.bas, .cls,
> > .frm, .frx). Software-Updates kommen immer von mir. Diese Dateien
> > werden über das VBE-Objekt importiert, die bisher vorhandenen Module
> > und Forms ersetzt.
>
> Solltest Du meine Meinung zu einer derartigen Vorgehensweise nicht kennen:
> Ich halte von derartigen Importen oder CodeÄnderungen zur Laufzeit
> überhaupt nichts.
>
> Prinzipiell würde ich Dir dafür empfehlen, den Code in den Arbeitsdateien
> einmal generell zu schreiben und von dort aus die Programmsteuerung an eine
> weitere Datei zu übergeben, die Du dann unabhängig von den Daten
> aktualisieren kannst.
> Es macht insbesondere das Update ungleich einfacher, wenn Du einfach eine
> Datei austauschen kannst und nicht erstmal den Dateityp erkennen musst, um
> sie dann einzeln zu importieren.
Hm... Eigentlich keine schlechte Idee, aber:
- Meine Kollegen haben immer nur _eine_ Kundendatei, und es sollen
nicht noch tausend andere herumschwirren.
- Bei 23 Modulen und über 5.000 Zeilen Code würde das einiges an
ausgelagerten Dateien ergeben...
- Da diese Dateien im Ernstfall wahrscheinlich während des Updates
gerader geöffnet sind, ergibt das bestimmt wieder Konflikte.
> Hast Du schonmal über die Benutzung eines Setup-Programmes nachgedacht?
> Ich arbeite bei soetwas entweder mit einer AutoUpdate-Routine oder verteile
> dergleichen mit InnoSetup.
Die IT-Abteilung tötet mich! :-) Wir dürfen auf unseren Rechnern
keinerlei Software installieren, und dann taucht auch noch eine
undurchsichtige .exe auf, die Dateien installiert... Aber das wäre
natürlich die sauberste Lösung, stimme Dir zu. Vielleicht kommt das
auch mal irgendwann, wenn sich meine Anwendung bewährt hat und ich mit
der IT-Abteilung zusammenarbeite. Bislang aber möchte ich erstmal,
daß die Kollegen meine Anwendung auf Alltagstauglichkeit testen. Nur
sind es halt sehr viele Kollegen, und wenn sie einmal ihre Kundendaten
in die Datei eingefügt und die Kundentabelle vielleicht sogar nach
ihren Bedürfnissen angepaßt haben, kann ich sie nicht immer wieder
dazu zwingen, ihre Kundendaten und Anpassungen in jede verbesserte
Datei zu übertragen, die ich ihnen schicke. Deshalb fand ich es die
beste Lösung, wenn meine Anwendung nur ein einziges Mal an den
Benutzer angepaßt wird (sie stellt übrigens von selbst fest, wenn ein
Benutzerwechsel stattfindet). Dann kann der Benutzer "auf ewig" mit
dieser Datei weiterarbeiten und sie verbiegen, wie er will (bis auf den
Code natürlich). Wenn was Neues von mir kommt, kann der Benutzer das
einfach in seine vorhandene Datei aufsaugen.
> Das klingt nicht nach einem gemeinsamen Netzwerk.
> Damit kämen wir zu einer Setup-Routine. ;-)
Doch, ist alles vorhanden, mit professioneller Distribution neuer
Releases von anderer Software und allem Drum und Dran - aber eben nur
von der IT-Abteilung.
Und bei diesen Distributionen hat mich schon immer geärgert, daß z.
B. meine Word-Anpassungen jedesmal überschrieben wurden, wenn eine
neue Version installiert wurde. Mit meiner Anwendung passiert das
nicht. Der Benutzer behält immer "seine" persönliche Datei, in die er
meinetwegen auch eine Spalte für die Haarfarbe der Kunden einfügen
kann. Bei Updates werden diese immer in seine eigene Datei eingebaut.
> Sind in Deinen Bezeichnung eigentlich Programmupdate-Dateien und
> Datenupdate-Dateien beide einfach nur Update-Dateien?
Ich verstehe die Frage nicht ganz. Wenn ich sie richtig deute: Ja. Ich
schicke eine Mail an die registrierten Benutzer, in der sich die eine
oder andere Datei befindet, schreibe ihnen: "Speichert das und klickt
in Eurer Kundentabelle auf Importieren", das war's. Egal, ob ein Modul,
Gesellschaftsdaten oder die Hilfedatei ausgetauscht wird. In der Mail
wird natürlich erwähnt, was geupdatet wird, Kenner werden es
überdies an der Dateiendung erkennen, und in der Import-Routine wird
nochmal gefragt: "Sie wollen [dies und das] importieren. Wirklich
jetzt?"
> > Bei jedem dieser Vorgänge müßte ich gesonderte Fehler abfangen. Das
> > Einlesen als Text funktioniert dagegen immer, völlig egal, welche
> > Datei eingelesen wird, und ohne komplexere Excel-Importroutinen oder
> > Datenverbindungen zu aktivieren, die fehleranfälliger als bitweises
> > Einlesen sind.
>
> Tja, Du weißt bloß nicht, ob Du Dich darauf verlassen kannst.
> Was nützt Dir eine Variante, auf die Du Dich nicht verlassen willst.
> Auch hier wirst Du ggf. Fehlerabwehr betreiben müssen (zB das Benutzer
> unnütze Dateien ausgewählt haben).
Oh, ich wollte mich ja auf das Einlesen als Test verlassen, wußte aber
nicht, ob Ihr nicht vielleicht doch Risiken kennt oder eine viel
einfachere Methode. Oder sowas wie eine eindeutige Kennzeichnung
innerhalb der Dateien, wie z. B. "Microsoft Forms 2.0 Form" in einer
.frx-Datei, das dort immer ziemlich am Ende und im Klartext zu stehen
scheint. Bis Microsoft sich was anderes einfallen läßt, natürlich.
:-)
> Wenn der Drittanbieter lediglich seine Dateiendung von txt auf csv ändert,
> kann es Dir egal sein.
> Wenn er aber inhaltlich an seinen Dateien grundlegend etwas ändert, wirst
> Du Dein Programm eh daran anpassen müssen.
Hast recht. Das ist auch das erste, worum ich die Leute aus der
Datenbankabteilung bitten werde: Mich benachrichtigen, wenn sie die
ausgeworfene Datenstruktur grundlegend ändern oder die Feldnamen, die
ich zur Erkennung der Datei benutze, sich ändern. In einer
kommaseparierten Datei kann ich mich ja sonst an nichts festhalten...
Puh, schon wieder so ein langes Posting geworden...
War jedenfalls sehr aufschlußreich bisher, vielen Dank!
Grüße
Guido
Reiner Wolff
*Guido Hesterberg* schrieb:
>> Wäre es trotzdem denkbar Update-Dateien an einem Zentralen Ablageort (zB
>> UNC-Pfad) abzulegen und das Update beim Start der Anwendung automatisch und
>> ohne Knopfdruck durchzuführen?
>> Nur so als Hinweis zu "um es für den Benutzer so einfach wie möglich zu
>> machen."
> Wär natürlich einen Lösung, aber ich bin selbst nur einer der
> "Kollegen" ohne Schreibrechte für zentrale Datenbanken usw. Kann aber
> gut sein, daß meine Anwendung später mal auch "offiziell" wird, nur
> vorerst eben nicht.
Ooch, ich arbeite zwar seltener als Anwender (sondern fast immer als Admin
oder als Programmierer) in der Netzwerkstruktur, aber bislang kennt noch
jede mir bekannte Struktur irgendwelche Bereiche, in dem alle Schreiben und
Lesen können. Aber das mag in anderen Netzen natürlich anders organisiert
sein.
Je Größer der Laden, desto starrer die Strukturen. Das ist zwar
admin-arbeitszeitsparend, aber auch nicht immer vorteilhaft.
>> Verstehe ich das richtig? Der Benutzer muss jede Datei (XLS-Update, cls,
>> frm, cls) für ein Update einzeln anwählen?
> Er kann - er kann ja auch mehrere gleichzeitig markieren, die dann
> importiert werden. Aber ich weiß, worauf Du anspielst, wäre mühsam,
> wenn ich 10 Dateien schicke und er jede einzeln anklicken muß.
Yepp.
Da fällt mir gerade ein, eines meiner ersten Excel-Projekte mir derart viel
Codezeilen (ein Amerikanisches Journal) war in Bezug auf Updates Deinem
Projekt gar nicht unähnlich.
Ich hatte den kompletten Code und die Daten in einer Excel-Datei und es gab
ab und zu mal Updates und/oder Erweiterungen.
Vielleicht wäre ja auch der Ansatz etwas für Dich:
Die Update-Funktion ist dort in der jeweils neuesten Version
eingearbeitet. Importiert werden dort nicht die neuen Programmversionen,
sondern die vom Benutzer eingepflegten Daten. An der Stelle muss lediglich
festgestellt werden, wo die Datei mit den Daten gespeichert ist und Deine
Update-Funktion importiert lediglich die Tabellenblätter mit den Daten und
nicht unterschiedliche Dateien, die der Benutzer auswählen muss.
Wo sich die letzte Version der Daten befindet, könntest Du regelmäßig in
die Registry wegschreiben lassen (SaveSetting) und ansonsten durch den
Benutzer auswählen lassen.
> Meine Updates werden sich aber im Rahmen halten, denke ich. Nur mal ein
> Modul oder ein verbessertes Fenster oder so...
Yepp, das denke ich auch immer ;-)
Obiges Programm brachte es so mit einigen Unternummern dann bis zur Version
15.4 im Laufe der Jahre. Andere Projekte stehen seit Jahren immer noch auf
Version 1 :-) Man weiß halt nie, was kommt.
> Du bringst mich aber auf eine Idee... So eine Art Update.xls, die dann
> die anderen Dateien nachlädt, falls es mal mehrere sein sollten.
Wäre praktischer. Wenn Du die Idee verfolgen willst, könnte die Update.xls
auch gleich die notwendigen Komponenten alle enthalten und diese dann
direkt selbst einbinden, ohne weitere Dateien suchen zu müssen.
>>> - Geänderte Gesellschaftsdaten (.xls). Die zu importierende Datei
>>> enhält nur ein Tabellenblatt mit den neuen Daten. Das alte Blatt in
>>> der Anwendung wird gelöscht und durch das neue ersetzt.
>>> Gesellschaftsdaten werden (noch) von mir, später von anderen gepflegt
>>> und verteilt.
>> Ok, sind derzeit kein Problem, oder?
> Doch, schon, deswegen war ich überhaupt darauf gekommen, schon vor dem
> Öffnen in eine Datei zu schnüffeln. Es gibt auf der Festplatte der
> Benutzer .xls-Dateien, die einen kompletten Stillstand meiner Anwendung
> beim "normalen" Öffnen verursachen, weil sie ihrerseits wieder Makros
> und so'n Zeugs in sich haben...
Hm, vielleicht kannst Du Dich ja selbst für Deine Anwendung auf eine andere
Dateiendung festlegen. Dazu müsstest Du allerdings das Öffnen und Speichern
Deiner Pflegedateien selbst organisieren, aber Excel speichert prinzipiell
auch unter frei gewählten Endungen.
> ...Code ist aber nicht offen, so daß ich
> nicht weiß, was genau das verursacht. Ich habe auch keine Lust, alles
> abzufangen, was unsere IT-Abteilung so geschrieben hat. Daher dachte
> ich, der einfachste Weg ist, in dem binär eingelesenen Text nach
> meinen eindeutigen Wörtern zu suchen und überhaupt nur zu öffnen,
> was den Test bestanden hat.
Ist ja auch keine schlechte Idee. Find ich jedenfalls.
>> Prinzipiell würde ich Dir dafür empfehlen, den Code in den Arbeitsdateien
>> einmal generell zu schreiben und von dort aus die Programmsteuerung an eine
>> weitere Datei zu übergeben, die Du dann unabhängig von den Daten
>> aktualisieren kannst.
>> Es macht insbesondere das Update ungleich einfacher, wenn Du einfach eine
>> Datei austauschen kannst und nicht erstmal den Dateityp erkennen musst, um
>> sie dann einzeln zu importieren.
>
> Hm... Eigentlich keine schlechte Idee, aber:
> - Meine Kollegen haben immer nur _eine_ Kundendatei, und es sollen
> nicht noch tausend andere herumschwirren.
Wieso würde mein Vorschlag denn dazu führen? *auf dem Schlauch steh*
> - Bei 23 Modulen und über 5.000 Zeilen Code würde das einiges an
> ausgelagerten Dateien ergeben...
Yepp. Wobei es doch auch ausreichen würde, die Daten (und nicht den Code)
auszugliedern ;-)
> - Da diese Dateien im Ernstfall wahrscheinlich während des Updates
> gerader geöffnet sind, ergibt das bestimmt wieder Konflikte.
Das wäre kein Problem, da Du die Update-Funktion ja eh selbst
schreibst/schreiben musst, so dass Du dementsprechend Deine Programmierung
daran angepaßt hättest.
>> Hast Du schonmal über die Benutzung eines Setup-Programmes nachgedacht?
>> Ich arbeite bei soetwas entweder mit einer AutoUpdate-Routine oder verteile
>> dergleichen mit InnoSetup.
> Die IT-Abteilung tötet mich! :-)
Sind die so brutal? :-)
> Wir dürfen auf unseren Rechnern keinerlei Software installieren, und dann
> taucht auch noch eine undurchsichtige .exe auf, die Dateien
> installiert...
Deine Setups würden keine Admin-Rechte erfordern müssen und .exe führt
jeder Anwender jeden Tag aus (sonst könnte er nämlich kein Programm
starten).
Aber ich weiß, was Du meinst. Dann packst Du das ganze halt nicht in ein
InnoSetup sondern in eine Setup.bat ;-)
Für Deine Fälle würden ja einfache Kopieroperationen ausreichen.
> Aber das wäre natürlich die sauberste Lösung, stimme Dir zu.
Danke.
> Vielleicht kommt das auch mal irgendwann, wenn sich meine Anwendung
> bewährt hat und ich mit der IT-Abteilung zusammenarbeite.
Du arbeitest derzeit nicht mit denen zusammen?
Hoffentlich arbeitest Du nicht gegen sie ;-)
Ok, man kann mit den Leuten aus der IT-Abteilung nicht immer gut
zusammenarbeiten ;-)
Ich muss das wissen, ich arbeite ja auch als solche.
> [Benutzeranpassungsmöglichkeiten gesnippt]
> Dann kann der Benutzer "auf ewig" mit dieser Datei weiterarbeiten und sie
> verbiegen, wie er will (bis auf den Code natürlich). Wenn was Neues von
> mir kommt, kann der Benutzer das einfach in seine vorhandene Datei
> aufsaugen.
Ei, da fällt mir noch ein Gegenargument ein:
Excel-Dateien, die ewig in Benutzung sind und immer wieder geändert werden,
können sich gerne mal "aufblähen" bzw. speichern gelegentlich Daten mit ab,
die längst nicht mehr gebraucht werden.
Wenn Du jeweils die alte Datei aktualisierst, löst Du diese Stilblüte von
Excel nicht. Übernimmst Du lediglich die Daten in eine neue
Programmversion, musst Du "lediglich" (ggf. Excel-Rebuilder) Deine
Originalversion ab und an mal verkleinern.
>> Das klingt nicht nach einem gemeinsamen Netzwerk.
>> Damit kämen wir zu einer Setup-Routine. ;-)
> Doch, ist alles vorhanden, mit professioneller Distribution neuer
> Releases von anderer Software und allem Drum und Dran - aber eben nur
> von der IT-Abteilung.
Achso. Naja, sowas behält sich die IT-Abteilung auch vor. Wenn in den
Bereichen jeder ändert, wird's schnell unübersichtlich. Aber vielleicht
kann man mit denen ja reden und Dir auch einen Bereich bereitstellen?
(Das hängt natürlich sehr vom Verhältnis zu denen und von der Größe des
Unternehmens ab.)
> Und bei diesen Distributionen hat mich schon immer geärgert, daß z.
> B. meine Word-Anpassungen jedesmal überschrieben wurden, wenn eine
> neue Version installiert wurde.
Hast Du dies bei denen auch mal angemerkt?
Manchmal ist es zwar sehr arbeitsaufwendig einzelne Benutzereinstellungen
zu übernehmen, manchmal ist es aber auch nur Gedankenlosigkeit.
>> Sind in Deinen Bezeichnung eigentlich Programmupdate-Dateien und
>> Datenupdate-Dateien beide einfach nur Update-Dateien?
> Ich verstehe die Frage nicht ganz. Wenn ich sie richtig deute: Ja.
Du hast mich richtig verstanden.
>> Wenn der Drittanbieter lediglich seine Dateiendung von txt auf csv ändert,
>> kann es Dir egal sein.
>> Wenn er aber inhaltlich an seinen Dateien grundlegend etwas ändert, wirst
>> Du Dein Programm eh daran anpassen müssen.
> Hast recht. Das ist auch das erste, worum ich die Leute aus der
> Datenbankabteilung bitten werde:
"Datenbankabteilung" *träum*
Ick muss das alles alleine machen ;-)
> Mich benachrichtigen, wenn sie die
> ausgeworfene Datenstruktur grundlegend ändern oder die Feldnamen, die
> ich zur Erkennung der Datei benutze, sich ändern. In einer
> kommaseparierten Datei kann ich mich ja sonst an nichts festhalten...
Stimmt zwar, aber du merkst das ziemlich schnell ;-)
> Puh, schon wieder so ein langes Posting geworden...
Macht ja nichts.
> War jedenfalls sehr aufschlußreich bisher, vielen Dank!
Vielen Dank.
Solange einem die Ideen nicht ausgehen, wird das hier auch weiter gehen ;-)
Gruß aus Kiel
Reiner
--
Wenn am Anfang alles schief geht, nenne es Version 1.0!
Guido Hesterberg
melde mich später noch dazu.