Verweis löschen per VBA
Volker Scherf
folgendes Szenario:
System: A2K-SP3, DevTools, WinXP-SP3
Ich ben�tige f�r Zugriffe auf die COM-Schnittstelle die MSCOMM32.OCX. Der
Verweis wurde im VBA-Editor korrekt gesetzt.
Wenn nun der Verweis fehlerhaft ist, funktionieren merkw�rdigerweise auch
einige Access interne Funktionen in Formularen nicht mehr (Anzahl(),
Summe()).
Daf�r habe ich die Datei auf dem Server abgelegt und darauf hin verwiesen.
Warum auch immer wird der Verweis wieder auf die lokale Datei gelegt.
Wenn ich jetzt die AccessDB auf einem anderen Rechner kopiere und da diese
OCX nicht installiert ist kommt logischerweis ein Fehler. Korrigiere ich den
Verweis manuell auf die Datei auf dem Server funktionert alles wieder
bestens.
Folgendes Problem..
Um die Verweise neu einzubinden w�rde ich jetzt gerne den Verweis per VBA
neu seztzen.
Prinzipiell ist das setzen ja auch kein Problem. Das Problem ist folgendes,
wenn der Verweis defekt ist (IsBroken), dann muss dieser erst gel�scht
werden um auf eine neue Datei zu verweisen (AddFromFile), da hier sonst die
Meldung kommt, dass der Verweis in Konflikt zu einem vorhandenen besteht.
Dazu wiederum muss der Namen des Verweises angegeben werden welcher gel�scht
werden soll. Der Namen des Verweises allerdings kann nicht ausgelesen
werden, da ja der Verweis defekt ist. Ich hab das Gef�hl, dass sich hier die
Katz in den eigenen Schwanz bei�t. Bei Google hab ich zwar gen�gend Hinweise
zu Verweisen und VBA bekommen, jedoch scheitere ich an dem l�schen des
Verweises. Ich hab es mit Application.References... oder auch �ber
VBIDE.Reference... probiert, aber komme leider zu keinem Ergebnis. Gibt es
hier keine Refresh-Funktion mit Angabe des Pfades oder so etwas?
Hier mal der Code:
############
Function TestVerweis()
Dim rsVerweise As ADODB.Recordset
Set rsVerweise = New ADODB.Recordset
Dim I As Integer
For I = 1 To Application.References.Count
If Application.References(I).IsBroken = True Then
rsVerweise.Open "SELECT * FROM tbl_Verweise WHERE (VerweisOrder
= " & I & ")", CurrentProject.Connection, adOpenForwardOnly, adLockReadOnly
Application.References.Remove
Application.References(rsVerweise("VerweisName"))
Application.References.AddFromFile (rsVerweise("VerweisPfad"))
rsVerweise.Close
End If
Next I
Set rsVerweise = Nothing
End Function
############
Beim L�schen des Verweises bekomme ich immer die Fehlermeldung "Typen
unvertr�glich!"
Hab�s auch schon �ber die Auflistung, Beschreibung versucht, jedoch immer
die selbe Sch....
Evtl. hat ja jemand von euch einen L�sungsansatz.
Die n�chste Frage w�re noch: Funktioniert das ganze auch in einer ADE/MDE,
oder m�sste ich mal komplett umdenken?
Hab in diesem Zusammenhang von LateBinding gelesen. Aber wie stelle ich da
bei o.g. Problem die Verbindung zu einer DLL, OCX,.. her? Das muss ich ja
auch irgendwie angeben.
Oh mann, ich hab doch keine Ahnung...
Viele Gr��e,
Volker Scherf
Gunter Avenius
Volker Scherf schrieb folgendes:
> folgendes Szenario:
> System: A2K-SP3, DevTools, WinXP-SP3
>
> Ich ben�tige f�r Zugriffe auf die COM-Schnittstelle die MSCOMM32.OCX. Der
> Verweis wurde im VBA-Editor korrekt gesetzt.
> Wenn nun der Verweis fehlerhaft ist, funktionieren merkw�rdigerweise auch
> einige Access interne Funktionen in Formularen nicht mehr (Anzahl(),
> Summe()).
...
http://team-moeller.de/access/tiptrick/vbide/verweisloeschen.html geht
darauf ein.
Gru�
Gunter
--
__________________________________________________________
Access FAQ: http://www.donkarl.com
home: http://www.avenius.com - http://www.AccessRibbon.de
http://www.ribboncreator.de
3. SQL Server-Entwickler-Konferenz - N�rnberg im Mai
http://www.donkarl.com/?SEK
Doerthe Weber
Volker Scherf schrieb:
> Folgendes Problem..
> Um die Verweise neu einzubinden wï¿œrde ich jetzt gerne den Verweis per VBA
> neu seztzen.
> Prinzipiell ist das setzen ja auch kein Problem. Das Problem ist folgendes,
> wenn der Verweis defekt ist (IsBroken), dann muss dieser erst gelï¿œscht
> werden um auf eine neue Datei zu verweisen (AddFromFile), da hier sonst die
> Meldung kommt, dass der Verweis in Konflikt zu einem vorhandenen besteht.
> Dazu wiederum muss der Namen des Verweises angegeben werden welcher gelï¿œscht
> werden soll. Der Namen des Verweises allerdings kann nicht ausgelesen
> werden, da ja der Verweis defekt ist. Ich hab das Gefï¿œhl, dass sich hier die
> Katz in den eigenen Schwanz beiï¿œt. Bei Google hab ich zwar genï¿œgend Hinweise
> zu Verweisen und VBA bekommen, jedoch scheitere ich an dem lï¿œschen des
> Verweises. Ich hab es mit Application.References... oder auch ï¿œber
> VBIDE.Reference... probiert, aber komme leider zu keinem Ergebnis. Gibt es
> hier keine Refresh-Funktion mit Angabe des Pfades oder so etwas?
>
Den Namen des Verweises brauchst du nicht zum Lï¿œschen.
Dim ref As Reference
For Each ref In References
If ref.IsBroken Then
References.Remove ref
End If
Next
Gruￜ
Doerthe
Doerthe Weber
Volker Scherf schrieb:
> Folgendes Problem..
> Um die Verweise neu einzubinden wï¿œrde ich jetzt gerne den Verweis per VBA
> neu seztzen.
> Prinzipiell ist das setzen ja auch kein Problem. Das Problem ist folgendes,
> wenn der Verweis defekt ist (IsBroken), dann muss dieser erst gelï¿œscht
> werden um auf eine neue Datei zu verweisen (AddFromFile), da hier sonst die
> Meldung kommt, dass der Verweis in Konflikt zu einem vorhandenen besteht.
> Dazu wiederum muss der Namen des Verweises angegeben werden welcher gelï¿œscht
> werden soll. Der Namen des Verweises allerdings kann nicht ausgelesen
> werden, da ja der Verweis defekt ist. Ich hab das Gefï¿œhl, dass sich hier die
> Katz in den eigenen Schwanz beiï¿œt. Bei Google hab ich zwar genï¿œgend Hinweise
> zu Verweisen und VBA bekommen, jedoch scheitere ich an dem lï¿œschen des
> Verweises. Ich hab es mit Application.References... oder auch ï¿œber
> VBIDE.Reference... probiert, aber komme leider zu keinem Ergebnis. Gibt es
> hier keine Refresh-Funktion mit Angabe des Pfades oder so etwas?
>
Den Pfadnamen brauchst du nicht zum Lï¿œschen:
Jens Schilling
Volker Scherf wrote:
> Die n�chste Frage w�re noch: Funktioniert das ganze auch in einer
> ADE/MDE, oder m�sste ich mal komplett umdenken?
> Hab in diesem Zusammenhang von LateBinding gelesen. Aber wie stelle
> ich da bei o.g. Problem die Verbindung zu einer DLL, OCX,.. her? Das
> muss ich ja auch irgendwie angeben.
Hinweise zur L�sung Deines Problemes haben Doerthe und Gunter Dir bereits
gegeben, auf Deine anderen Fragen ( und viel mehr ) geht der Vortrag
"Verweise" von Thomas ein, den Du im Downloadbereich zur 10. AEK finden
kannst :
http://www.donkarl.com/AEK/AEK_Downloads.htm
Gruss
Jens
Sascha Trowitzsch
"Volker Scherf" <vsc...@online.de> schrieb im Newsbeitrag
news:gt6781$jld$1...@online.de...
> ... Die n�chste Frage w�re noch: Funktioniert das ganze auch in einer ADE/MDE,
> oder m�sste ich mal komplett umdenken?
> Hab in diesem Zusammenhang von LateBinding gelesen. Aber wie stelle ich da bei
> o.g. Problem die Verbindung zu einer DLL, OCX,.. her? Das muss ich ja auch
> irgendwie angeben.
Dim objCOMM As Object
Set objCOMM = CreateObject("MSCOMMLib.MSCOMM.1")
Damit kannst du 1. �berpr�fen, ob das OCX installiert bzw. registriert ist, und
2. auch direkt programmieren.
Allerdings kommt hier der Nachteil von late bindig ins Spiel, dass die
objCOMM-Variable keine Ereignisse ausl�st, was ausgerechnet bei diesem Control
den Code etwas umst�ndlich macht. Du m�sstest dann eine Zeitschleife
programmieren, die dauernd abfragt, ob was in den seriellen Puffer rein kam -
...falls du nicht zuf�llig nur senden willst.
Theroretisch gibt es von Josef auch eine L�sung, die Events auch bei late
binding generieren kann, die erfodert aber auch zus�tzliche DLLs, was bei euch
ja anscheinend nicht erw�nscht ist.
Ciao, Sascha
Volker Scherf
"Sascha Trowitzsch" schrieb im Newsbeitrag
news:umAS3R$xJHA...@TK2MSFTNGP04.phx.gbl...
>
> Dim objCOMM As Object
> Set objCOMM = CreateObject("MSCOMMLib.MSCOMM.1")
>
> Damit kannst du 1. �berpr�fen, ob das OCX installiert bzw. registriert
> ist, und
Und genau hier liegt der Hund begraben. Das OCX ist nicht auf dem Rechner
Installiert und damit auch nicht registriert.
> 2. auch direkt programmieren.
> Allerdings kommt hier der Nachteil von late bindig ins Spiel, dass die
> objCOMM-Variable keine Ereignisse ausl�st, was ausgerechnet bei diesem
> Control den Code etwas umst�ndlich macht. Du m�sstest dann eine
> Zeitschleife programmieren, die dauernd abfragt, ob was in den seriellen
> Puffer rein kam - ...falls du nicht zuf�llig nur senden willst.
Das klingt mir irgendwie zu kompliziert. Ich denke da werde ich die H�nde
von lassen..
Zumal ich als fauler Programmierer die Vorteile von EarlyBinding mehr
sch�tze als die Nachteile von LateBinding.
;)
>
> Theroretisch gibt es von Josef auch eine L�sung, die Events auch bei late
> binding generieren kann, die erfodert aber auch zus�tzliche DLLs, was bei
> euch ja anscheinend nicht erw�nscht ist.
Ooch, das hat mit erw�nscht nix zu tun. Es ist halt so.
Aber die DLL m�sste ja dann auch irgendwie angesprochen werden, was mich
dann unweigerlich wieder zum Ursprungsproblem bringt.
Trotzdem vielen Dank f�r deine Hilfe.
Viele Gr��e,
Volker
OT: Ich glaube jetzt regnet es gleich. Sch... Pollen, mein ganzer
Schreibtisch ist gelb!
Volker Scherf
danke f�r deine Antwort.
"Doerthe Weber" schrieb im Newsbeitrag
news:%23oxHH38...@TK2MSFTNGP06.phx.gbl...
> Hallo Volker,
>
> Volker Scherf schrieb:
>
>> Folgendes Problem..
>> Um die Verweise neu einzubinden w�rde ich jetzt gerne den Verweis per VBA
>> neu seztzen.
>> Prinzipiell ist das setzen ja auch kein Problem. Das Problem ist
>> folgendes, wenn der Verweis defekt ist (IsBroken), dann muss dieser erst
>> gel�scht werden um auf eine neue Datei zu verweisen (AddFromFile), da
>> hier sonst die Meldung kommt, dass der Verweis in Konflikt zu einem
>> vorhandenen besteht. Dazu wiederum muss der Namen des Verweises angegeben
>> werden welcher gel�scht werden soll. Der Namen des Verweises allerdings
>> kann nicht ausgelesen werden, da ja der Verweis defekt ist. Ich hab das
>> Gef�hl, dass sich hier die Katz in den eigenen Schwanz bei�t. Bei Google
>> hab ich zwar gen�gend Hinweise zu Verweisen und VBA bekommen, jedoch
>> scheitere ich an dem l�schen des Verweises. Ich hab es mit
>> Application.References... oder auch �ber VBIDE.Reference... probiert,
>> aber komme leider zu keinem Ergebnis. Gibt es hier keine Refresh-Funktion
>> mit Angabe des Pfades oder so etwas?
>>
>
> Den Pfadnamen brauchst du nicht zum L�schen:
>
> Dim ref As Reference
>
> For Each ref In References
> If ref.IsBroken Then
> References.Remove ref
> End If
> Next
>
Bei 'References.Remove ref' kommt die Meldung "Objektbibliothek nicht
registriert"
Will ich den Verweis einf�gen, dann erhalte ich "Name steht in Konflikt mit
vorhandenem Modul, Projekt oder vorhandener Objektbibliothek"
Ich werd noch wahnsinnig.
Ich bekomm den schei� fehlerhaften Verweis einfach net weg!
<heul>
Das einzig brauchbare was ich noch auslesen kann, ist die 'References.GUID',
d.h. ich k�nnte ja, selbst wenn ich wollte, nicht einmal einen Hinweis
ausgeben, welcher Verweis fehlerhaft ist!
Ich w�rde mal sagen das das Problem mit dem fehlenden OCX nicht sooo
unbedingt brisant ist, da die Routine , die auf das OCX zugreift nur auf 1-2
Rechnern aufgerufen wird. Und da k�nnte ich das OCX manuell installieren.
Was mich halt stutzig macht, ist das, dass einige rudiment�re
Accessfunktionen nicht mehr arbeiten wenn ein Verweis fehlerhaft ist, So
z.B.Left(), Anzahl(), Summe(), o.�.
Die haben doch nun wirklich nix mit mscomm32.ocx zu tun. L�sche ich den
Verweis manuell funktioniert wieder alles einwandfrei.
Viele Gr��e und danke f�r die Hilfe,
Volker
Volker Scherf
"Volker Scherf" schrieb im Newsbeitrag news:gt6781$jld$1...@online.de...
> Hallo NG,
> folgendes Szenario:
> System: A2K-SP3, DevTools, WinXP-SP3
>
>
> Folgendes Problem..
> Um die Verweise neu einzubinden w�rde ich jetzt gerne den Verweis per VBA
> neu seztzen.
> Prinzipiell ist das setzen ja auch kein Problem. Das Problem ist
> folgendes, wenn der Verweis defekt ist (IsBroken), dann muss dieser erst
> gel�scht werden um auf eine neue Datei zu verweisen (AddFromFile), da hier
> sonst die Meldung kommt, dass der Verweis in Konflikt zu einem vorhandenen
> besteht. Dazu wiederum muss der Namen des Verweises angegeben werden
> welcher gel�scht werden soll. Der Namen des Verweises allerdings kann
> nicht ausgelesen werden, da ja der Verweis defekt ist. Ich hab das Gef�hl,
> dass sich hier die Katz in den eigenen Schwanz bei�t. Bei Google hab ich
> zwar gen�gend Hinweise zu Verweisen und VBA bekommen, jedoch scheitere ich
> an dem l�schen des Verweises. Ich hab es mit Application.References...
> oder auch �ber VBIDE.Reference... probiert, aber komme leider zu keinem
> Ergebnis. Gibt es hier keine Refresh-Funktion mit Angabe des Pfades oder
> so etwas?
>
> Beim L�schen des Verweises bekomme ich immer die Fehlermeldung "Typen
> unvertr�glich!"
> Hab�s auch schon �ber die Auflistung, Beschreibung versucht, jedoch immer
> die selbe Sch....
> Evtl. hat ja jemand von euch einen L�sungsansatz.
>
> Die n�chste Frage w�re noch: Funktioniert das ganze auch in einer ADE/MDE,
> oder m�sste ich mal komplett umdenken?
> Hab in diesem Zusammenhang von LateBinding gelesen. Aber wie stelle ich da
> bei o.g. Problem die Verbindung zu einer DLL, OCX,.. her? Das muss ich ja
> auch irgendwie angeben.
> Oh mann, ich hab doch keine Ahnung...
>
>
Also ich hab mir jetzt mal mit Thomas M�llers Hilfe (
http://team-moeller.de/access/tiptrick/vbide/verweisloeschen.html )folgendes
zusammengebastelt:
'#####
Public Function VerweisTesten() As Boolean
On Error GoTo ErrHandle
Dim ref As VBIDE.Reference
Dim rsVerweise As ADODB.Recordset
Set rsVerweise = New ADODB.Recordset
Dim strMeldung As String
Dim I As Integer
'Initialisieren
VerweisTesten = False
For Each ref In Application.VBE.ActiveVBProject.References
I = I + 1
rsVerweise.Open "SELECT * FROM tbl_Verweise WHERE (VerweisOrder = "
& I & ")", CurrentProject.Connection, adOpenForwardOnly, adLockReadOnly
If ref.Name = rsVerweise("VerweisName") Then
'irgendwas
End If
rsVerweise.Close
Next
If Not strMeldung = "" Then MsgBox strMeldung
ExitHere:
Set rsVerweise = Nothing
Exit Function
ErrHandle:
Select Case Err.Number
Case 35021
strMeldung = strMeldung & "Verweis zu '" &
rsVerweise("VerweisBeschreibung") & "' fehlerhaft!" & vbCrLf
Resume Next 'damit alle Verweise gepr�ft werden
Case Else
'irgendwas
End Select
GoTo ExitHere
End Function
'#####
Die Verweisinfos hole ich mir aus einer Tabelle und vergleiche diese mit dem
R�ckgabewert von 'ref.Name'
So wei� ich wenigstens welcher Verweis fehlerhaft ist und kann den
wenigstens von Hand einbinden.
Wenn nat�rlich der verweis auf die VBIDE fehlt isses eh f�r die Katz, aber
da kann ich ja noch auf das 'Application'-Modell ausweichen.
Das ist zwar schon etwas umst�ndlich, aber ich wei� echt nicht wie ich sonst
den fehlerhaften Verweis beseitige.
Ihr habt doch sicherlich bessere und elegandere Ideen.
:-/
Viele Gr��e,
Volker
Doerthe Weber
>> Dim ref As Reference
>>
>> For Each ref In References
>> If ref.IsBroken Then
>> References.Remove ref
>> End If
>> Next
>>
>
> Bei 'References.Remove ref' kommt die Meldung "Objektbibliothek nicht
> registriert"
> Will ich den Verweis einfï¿œgen, dann erhalte ich "Name steht in Konflikt mit
> vorhandenem Modul, Projekt oder vorhandener Objektbibliothek"
>
> Ich werd noch wahnsinnig.
> Ich bekomm den scheiￜ fehlerhaften Verweis einfach net weg!
> <heul>
>
> Das einzig brauchbare was ich noch auslesen kann, ist die 'References.GUID',
> d.h. ich kï¿œnnte ja, selbst wenn ich wollte, nicht einmal einen Hinweis
> ausgeben, welcher Verweis fehlerhaft ist!
>
> Ich wï¿œrde mal sagen das das Problem mit dem fehlenden OCX nicht sooo
> unbedingt brisant ist, da die Routine , die auf das OCX zugreift nur auf 1-2
> Rechnern aufgerufen wird. Und da kï¿œnnte ich das OCX manuell installieren.
> Was mich halt stutzig macht, ist das, dass einige rudimentï¿œre
> Accessfunktionen nicht mehr arbeiten wenn ein Verweis fehlerhaft ist, So
> z.B.Left(), Anzahl(), Summe(), o.ￜ.
> Die haben doch nun wirklich nix mit mscomm32.ocx zu tun. Lï¿œsche ich den
> Verweis manuell funktioniert wieder alles einwandfrei.
>
Nein, haben sie nicht, aber das ist das ï¿œbliche Auftreten des Problems...
Bis du sicher, dass du dir nicht die mdb zerschossen hast? Normalerweise
bekomme ich mit folgender Funktion eine Auflistung aller Verweise, auch
wenn einer fehlerhaft ist:
Public Function VerweisListe() As String
Dim ref As Reference
Dim sMsg As String
For Each ref In References
sMsg = sMsg & ref.name & vbCrLf
sMsg = sMsg & ref.FullPath & vbCrLf & ref.Guid
sMsg = sMsg & "@Version " & ref.Major & "." & ref.Minor & vbCrLf
sMsg = sMsg & IIf(ref.BuiltIn, "[x]", "[ ]") & " BuiltIn "
sMsg = sMsg & IIf(ref.IsBroken, "[x]", "[ ]") & " IsBroken" &
vbCrLf & vbCrLf
Next
VerweisListe = sMsg
End Function
Welche Verweise hast du denn insgesamt drin?
Gruￜ
Doerthe
Thomas Möller
Volker Scherf schrieb:
>> Dim objCOMM As Object
>> Set objCOMM = CreateObject("MSCOMMLib.MSCOMM.1")
>>
>> Damit kannst du 1. �berpr�fen, ob das OCX installiert bzw. registriert
>> ist, und
>> 2. auch direkt programmieren.
>
> Und genau hier liegt der Hund begraben. Das OCX ist nicht auf dem Rechner
> Installiert und damit auch nicht registriert.
Du hast selber festgestellt, dass Access bzw. VBA seine eigenen
Funktionen nicht mehr findet, wenn *ein* Verweis defekt ist. Dann
funktioniert auf einmal Deine gesamte Anwendung nicht mehr (richtig).
Hier setzt Saschas Vorschlag an. Du setzt keinen Verweis. Statt dessen
verwendest Du Lade Binding. Vorteil f�r Dich: Es gibt auf keinem Rechner
ein Problem mit den Verweisen, da es keinen Verweis (auf die MSCOMMLib)
gibt, der defekt sein k�nnte. Grunds�tzlich l�uft Deine Anwendung also
auf jedem Rechner. Dabei ist es egal, ob das OCX installiert ist oder nicht.
Zum Problem kann es nur auf den Rechnern kommen, an denen Deine Routine,
die die MSCOMMLib ben�tigt, aufgerufen wird. Wenn Du mit CreateObject
eine Objekt der MSCOMMLib auf einem Rechner, auf dem die MSCOMMLib nicht
installiert ist, erstellen willst, erh�ltst Du eine abfangbare
Fehlermeldung (429). Auf diese kannst Du reagieren. Du kannst den
Benutzer z.B. anweisen, Dich zu informieren, damit das OCX auf diesem
Rechner installiert werden kann.
CU
--
Thomas
Homepage: www.Team-Moeller.de
Thomas Möller
Volker Scherf schrieb:
> Wenn nat�rlich der verweis auf die VBIDE fehlt isses eh f�r die Katz, aber
> da kann ich ja noch auf das 'Application'-Modell ausweichen.
das kannst / solltest Du eh tun. Die beiden Bibliotheken bieten fast die
selben M�glichkeiten, was die Verweise angeht. Der Vorteil bei der
Verwendung des Application-Objekts ist, dass die Access-Bibliothek ein
eingebauter Verweis ist. Der kann nicht fehlen. Dann w�rde Access
n�mlich nicht funktionieren. ;-)
> Das ist zwar schon etwas umst�ndlich, aber ich wei� echt nicht wie ich sonst
> den fehlerhaften Verweis beseitige.
> Ihr habt doch sicherlich bessere und elegandere Ideen.
Schau Dir mal diesen Artikel n�her an:
http://support.microsoft.com/kb/194374/en-us
(Link in einer Zeile)
HTH
--
Thomas
Homepage: www.Team-Moeller.de
Volker Scherf
"Thomas M�ller" schrieb
> Volker Scherf schrieb:
>>> Dim objCOMM As Object
>>> Set objCOMM = CreateObject("MSCOMMLib.MSCOMM.1")
>>>
>>> Damit kannst du 1. �berpr�fen, ob das OCX installiert bzw. registriert
>>> ist, und
>>> 2. auch direkt programmieren.
>>
>> Und genau hier liegt der Hund begraben. Das OCX ist nicht auf dem Rechner
>> Installiert und damit auch nicht registriert.
>
> Du hast selber festgestellt, dass Access bzw. VBA seine eigenen Funktionen
> nicht mehr findet, wenn *ein* Verweis defekt ist. Dann funktioniert auf
> einmal Deine gesamte Anwendung nicht mehr (richtig).
>
> Hier setzt Saschas Vorschlag an. Du setzt keinen Verweis. Statt dessen
> verwendest Du Lade Binding. Vorteil f�r Dich: Es gibt auf keinem Rechner
> ein Problem mit den Verweisen, da es keinen Verweis (auf die MSCOMMLib)
> gibt, der defekt sein k�nnte. Grunds�tzlich l�uft Deine Anwendung also auf
> jedem Rechner. Dabei ist es egal, ob das OCX installiert ist oder nicht.
>
Da werde ich wohl oder �bel doch nicht drum herum kommen.
Oh Gott, damit hatte ich bisher noch gar nix am Hut.
Schau ma mal.
Zumal ich einer MDE die Verweise eh nicht neu setzen kann.
Sch�ne Sch...
Vielen Dank f�r eure Hilfe!
Volker
Volker Scherf
"Doerthe Weber" schrieb im Newsbeitrag
news:Owp9NqAy...@TK2MSFTNGP02.phx.gbl...
>>> Dim ref As Reference
>>>
>>> For Each ref In References
>>> If ref.IsBroken Then
>>> References.Remove ref
>>> End If
>>> Next
>>>
>>
>> Bei 'References.Remove ref' kommt die Meldung "Objektbibliothek nicht
>> registriert"
>> Will ich den Verweis einf�gen, dann erhalte ich "Name steht in Konflikt
>> mit vorhandenem Modul, Projekt oder vorhandener Objektbibliothek"
>>
>> Ich werd noch wahnsinnig.
>> Ich bekomm den schei� fehlerhaften Verweis einfach net weg!
>> <heul>
>>
>> Das einzig brauchbare was ich noch auslesen kann, ist die
>> 'References.GUID', d.h. ich k�nnte ja, selbst wenn ich wollte, nicht
>> einmal einen Hinweis ausgeben, welcher Verweis fehlerhaft ist!
>>
>> Ich w�rde mal sagen das das Problem mit dem fehlenden OCX nicht sooo
>> unbedingt brisant ist, da die Routine , die auf das OCX zugreift nur auf
>> 1-2 Rechnern aufgerufen wird. Und da k�nnte ich das OCX manuell
>> installieren. Was mich halt stutzig macht, ist das, dass einige
>> rudiment�re Accessfunktionen nicht mehr arbeiten wenn ein Verweis
>> fehlerhaft ist, So z.B.Left(), Anzahl(), Summe(), o.�.
>> Die haben doch nun wirklich nix mit mscomm32.ocx zu tun. L�sche ich den
>> Verweis manuell funktioniert wieder alles einwandfrei.
>>
> Nein, haben sie nicht, aber das ist das �bliche Auftreten des Problems...
> Bis du sicher, dass du dir nicht die mdb zerschossen hast? Normalerweise
> bekomme ich mit folgender Funktion eine Auflistung aller Verweise, auch
> wenn einer fehlerhaft ist:
>
> Public Function VerweisListe() As String
> Dim ref As Reference
> Dim sMsg As String
>
> For Each ref In References
> sMsg = sMsg & ref.name & vbCrLf
> sMsg = sMsg & ref.FullPath & vbCrLf & ref.Guid
> sMsg = sMsg & "@Version " & ref.Major & "." & ref.Minor & vbCrLf
> sMsg = sMsg & IIf(ref.BuiltIn, "[x]", "[ ]") & " BuiltIn "
> sMsg = sMsg & IIf(ref.IsBroken, "[x]", "[ ]") & " IsBroken" &
> vbCrLf & vbCrLf
> Next
> VerweisListe = sMsg
> End Function
Also ich hab die DB mal mit /decompile gestartet, der Effekt ist der
gleiche.
Fehler: Die Methode 'Name' f�r das Objekt 'Reference' ist fehlgeschlagen.
Ich bekomme den Namen oder sonstiges nicht aufgel�st.
Ich werde es dann doch evtl. �ber LateBinding machen, oder beim Start die
Verweise checken und einen entpsrechenden Hinweis ausgeben.
Wie bereits in einer anderen mail geschrieben, bringt das Neueinbinden in
einer ADE/MDE sowieso nix.
> Welche Verweise hast du denn insgesamt drin?
>
Diese:
VBA - Visual Basic For Applications
Access - Microsoft Access 9.0 Object Library
DAO - Microsoft DAO 3.6 Object Library
ADODB - Microsoft ActiveX Data Objects 2.1 Library
stdole - OLE Automation
Scripting - Microsoft Scripting Runtime
Outlook - Microsoft Outlook 9.0 Object Library
Excel - Microsoft Excel 9.0 Object Library
MSForms - Microsoft Forms 2.0 Object Library
VBIDE - Microsoft Visual Basic for Applications Extensibility 5.3
Danke f�r deine Hilfe.
Viele Gr��e,
Volker
Thomas Möller
Volker Scherf schrieb:
>> Welche Verweise hast du denn insgesamt drin?
>
> Diese:
>
> VBA - Visual Basic For Applications
> Access - Microsoft Access 9.0 Object Library
> DAO - Microsoft DAO 3.6 Object Library
> ADODB - Microsoft ActiveX Data Objects 2.1 Library
> stdole - OLE Automation
> Scripting - Microsoft Scripting Runtime
> Outlook - Microsoft Outlook 9.0 Object Library
> Excel - Microsoft Excel 9.0 Object Library
> MSForms - Microsoft Forms 2.0 Object Library
> VBIDE - Microsoft Visual Basic for Applications Extensibility 5.3
das sind doch einige Verweise. Bist Du sicher, dass Du alle wirklich
brauchst? Mein Vorschlag: Du deaktivierst einen verweis. Dann
kompilierst Du den Code. Wenn es einen Fehler gibt aktivierst Du den
Verweis wieder; ansonsten war er �berfl�ssig. So gehst Du alle Verweise
ab DAO durch.
Bei "stdole" habe ich z.B. die Hoffnung, dass dieser Verweis �berfl�ssig
ist. Dieser Verweis wurde bei einer �lteren Version von Access
automatisch gesetzt, wird aber nur selten ben�tigt.
Auch die Verwendung von ADO und DAO ist IMHO zu hinterfragen. Greifst Du
tats�chlich mit beiden Bibliotheken auf Deine Daten zu?
Der Verweis auf die VBIDE sollte auch entbehrlich sein, wenn Du nichts
mit dem VBA-Code anstellst. Bezgl. der Verweise k�nntest Du die Methoden
des Application-Objekts verwenden.
Volker Scherf
danke, f�r deine Hilfe.
"Thomas M�ller" schrieb im Newsbeitrag
news:75rbsvF...@mid.individual.net...
Also:
- stdole wird f�r GDI+ Aufrufe ben�tigt.
Da sind irgendwelche Typendeklarationen drin (IUnknown, etc.).
Da m�sste man mal Sascha Trowitzsch fragen, vielleicht liest er ja mit.
Auf die Funktion hat er mich vor einiger Zeit mal hingewiesen.
Ehrlich gesagt hab ich vor irgendwelchen API-Zeugs ziemlichen Respekt
und will da aus Gr�nden der Unkenntnis net unn�tig dran herumpfuschen,
wobei es bestimmt kein Hexenwerk ist.
- Scripting brauch ich f�r Dateigr��enermittlungen
- VBIDE f�r Registryzugriffe
- MSForms....��hhmm, das wei� ich ehrlich gesagt nicht,
weil ich es nicht deaktivieren kann, da die Meldung kommt,
dass es derzeit in Verwendung ist und daher nicht deaktiviert werden kann.
Muss ich mal schaun.
- ADO und DAO deshalb zeitgleich weil ich von ADP nach MDB umstelle.
Was spr�che aber prinzipiell gegen eine Symbiose beider Bibliotheken,
jetzt mal von Verweisproblemen abgesehen. ;)
- auf Outlook kann ich mittlerweile verzichten, da wir auf das
"wundersch�ne"
LotusNotes umgestellt haben und das ist mir LateBinding eingebunden
(allerdings net von mir)
Das brauch ich eigentlich nur, um irgendwelche Anh�nge zu versenden,
ansonsten w�rde 'DoCmd.SendObject' v�llig gen�gen.
- Excel nehm ich zum Export f�r formatierte Excellisten
und zur Diagrammerstellung
- Outlook und Excel sind aus Gr�nden der Bequemlichkeit drin,
da IntelliSense und automatische Syntaxpr�fung f�r einen Depp wie mich
doch ganz hilfreich sind.
- MSCOMM hab ich rausgeschmissen und stattdessen
ein ActivX-Control eingebunden.
Da hab ich mal den Teufel mit dem Beelzebub ausgtrieben! ;)
Viele Gr��e,
Volker
Sascha Trowitzsch
"Volker Scherf" <vsc...@online.de> schrieb im Newsbeitrag
news:gtbfjq$anh$1...@online.de...
stdole ist auch niemals ein Problem.
Ich habe vor kurzem versucht, das Gdiplus-Modul so umzuschreiben, dass man ohne
StdPicture und ohne IUnknown hinkommt, also den Verweis auf OLE Automation
wegassen k�nnte.
Das ist mir nicht wirklich gelungen. Es gibt zuviele Macken, wenn man nur ein
Object statt eines StdPictures zur�ckgibt und das f�r die Array-Funktionen
(Streams) notwendig Interface IUnknown ist einfach nicht zu ersetzen.
> - Scripting brauch ich f�r Dateigr��enermittlungen
Na gut, aber gerade das l�sst sich auch per Late binding verwenden
(CreateObject("Scripting.FileSystemObject"))
> - VBIDE f�r Registryzugriffe
??
Wie das? Da gibt's keine Methoden drin, die Registry-Zugriffe unterst�tzen
w�rden.
> - MSForms....��hhmm, das wei� ich ehrlich gesagt nicht,
> weil ich es nicht deaktivieren kann, da die Meldung kommt,
> dass es derzeit in Verwendung ist und daher nicht deaktiviert werden kann.
MSForms ist eine bl�de Angelegenheit, weil man's schlecht deaktivieren kann,
wenn's mal drin ist.
Grund: Der VBA-Editor verwendet die Bibliothek selbst. Er l�dt die DLL also von
sich aus. Den Verweis zu entfernen w�rde bedeuten, die DLL zu entladen. Das geht
aber eben nicht, wenn die DLL im Einsatz ist, also ihr Referenzz�hler noch vom
VBA-Editor �ber 1 gehalten wird.
Allerdings sollte es per Code klappen, solange man den VBA-Editor noch nicht
ge�ffnet hatte, denn erst dann wird die fm20.dll geladen.
Abgesehen davon st�rt die Bibliothek auch nie.
> - Outlook und Excel sind aus Gr�nden der Bequemlichkeit drin,
> da IntelliSense und automatische Syntaxpr�fung f�r einen Depp wie mich
> doch ganz hilfreich sind.
Excel ist ein klarer Kandidat f�r Late binding.
Und Outlook erst recht, weil sich dessen Objektmodell von Version zu Version
immer erheblich ge�ndert hat. Mit einem Verweis auf OL2003 kriegt man unter
OL2007 z.B. ziemlich Stress.
Es gibt keinen Grund, warum man einen Verweis drauf setzen m�sste, au�er den,
dass es die Programmierarbet erleichert.
Und maximal noch den, dass man die Objekte WithEvents deklarieren k�nnte, um
Ereignisse abzufangen. Aber wer macht sowas denn schon?
> - MSCOMM hab ich rausgeschmissen und stattdessen
> ein ActivX-Control eingebunden.
> Da hab ich mal den Teufel mit dem Beelzebub ausgtrieben! ;)
Allerdings. Hier hat sich in punto Verweise nichts zum Besseren ver�ndert.
Jetzt ist halt ein anderer neuer VErweis drin. ;-)
Ciao, Sasca
Volker Scherf
danke f�r deine Hilfe.
"Sascha Trowitzsch" schrieb im Newsbeitrag
news:OjAYTUXy...@TK2MSFTNGP02.phx.gbl...
> Hi,
>
> "Volker Scherf" schrieb
>> Also:
>> - stdole wird f�r GDI+ Aufrufe ben�tigt.
>> Da sind irgendwelche Typendeklarationen drin (IUnknown, etc.).
>> Da m�sste man mal Sascha Trowitzsch fragen, vielleicht liest er ja mit.
>> Auf die Funktion hat er mich vor einiger Zeit mal hingewiesen.
>> Ehrlich gesagt hab ich vor irgendwelchen API-Zeugs ziemlichen Respekt
>> und will da aus Gr�nden der Unkenntnis net unn�tig dran herumpfuschen,
>> wobei es bestimmt kein Hexenwerk ist.
>
> stdole ist auch niemals ein Problem.
> Ich habe vor kurzem versucht, das Gdiplus-Modul so umzuschreiben, dass man
> ohne StdPicture und ohne IUnknown hinkommt, also den Verweis auf OLE
> Automation wegassen k�nnte.
> Das ist mir nicht wirklich gelungen. Es gibt zuviele Macken, wenn man nur
> ein Object statt eines StdPictures zur�ckgibt und das f�r die
> Array-Funktionen (Streams) notwendig Interface IUnknown ist einfach nicht
> zu ersetzen.
Was bedeutet, dass ich stdole drin lassen kann?
Also ich muss sagen das das GDIPlus-Modul hervorragend funktioniert.
DANKE!!
>
>> - Scripting brauch ich f�r Dateigr��enermittlungen
>
> Na gut, aber gerade das l�sst sich auch per Late binding verwenden
> (CreateObject("Scripting.FileSystemObject"))
Ok, werd ich machen.
>
>> - VBIDE f�r Registryzugriffe
>
> ??
> Wie das? Da gibt's keine Methoden drin, die Registry-Zugriffe unterst�tzen
> w�rden.
Ha, das war mein Fehler. Da hatt ich in einer Routine noch einen Aufruf
'VBIDE.Reference' drin.
Ok, der ist auch weg.
>
>> - MSForms....��hhmm, das wei� ich ehrlich gesagt nicht,
>> weil ich es nicht deaktivieren kann, da die Meldung kommt,
>> dass es derzeit in Verwendung ist und daher nicht deaktiviert werden
>> kann.
>
> MSForms ist eine bl�de Angelegenheit, weil man's schlecht deaktivieren
> kann, wenn's mal drin ist.
> Grund: Der VBA-Editor verwendet die Bibliothek selbst. Er l�dt die DLL
> also von sich aus. Den Verweis zu entfernen w�rde bedeuten, die DLL zu
> entladen. Das geht aber eben nicht, wenn die DLL im Einsatz ist, also ihr
> Referenzz�hler noch vom VBA-Editor �ber 1 gehalten wird.
> Allerdings sollte es per Code klappen, solange man den VBA-Editor noch
> nicht ge�ffnet hatte, denn erst dann wird die fm20.dll geladen.
> Abgesehen davon st�rt die Bibliothek auch nie.
OK, die hab ich auch mal rausgehauen.
Die wird ben�tig, wenn ich etwas in die Zwischenablage kopiere:
Karl ( http://www.donkarl.com/FAQ/FAQ6VBA.htm#6.15 ) und MS sei dank, konnte
ich auch dieses Problem l�sen.
>
>> - Outlook und Excel sind aus Gr�nden der Bequemlichkeit drin,
>> da IntelliSense und automatische Syntaxpr�fung f�r einen Depp wie mich
>> doch ganz hilfreich sind.
>
> Excel ist ein klarer Kandidat f�r Late binding.
Tut mir Leid, wenn ich dich nerve, aber hier bin ich nochmals auf deine
Hilfe angewiesen, da ich selbst mit LateBinding bisher noch nix gemacht
habe.
Ich schreib mal meinen geistigen Erguss nieder.
Der Zugriff auf Excel sieht z.Zt. folgenderma�en aus
#####
Dim xlApp As Excel.Application
Dim xlWrkbk As Excel.Workbook
Dim xlChartObj As Excel.Chart
Dim xlSourceRange As Excel.Range
Dim xlColPoint As Excel.Point
Set xlApp = CreateObject("Excel.Application")
Set xlWrkbk = xlApp.Workbooks.Open(strNameDerExceldatei)
' Bestimmen der Gr��e und Speichern des Bereichs.
Set xlSourceRange = _
xlWrkbk.Worksheets(1).Range("a2:c" & intCount + 1).CurrentRegion
' Erstellen eines neuen Diagramms.
Set xlChartObj = xlApp.Charts.Add
...
#####
Ich m�sste also aus 'Dim xl... As Excel...
-> 'Dim xl... As Object' machen, dann:
-> Set xlApp = getObject(, "Excel.Application")
oder sollte CreateObject() benutzt werden? Ben�tigt das mehr Speicher?
Die nachfolgenden Set-Aufrufe k�nnten doch bestehen bleiben, da ja immer auf
xlApp verwiesen wird.
Das w�rde ja bedeuten, dass man beim programmieren schon den Verweis
einbinden k�nnte (Helferlein!), danach, wenn alles passt einfach die
Dimensionierungen auf ein Object verweist, den Verweis entfernt und der K�s
ist gegessen.
Oder stelle ich mir das zu einfach vor?
Ich hab hier n�mlich den Vortrag von Thomas Moeller von der 10. AEK
(Verweise) vor mir liegen.
Jaaa, ich habs ausgedruck und abgeheftet.
:)
> Und Outlook erst recht, weil sich dessen Objektmodell von Version zu
> Version immer erheblich ge�ndert hat. Mit einem Verweis auf OL2003 kriegt
> man unter OL2007 z.B. ziemlich Stress.
> Es gibt keinen Grund, warum man einen Verweis drauf setzen m�sste, au�er
> den, dass es die Programmierarbet erleichert.
Ist das kein ausreichender Grund?
> Und maximal noch den, dass man die Objekte WithEvents deklarieren k�nnte,
> um Ereignisse abzufangen. Aber wer macht sowas denn schon?
Outlook hab ich schon rausgeschmissen, da wir ja eh auf Lotus umgestellt
haben.
:))
>
>> - MSCOMM hab ich rausgeschmissen und stattdessen
>> ein ActivX-Control eingebunden.
>> Da hab ich mal den Teufel mit dem Beelzebub ausgtrieben! ;)
>
> Allerdings. Hier hat sich in punto Verweise nichts zum Besseren ver�ndert.
> Jetzt ist halt ein anderer neuer VErweis drin. ;-)
Jahhh, schon, aber da sch... ich drauf. Wenigstens funktionieren dann die
anderen Funktionen (Left(), Anzahl(),...)
Mit diesem Fehler kann ich irgendwie einfacher umgehen.
>
Mein Gott, was w�rde ich machen, wenn es euch Gurus net g�b!!
Viele Gr��e,
Volker
Thomas Winkler
>>> Scripting - Microsoft Scripting Runtime
>
> - Scripting brauch ich fￜr Dateigrￜￜenermittlungen
Nur zur Dateigrￜￜenermittlung kannst Du auf das hￜￜliche Scripting
verzichten. Das erledigt auch die Funktion "FileLen".
HTH
Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Doerthe Weber
> Der Zugriff auf Excel sieht z.Zt. folgendermaï¿œen aus
>
> #####
> Dim xlApp As Excel.Application
> Dim xlWrkbk As Excel.Workbook
> Dim xlChartObj As Excel.Chart
> Dim xlSourceRange As Excel.Range
> Dim xlColPoint As Excel.Point
>
> Set xlApp = CreateObject("Excel.Application")
> Set xlWrkbk = xlApp.Workbooks.Open(strNameDerExceldatei)
>
> ' Bestimmen der Grￜￜe und Speichern des Bereichs.
> Set xlSourceRange = _
> xlWrkbk.Worksheets(1).Range("a2:c" & intCount + 1).CurrentRegion
> ' Erstellen eines neuen Diagramms.
> Set xlChartObj = xlApp.Charts.Add
> ...
>
> #####
>
> Ich mï¿œsste also aus 'Dim xl... As Excel...
> -> 'Dim xl... As Object' machen, dann:
> -> Set xlApp = getObject(, "Excel.Application")
> oder sollte CreateObject() benutzt werden? Benï¿œtigt das mehr Speicher?
Ob du GetObject oder CreateObject benutzt, hï¿œngt davon ab, ob Excel
schon auf ist oder nicht...
> Die nachfolgenden Set-Aufrufe kï¿œnnten doch bestehen bleiben, da ja immer auf
> xlApp verwiesen wird.
>
> Das wï¿œrde ja bedeuten, dass man beim programmieren schon den Verweis
> einbinden kï¿œnnte (Helferlein!), danach, wenn alles passt einfach die
> Dimensionierungen auf ein Object verweist, den Verweis entfernt und der Kï¿œs
> ist gegessen.
>
> Oder stelle ich mir das zu einfach vor?
Nein, es geht tatsï¿œchlich genau so einfach
Gruￜ
Doerthe
Volker Scherf
>> -> Set xlApp = getObject(, "Excel.Application")
>> oder sollte CreateObject() benutzt werden? Benï¿œtigt das mehr Speicher?
>
> Ob du GetObject oder CreateObject benutzt, hï¿œngt davon ab, ob Excel schon
> auf ist oder nicht...
>
Versteh ich net, wenn Excel nicht drauf ist, was nï¿œtzt es dann drauf zu
verweisen?? Ist doch nix da.
Ich kann aber von 99,99%iger Sicherheit ausgehen, dass es drauf ist. Dann
wï¿œrde, nehme ich an, GetObject() genï¿œgen.
>> Das wï¿œrde ja bedeuten, dass man beim programmieren schon den Verweis
>> einbinden kï¿œnnte (Helferlein!), danach, wenn alles passt einfach die
>> Dimensionierungen auf ein Object verweist, den Verweis entfernt und der
>> Kï¿œs ist gegessen.
>>
>> Oder stelle ich mir das zu einfach vor?
>
> Nein, es geht tatsï¿œchlich genau so einfach
Cool, dann bin ja einige Fehlerquellen los.
Ich danke euch fï¿œr eure Hilfe!
Viele Grￜￜe und ein schￜnes langes Wochenende,
Volker
Volker Scherf
"Thomas Winkler" schrieb im Newsbeitrag
news:%23npvjAZ...@TK2MSFTNGP06.phx.gbl...
>
>>>> Scripting - Microsoft Scripting Runtime
>>
>> - Scripting brauch ich fￜr Dateigrￜￜenermittlungen
>
> Nur zur Dateigrￜￜenermittlung kannst Du auf das hￜￜliche Scripting
> verzichten. Das erledigt auch die Funktion "FileLen".
Das werde ich dann auch tun.
Danke!
Thomas Winkler
>> Ob du GetObject oder CreateObject benutzt, hï¿œngt davon ab, ob Excel
>> schon auf ist oder nicht...
^^^
> Versteh ich net, wenn Excel nicht drauf ist, was nï¿œtzt es dann drauf zu
^^^^^
> verweisen?? Ist doch nix da.
> Ich kann aber von 99,99%iger Sicherheit ausgehen, dass es drauf ist.
> Dann wï¿œrde, nehme ich an, GetObject() genï¿œgen.
Hier hast Du offensichtlich nicht richtig gelesen. Es geht nicht darum
ob Excel "drauf" ist sondern ob es es bereits lï¿œuft.
GetObject nimmst Du, wenn Du die mï¿œglicherweise bereits geï¿œffnete
Excel-Instanz benutzen mï¿œchtest. CreateObject legt eine neue
Excel-Instanz an.
Volker Scherf
>>> Ob du GetObject oder CreateObject benutzt, hï¿œngt davon ab, ob Excel
>>> schon auf ist oder nicht...
> ^^^
>
>> Versteh ich net, wenn Excel nicht drauf ist, was nï¿œtzt es dann drauf zu
> ^^^^^
>> verweisen?? Ist doch nix da.
>> Ich kann aber von 99,99%iger Sicherheit ausgehen, dass es drauf ist. Dann
>> wï¿œrde, nehme ich an, GetObject() genï¿œgen.
>
> Hier hast Du offensichtlich nicht richtig gelesen. Es geht nicht darum ob
> Excel "drauf" ist sondern ob es es bereits lï¿œuft.
Ups, wer lesen kann ist klar im Vorteil.
Ich nehme alles zurï¿œck.
Danke fï¿œr den Hinweis.
Aber das ist der Beweis! Es gibt keine dumme Antworten, nur dumme Fragen.
...oder war das anders herum??
Viele Grￜￜe,
Volker
Doerthe Weber
Volker Scherf schrieb:
Wenn wir noch die Mï¿œglichkeiten der falsch verstandenen Fragen bzw.
Antworten dazu nehmen (ob nun dumm oder nicht) bekommen wir auf jeden
Fall einen Haufen unterhaltsame Kommunikationsmï¿œglichkeiten ;-)
Gruￜ
Doerthe
Thomas Möller
Volker Scherf schrieb:
nein, genau so ist das. Du kannst Dir die Arbeit mit der Bedingten
Kompilierung noch einfacher machen:
#If EarlyBinding Then
Dim objWord As Word.Application
Set objWord = New Word.Application
#Else
Dim objWord As Object
Set objWord = CreateObject("Word.Application")
Const wdWindowStateMaximize = 1
#End If
Dies Beispiel ist zwar mit Word, aber ich denke, dass das Prinzip klar wird.
So brauchst Du zum Umschalten zwischen Late- und Early-Binding nur eine
Konstante und einen Verweis anpassen. Der restliche Code bleibt unver�ndert.
Volker Scherf
"Thomas M�ller" schrieb im Newsbeitrag
news:75uadhF...@mid.individual.net...
Na klar hat�s geholfen, das ist genial einfach.
So werd ich da auf jeden Fall umsetzen.
Da bin ich auf jeden Fall diverse Fehlerquellen los.
Danke f�r die geduldige Hilfe, auch nochmals an Doerthe, Sascha, Thomas W.
und Jens!
Viele Gr��e,
Volker
Jens Schilling
Volker Scherf wrote:
> Danke f�r die geduldige Hilfe, auch nochmals an Doerthe, Sascha,
> Thomas W. und Jens!
Letzterer hat noch einen Tipp f�r Dich :
Der Vortrag "Automation von Excel und Word" von Michael Zimmermann -
vorgetragen w�hrend der 9. AEK - hat noch so Einiges an Details zum Thema zu
bieten; so z.B. die direkte Instamzierung eines Word-Dokumentes, ohne sich
um laufende Instanzen k�mmern zu m�ssen.
Schau doch mal in den Vortrag rein, Du findest diesen - �brigens incl.
Demo-DB - hier :
http://www.donkarl.com/AEK/AEK_Downloads.htm
Gruss
Jens