Wenn ich unter XL2000 in VBA einen Verweis auf SOLVER.XLA setzte und
dann das File mit einer anderen Excel-Version öffne, dann meckert er
wegen des fehlenden Verweises.
Im Prinzip müsste man nun "von Hand" den Verweis nachpflegen, was ich
aber meinen Usern nicht zumuten kann/möchte, zumal er bei geschütztem
VBA-Project eh nicht drankommt.
Gibt es da eine Chance in WorkBook_Open den Pfad zu reparieren?
Oder kann man den kaputten Verweis entfernen?
Theoretisch wäre es ja möglich nach SOLVER.XLA zu suchen und ihn in
etwa so hinzuzufügen:
Public Sub setzen()
Dim intIndex As Integer, bolgefunden As Boolean
With ThisWorkbook.VBProject.References
For intIndex = 1 To .Count
If Right(.Item(intIndex).FullPath, InStr(1, StrReverse( _
.Item(intIndex).FullPath), "\") - 1) = "SOLVER.XLA" Then _
bolgefunden = True: Exit For
Next
If Not bolgefunden Then .AddFromFile "C:\Programme\Microsoft " & _
"Office\OFFICE11\Makro\Solver\SOLVER.XLA"
End With
End Sub
Oder kann man den Verweis einfach nochmals "draufhauen" und die
kaputten Verweise einfach ignorieren?
Hat da jemand zufälliger Weise was fertiges für dies "uralte" Problem?
Andere Lösungsansätze, Hinweise?
Andreas.
> Bedingte Kompilierung oder Abfrage von Systemvariablen kommt nicht in Frage?
Bedingte Kompilierung:
Nein, ich brauche den Solver im WorkSheet_Change um die Ergebnisse von
Formeln zu optimieren.
Abfrage von Systemvariablen:
? Keine Ahnung, was kann ich da abfragen?
Stell Dir vor Du bekommst mein Excel-File, wie kann ich sicherstellen
das es bei Dir läuft ohne das Du eingreifen musst?
Andreas.
Andreas Killer schrieb am 15.10.2009
> Juhu. :-))
Ja, auch soviel :-))
> Wenn ich unter XL2000 in VBA einen Verweis auf SOLVER.XLA setzte und
> dann das File mit einer anderen Excel-Version �ffne, dann meckert er
> wegen des fehlenden Verweises.
Nicht nur in diesem Falle, auch folgende Situationen werden angemeckert:
- Excel 2007 und j�nger
- Andere Sprach-Version von Excel
- Andere Sprach-Version des Betriebssystems
- 64-bit Betriebssystem
Der Grund liegt in den unterschiedlichen Pfad-Namen in denen der Solver
abgegegt ist und in der neuen Endung seit xl2007
> Im Prinzip m�sste man nun "von Hand" den Verweis nachpflegen, was ich
> aber meinen Usern nicht zumuten kann/m�chte, zumal er bei gesch�tztem
> VBA-Project eh nicht drankommt.
> Hat da jemand zuf�lliger Weise was fertiges f�r dies "uralte" Problem?
> Andere L�sungsans�tze, Hinweise?
Ja, dasselbe Problem hatte ich in der Firma ebenfalls.
Ein Tool f�r sehr zentrale Berechnungen wird in den USA entwickelt und
kommt dann hier unter deutschem BS zum Einsatz.
Dann gab es noch neue PC's mit 64-bit Architektur.
Die Datei mit der Berechnung sollte (Wunsch!) auf allen Rechnern laufen
ohne dass ein Eingreifen seitens des Usersr notwendig ist.
Aus den oben genannten Gr�nden war das nicht m�glich, daher habe ich mit
Unterst�tzung des WWW die folgenden Routinen zusammengestellt. Dabei wird
kein Verweis gesetzt oder ben�tigt - einzige Voraussetzung ist, dass das
Solver-AddIn installiert ist, ansonsten gibt es eine Meldung.
Die Subs und Funktionen habe ich in einem Modul namens Check_Solver
abgelegt und die Sub 'CheckSolverIntl' wird aus dem Workbook_Open() heraus
aufgerufen.
Da der Solver �blicherweise eine erste manuelle Anstossung ben�tigt um
anschliessend per VBA automatisiert verwendet werden zu k�nnen wird dessen
Auto_Open-Makro ebenfalls gleich im Code angestossen.
Der einzige Unterschied im Aufruf per VBA ist dann, dass nicht mit
SolverSolve gestartet werden kann sondern mit der folgenden Zeile -
wiederum wegen des m�glichen Unterschides zu xl2007:
If Application.Version < 12 Then
Application.Run "Solver.xla!SolverSolve", False
Else
Application.Run "Solver.xlam!SolverSolve", False
End If
Bei Bedarf kann ich auch gerne die Demo-Mappe die ich zusammengestellt habe
zur Verf�gung stellen. Mich w�rde selbst interessieren wie sie sich unter
verschiedenen Umgebungen verh�lt. Das wird in der Demo-Mappe kurz
protokolliert wenn sie ge�ffnet wird.
Und hier noch die Codes f�r das Modul:
Option Explicit
Function CheckSolverIntl() As Boolean
'' Adjusted for Application.Run() to avoid Reference problems with
Solver
'' Adjusted for international versions of Excel and Versions >= xl2007
'' Returns True if Solver can be used, False if not.
Dim bSolverInstalled As Boolean
Dim bAddInFound As Boolean
Dim iAddIn As Long
Const sAddIn As String = "solver.xla"
'' Assume true unless otherwise
CheckSolverIntl = True
On Error Resume Next
' check whether Solver is installed
bSolverInstalled = IsInstalled(sAddIn)
Err.Clear
If bSolverInstalled Then
' uninstall temporarily
bAddInFound = AddInInstall(sAddIn, False)
' check whether Solver is installed (should be false)
bSolverInstalled = IsInstalled(sAddIn)
End If
If Not bSolverInstalled Then
' (re)install Solver
bAddInFound = AddInInstall(sAddIn, True)
' check whether Solver is installed (should be true)
bSolverInstalled = IsInstalled(sAddIn)
End If
If Not bSolverInstalled Then
MsgBox "Solver not found. This workbook will not work.", vbCritical
CheckSolverIntl = False
End If
If CheckSolverIntl Then
' initialize Solver depending of Excel-Version
If Application.Version < 12 Then
Application.Run "Solver.xla!Solver.Solver2.Auto_open", False
Else
Application.Run "Solver.xlam!Solver.Solver2.Auto_open", False
End If
End If
On Error GoTo 0
End Function
Function IsInstalled(sAddInFileName As String) As Boolean
Dim iAddIn As Long
IsInstalled = False
For iAddIn = 1 To Application.AddIns.Count
With Application.AddIns(iAddIn)
If InStr(1, LCase$(.Name), LCase$(sAddInFileName)) > 0 Then
If .Installed Then
IsInstalled = True
End If
Exit For
End If
End With
Next
End Function
Function AddInInstall(sAddInFileName As String, bInstall As Boolean) As
Boolean
Dim iAddIn As Long
For iAddIn = 1 To Application.AddIns.Count
With Application.AddIns(iAddIn)
If InStr(1, LCase$(.Name), LCase$(sAddInFileName)) > 0 Then
If .Installed <> bInstall Then
.Installed = bInstall
End If
AddInInstall = True ' True = add-in is listed
Exit For
End If
End With
Next
End Function
Mit freundlichen Gr�ssen
Thomas Ramel
--
- MVP f�r Microsoft-Excel -
[Vista Ultimate SP-1 / xl2007 SP-1]
Sub ListActiveVBEReferences()
'F�r das Early Binding des Reference-Objektes muss ein Verweis
'auf die "Microsoft Visual Basic for Applications Extensibility"
'unter Extras/Verweise gesetzt werden, ansonsten ist Late Binding
'anzuwenden.
'Early Binding
'Dim myReference As Reference
'Late Binding
Dim myReference As Object
ActiveWorkbook.Worksheets.Add
'Spalten�berschriften eintragen
ActiveSheet.Range("A1:G1").Value = _
Array("Description", "Name", "GUID", "Major", _
"Minor", "FullPath", "IsBroken")
For Each myReference In Application.VBE.ActiveVBProject.References
With ActiveSheet.Cells(ActiveSheet.Rows.Count, 1). _
End(xlUp).Offset(1, 0)
.Value = myReference.Description
.Offset(0, 1).Value = myReference.Name
.Offset(0, 2).Value = myReference.GUID
.Offset(0, 3).Value = myReference.Major
.Offset(0, 4).Value = myReference.Minor
.Offset(0, 5).Value = myReference.FullPath
.Offset(0, 6).Value = myReference.IsBroken
End With
Next
Columns("A:F").AutoFit
End Sub
------------------------------------------------------------------------------------------------------------
Mit den beiden folgenden Prozeduren kannst du gezielt den Verweis auf
den Solver entfernen bzw. setzen. Die Prozedur "AddSolverReference"
setzt voraus, das der Solver im Dialogfeld "AddIns" gelistet wird.
Public Sub RemoveReference()
Dim myReference As Object
Const strReferenceName As String = "SOLVER"
For Each myReference In ThisWorkbook.VBProject.References
If myReference.Name = strReferenceName Then
ThisWorkbook.VBProject.References.Remove _
ThisWorkbook.VBProject.References(myReference.Name)
End If
Next
End Sub
Public Sub AddSolverReference()
Dim myReference As Object
Dim myAddIn As AddIn
Const strAddInName As String = "SOLVER.XLA" 'oder SOLVER.XLAM
Const strReferenceName As String = "SOLVER"
'Pr�fen, ob die Reference bereits gesetzt wurde
For Each myReference In ThisWorkbook.VBProject.References
If UCase(myReference.Name) = strReferenceName Then
Exit Sub
End If
Next
'Falls nicht, Reference setzen
For Each myAddIn In Application.AddIns
If myAddIn.Name = strAddInName Then
ThisWorkbook.VBProject.References.AddFromFile myAddIn.FullName
End If
Next
End Sub
Mit freundlichem Gru� aus der Rattenf�ngerstadt Hameln
Frank Arendt-Theilen
--
(ehem. MVP f�r Excel)
Website: www.xl-faq.de
Microsoft - Excel, Bedingte Formatierung, ISBN: 978-3-86645-806-2
Frank Arendt-Theilen schrieb am 17.10.2009
> Hallo Andreas,
> folgende Prozedur verschafft Dir einen �berblick �ber die gesetzten
> Verweise:
>
> Sub ListActiveVBEReferences()
Das ist eine feine Sache, so muss sich der User im ersten Moment nicht
selbst durchhangeln bis zu den Verweisen!
> Mit den beiden folgenden Prozeduren kannst du gezielt den Verweis auf
> den Solver entfernen bzw. setzen. Die Prozedur "AddSolverReference"
> setzt voraus, das der Solver im Dialogfeld "AddIns" gelistet wird.
Leider klappt das Setzen eines Verweises nicht, wenn das VBA-Projekt
gesch�tzt ist.
Das Auflisten und (interessanterweise) das Entfernen eines Verweises klappt
auch wenn das VBA-Projekt gesch�tzt ist.
> Der einzige Unterschied im Aufruf per VBA ist dann, dass nicht mit
> SolverSolve gestartet werden kann sondern mit der folgenden Zeile -
> wiederum wegen des m�glichen Unterschides zu xl2007:
>
> If Application.Version < 12 Then
> Application.Run "Solver.xla!SolverSolve", False
> Else
> Application.Run "Solver.xlam!SolverSolve", False
> End If
Hmm, und wie machst Du dann SolverOK, SolverAdd, etc. in VBA ?
Auch �ber Application.Run?
> Function CheckSolverIntl() As Boolean
Das Teil pr�ft aber nur ob das Solver-Add-In geladen ist, ich brauche
aber den Verweis zu SOLVER.XLA in VBA, sonst geht doch kein
SolverSolve userFinish:=False, etc.
oder (mit einem Trick) doch???
> If Application.Version < 12 Then
> Application.Run "Solver.xla!Solver.Solver2.Auto_open", False
> Else
> Application.Run "Solver.xlam!Solver.Solver2.Auto_open", False
> End If
Das geht so nicht, auf meinem XL2002 m�chte er
"Solver.xlam!Solver.Solver2.Auto_open"
ausf�hren, denn Application.Version gibt bei mir "10.0" als String!
�nder das mal in
If Val(Application.Version) < 12 Then
dann geht's.
Andreas.
> folgende Prozedur verschafft Dir einen �berblick �ber die gesetzten
> Verweise:
...
> Mit den beiden folgenden Prozeduren kannst du gezielt den Verweis auf
> den Solver entfernen bzw. setzen. Die Prozedur "AddSolverReference"
> setzt voraus, das der Solver im Dialogfeld "AddIns" gelistet wird.
Vielen Dank, das hilft mir weiter.
BTW, das das setzen des Verweises nur bei ungesch�tztem VBA-Project
m�glich ist l��t sich akzeptieren.
Andreas.
Andreas Killer schrieb am 17.10.2009
> Thomas Ramel schrieb:
>
>> Der einzige Unterschied im Aufruf per VBA ist dann, dass nicht mit
>> SolverSolve gestartet werden kann sondern mit der folgenden Zeile -
>> wiederum wegen des m�glichen Unterschides zu xl2007:
>>
>> If Val(Application.Version) < 12 Then
>> Application.Run "Solver.xla!SolverSolve", False
>> Else
>> Application.Run "Solver.xlam!SolverSolve", False
>> End If
> Hmm, und wie machst Du dann SolverOK, SolverAdd, etc. in VBA ?
> Auch �ber Application.Run?
Ja, korrekt - siehe unten.
>> Function CheckSolverIntl() As Boolean
> Das Teil pr�ft aber nur ob das Solver-Add-In geladen ist, ich brauche
> aber den Verweis zu SOLVER.XLA in VBA, sonst geht doch kein
> SolverSolve userFinish:=False, etc.
> oder (mit einem Trick) doch???
Das hatte ich gegen Ende meines Beitrages ja auch geschrieben, ebenfalls
siehe unten
>> If Application.Version < 12 Then
>> Application.Run "Solver.xla!Solver.Solver2.Auto_open", False
>> Else
>> Application.Run "Solver.xlam!Solver.Solver2.Auto_open", False
>> End If
> Das geht so nicht, auf meinem XL2002 m�chte er
> "Solver.xlam!Solver.Solver2.Auto_open"
> ausf�hren, denn Application.Version gibt bei mir "10.0" als String!
>
> �nder das mal in
> If Val(Application.Version) < 12 Then
> dann geht's.
Ja, logo!
Im Original in der Firma ist das auch so gel�st.
Der Aufruf aller Solver-Teile erfolgt dann prinzipiell �ber Application.Run
und mit Angabe des Dateinamens des Addins:
If Val(Application.Version) < 12 Then
Application.Run "Solver.xla!SolverSolve", False
Else
Application.Run "Solver.xlam!SolverSolve", False
End If
Mit dieser Konstellation ist es dann aber m�glich, die Datei �berall zu
verwenden so wie Du es gew�nscht hattest:
>> Stell Dir vor Du bekommst mein Excel-File, wie kann ich sicherstellen
>> das es bei Dir l�uft ohne das Du eingreifen musst?
>> Das Teil pr�ft aber nur ob das Solver-Add-In geladen ist, ich brauche
>> aber den Verweis zu SOLVER.XLA in VBA, sonst geht doch kein
>> SolverSolve userFinish:=False, etc.
>> oder (mit einem Trick) doch???
> Das hatte ich gegen Ende meines Beitrages ja auch geschrieben, ebenfalls
> siehe unten
Wie was wo, lese lese lese, �hmm...Rembrandt???
Soll das hei�en ich brauche gar keinen Verweis im VBA auf SOLVER.XLA?
Andreas.
Andreas Killer schrieb am 17.10.2009
> Thomas Ramel schrieb:
>
>>> Das Teil pr�ft aber nur ob das Solver-Add-In geladen ist, ich brauche
>>> aber den Verweis zu SOLVER.XLA in VBA, sonst geht doch kein
>>> SolverSolve userFinish:=False, etc.
>>> oder (mit einem Trick) doch???
>> Das hatte ich gegen Ende meines Beitrages ja auch geschrieben, ebenfalls
>> siehe unten
> Wie was wo, lese lese lese, �hmm...Rembrandt???
Ich zitiere mit hier mal selbst aus meinem Beitrag vom 16.10.
>>>> Der einzige Unterschied im Aufruf per VBA ist dann, dass nicht mit
>>>> SolverSolve gestartet werden kann sondern mit der folgenden Zeile -
>>>> wiederum wegen des m�glichen Unterschides zu xl2007:
>>>>
>>>> If Application.Version < 12 Then
>>>> Application.Run "Solver.xla!SolverSolve", False
>>>> Else
>>>> Application.Run "Solver.xlam!SolverSolve", False
>>>> End If
> Soll das hei�en ich brauche gar keinen Verweis im VBA auf SOLVER.XLA?
Ja, das ist korrekt - wenn Du mit Application.Run auf eine geladene Datei
zugreifst (das kann auch ein AddIn sein) ist kein Verweis notwendig.
Es fehlt dann halt die Intellisense und im Objekt-Explorer fehlt der Solver
ebenfalls, aber beim Solver ist die 'Auswahl' an Methoden ja nicht allzu
gross.
Ggf. k�nnte man f�r die Entwicklung der Anwendung den Verweis setzen, ihn
am Ende aber wieder entfernen.
>> Soll das hei�en ich brauche gar keinen Verweis im VBA auf SOLVER.XLA?
> Ja, das ist korrekt - wenn Du mit Application.Run auf eine geladene Datei
> zugreifst (das kann auch ein AddIn sein) ist kein Verweis notwendig.
Ahhhaaaaaaaaaaaaa! Das ja'n Dings das. Na sag das doch gleich. :-)))
Sorry, ich bin manchmal schwer von Begriff.
> Es fehlt dann halt die Intellisense und im Objekt-Explorer fehlt der Solver
> ebenfalls, aber beim Solver ist die 'Auswahl' an Methoden ja nicht allzu
> gross.
Das ist kein Problem, da kann man ja eine kleine Shell drumherum
schreiben, dann geht das alles von alleine, die Intellisense w�re
vorhanden und aufgezeichnete Makro liefen auch..., Moment datt ham wir
gleich.
Zwischendurch noch 'ne Frage:
Warum wird in Deiner CheckSolverIntl zuerst das AddIn de- und
anschlie�end wieder aktiviert?
W�rde es nicht reichen
a.) zu pr�fen ob "SOLVER.XLA*" da ist und es
b.) wenn ja ggf. mit .Installed = True zu aktivieren?
Andreas.
Andreas Killer schrieb am 18.10.2009
> Thomas Ramel schrieb:
>
>>> Soll das hei�en ich brauche gar keinen Verweis im VBA auf SOLVER.XLA?
>> Ja, das ist korrekt - wenn Du mit Application.Run auf eine geladene Datei
>> zugreifst (das kann auch ein AddIn sein) ist kein Verweis notwendig.
> Ahhhaaaaaaaaaaaaa! Das ja'n Dings das. Na sag das doch gleich. :-)))
>
> Sorry, ich bin manchmal schwer von Begriff.
Das kann ich kaum glauben, ist aber auch kein Problem... ;-)
>> Es fehlt dann halt die Intellisense und im Objekt-Explorer fehlt der Solver
>> ebenfalls, aber beim Solver ist die 'Auswahl' an Methoden ja nicht allzu
>> gross.
> Das ist kein Problem, da kann man ja eine kleine Shell drumherum
> schreiben, dann geht das alles von alleine, die Intellisense w�re
> vorhanden und aufgezeichnete Makro liefen auch..., Moment datt ham wir
> gleich.
>
> Zwischendurch noch 'ne Frage:
>
> Warum wird in Deiner CheckSolverIntl zuerst das AddIn de- und
> anschlie�end wieder aktiviert?
>
> W�rde es nicht reichen
>
> a.) zu pr�fen ob "SOLVER.XLA*" da ist und es
> b.) wenn ja ggf. mit .Installed = True zu aktivieren?
Wie gesagt habe ich einen Teil des Codes aus dem WWW und dann weiter
modifiziert um alle(?) weiteren M�glichkeiten abzudecken.
Dieser Teil stammt aus dem Original und ist mir auch schon aufgefallen.
Das Ganze h�ngt wohl damit zusammen, dass die Speicherorte des AddIns je
nach System ganz anders sein k�nnen und man sichergehen wollte, dass das
AddIn sauber eingebunden ist. Zumal dann ja auch 'zu Fuss' das Auto_Open-
Makro des Solver gestartet wird. Das passiert normalerweise beim ersten
(manuellen) Start des Solvers und muss nun ebenfalls nicht gemacht werden.
Wir hatten in unserem Umfeld laufend Probleme mit gebrochenen Verweisen je
nach System auf dem die Mappe verwendet werden sollte und wo sie zuvor
gelaufen ist (die Mappe wird pro Projekt erstellt und dann ggf. von
verschiedenen Personen ge�ffnet/bearbeitet/angesehen). Es kann bei
gebrochenen Verweisen sein, dass der Code nicht kompiliert werden kann dann
klappt IMO auch das Entfernen und erneute Hinzuf�gen des Verweises per Code
nicht.
Seit ich die Mappe auf dieses System umgestellt habe hatten wir keines
dieser Ph�nomene mehr und k�nnen die Mappe quer �ber alle Versionen,
Betriebssysteme und Sprachen einsetzen.
Wenn ich darf w�rde ich dir gerne meine Demo-Mappe zusenden, die genau
diesen Code enth�lt. Zudem wird dort dann beim �ffnen der Username und
einige Angaben zum Solver-AddIn ausgelesen und in eine Liste geschrieben.
Ich wollte einfach gerne das ganze auf einigen weiteren Systemen getestet
haben. Also einfach Mappe �ffnen - Makros aktivieren - abwarten - speichern
und an mich zur�cksenden.
Wenn Du dazu bereit bist, dann sende doch kurz eine Mail an meine Adresse
hier in der NG (nat�lich auch alle anderen die hier mitlesen) und ich sende
dir die Mappe zu.
>> Sorry, ich bin manchmal schwer von Begriff.
> Das kann ich kaum glauben, ist aber auch kein Problem... ;-)
Naja, da ist man Jahrelang daran gew�hnt das dieses oder jenes nur so
und so geht und dann erz�hlt jemand das man die ganzen K�se nicht
braucht der in der offiziellen Excel-Hilfe drin steht...
> Wenn ich darf w�rde ich dir gerne meine Demo-Mappe zusenden, die genau
> diesen Code enth�lt. Zudem wird dort dann beim �ffnen der Username und
> einige Angaben zum Solver-AddIn ausgelesen und in eine Liste geschrieben.
> Ich wollte einfach gerne das ganze auf einigen weiteren Systemen getestet
> haben. Also einfach Mappe �ffnen - Makros aktivieren - abwarten - speichern
> und an mich zur�cksenden.
Ja klaro, schick her das Teil.
Bitte im Betreff "Re" oder "Excel" angeben, dann muss ich die Mail
nicht aus dem GMX-SPAM-Ordner raussuchen.
Ich hab hier WinXP mit XL2002 und morgen auf der Arbeit Win2k mit Xl2000.
BTW, ich hab zwischenzeitlich ein wenig experimentiert, mir ein paar
sub's ala
Private Sub SetSOLVERXLA()
If Val(Application.Version) < 12 Then
SOLVERXLA = "solver.xla"
Else
SOLVERXLA = "solver.xlam"
End If
End Sub
Public Sub SolverAdd(CellRef, Relation As Integer, Optional _
FormulaText)
If Len(SOLVERXLA) = 0 Then SetSOLVERXLA
Application.Run SOLVERXLA & "!SolverAdd", CellRef, Relation, _
FormulaText
End Sub
geschrieben, sieht ganz gut aus, in einer Test-Mappe l�uft es
einwandfrei, in einem Projekt-File gibt's komische Probleme:
Angefangen von "Solver: Ein unerwarteter interner Fehler ist
aufgetreten", bis hin zu einem "RTE 9 Index au�erhalb Bereich" beim
Aufrufen des Solvers im Excel-Men�.
Mache ich den Solver-Dialog nach dem �ffnen des Files einmal von Hand
auf und wieder zu, dann l�uft es... na ja schaun wir mal.
Andreas.
Andreas Killer schrieb am 18.10.2009
> Thomas Ramel schrieb:
>
>>> Sorry, ich bin manchmal schwer von Begriff.
>> Das kann ich kaum glauben, ist aber auch kein Problem... ;-)
> Naja, da ist man Jahrelang daran gew�hnt das dieses oder jenes nur so
> und so geht und dann erz�hlt jemand das man die ganzen K�se nicht
> braucht der in der offiziellen Excel-Hilfe drin steht...
>
>> Wenn ich darf w�rde ich dir gerne meine Demo-Mappe zusenden, die genau
>> diesen Code enth�lt. Zudem wird dort dann beim �ffnen der Username und
>> einige Angaben zum Solver-AddIn ausgelesen und in eine Liste geschrieben.
>> Ich wollte einfach gerne das ganze auf einigen weiteren Systemen getestet
>> haben. Also einfach Mappe �ffnen - Makros aktivieren - abwarten - speichern
>> und an mich zur�cksenden.
> Ja klaro, schick her das Teil.
>
> Bitte im Betreff "Re" oder "Excel" angeben, dann muss ich die Mail
> nicht aus dem GMX-SPAM-Ordner raussuchen.
OK, ich versuche es - das Projekt ist mit einem PW gesch�tzt, tut aber
nichts Unanst�nidges ;-)
Es soll halt auch gleich getestet werden ob das Ganze bei gsch�tztem
VBA-projekt reibungslos klappt.
> Ich hab hier WinXP mit XL2002 und morgen auf der Arbeit Win2k mit Xl2000.
Das w�re perfekt :-)
> BTW, ich hab zwischenzeitlich ein wenig experimentiert, mir ein paar
> sub's ala
>
> Private Sub SetSOLVERXLA()
> If Val(Application.Version) < 12 Then
> SOLVERXLA = "solver.xla"
> Else
> SOLVERXLA = "solver.xlam"
> End If
> End Sub
>
> Public Sub SolverAdd(CellRef, Relation As Integer, Optional _
> FormulaText)
> If Len(SOLVERXLA) = 0 Then SetSOLVERXLA
> Application.Run SOLVERXLA & "!SolverAdd", CellRef, Relation, _
> FormulaText
> End Sub
>
> geschrieben, sieht ganz gut aus, in einer Test-Mappe l�uft es
> einwandfrei, in einem Projekt-File gibt's komische Probleme:
>
> Angefangen von "Solver: Ein unerwarteter interner Fehler ist
> aufgetreten", bis hin zu einem "RTE 9 Index au�erhalb Bereich" beim
> Aufrufen des Solvers im Excel-Men�.
>
> Mache ich den Solver-Dialog nach dem �ffnen des Files einmal von Hand
> auf und wieder zu, dann l�uft es... na ja schaun wir mal.
Ja, das hatte ich erw�hnt - der Solver muss einmalig von Hand gestartet
werden um die Auto_Open-Makros in der Solver.xla zu aktivieren. Die nehem
bestimmte Einstellungen vor und initialisieren das AddIn.
Der Code den ich verwende tut das eben gleich direkt durch den Aufruf nach
der Installation des AddIns.
Dabei sind dann diese Fehler nicht mehr aufgetreten soweit ich es
beobachtet habe.
> Die Subs und Funktionen habe ich in einem Modul namens Check_Solver
> abgelegt und die Sub 'CheckSolverIntl' wird aus dem Workbook_Open() heraus
> aufgerufen.
> Da der Solver �blicherweise eine erste manuelle Anstossung ben�tigt um
> anschliessend per VBA automatisiert verwendet werden zu k�nnen wird dessen
> Auto_Open-Makro ebenfalls gleich im Code angestossen.
Also ich krieg das definitiv nicht zum Laufen, das mit der "ersten
manuellen Anstossung" scheint unter XL2002 nicht zu funktionieren.
Hier mal ein Test-File:
http://rapidshare.com/files/294544343/Solver.xls.html
Bitte direkt nach dem �ffnen Zelle B2 �ndern:
�ber Worksheet_Change wird ein Makro aufgerufen welches die
Solver-Routinen aufruft welche �ber Application.Run den Solver ausf�hren.
Gibt unter Xl2002 den Fehler:
"Solver: ein unerwarteter interner Fehler ist aufgetreten"
Nach OK wird der Code generell abgebrochen und
Application.EnableEvents bleibt auf False.
�ffnet man den Solverdialog direkt nach dem �ffnen von Hand und
schlie�t ihn wieder (ohne weitere Aktion), dann l�uft der Code.
Nun ja, fast, die Solver-Ziel-Zelle wird zur aktiven Zelle....
Irgendwelche Ideen dazu?
Andreas.
Andreas Killer schrieb am 18.10.2009
> Thomas Ramel schrieb:
>
>> Die Subs und Funktionen habe ich in einem Modul namens Check_Solver
>> abgelegt und die Sub 'CheckSolverIntl' wird aus dem Workbook_Open() heraus
>> aufgerufen.
>> Da der Solver �blicherweise eine erste manuelle Anstossung ben�tigt um
>> anschliessend per VBA automatisiert verwendet werden zu k�nnen wird dessen
>> Auto_Open-Makro ebenfalls gleich im Code angestossen.
> Also ich krieg das definitiv nicht zum Laufen, das mit der "ersten
> manuellen Anstossung" scheint unter XL2002 nicht zu funktionieren.
>
> Hier mal ein Test-File:
>
> http://rapidshare.com/files/294544343/Solver.xls.html
>
> Bitte direkt nach dem �ffnen Zelle B2 �ndern:
>
> �ber Worksheet_Change wird ein Makro aufgerufen welches die
> Solver-Routinen aufruft welche �ber Application.Run den Solver ausf�hren.
>
> Gibt unter Xl2002 den Fehler:
> "Solver: ein unerwarteter interner Fehler ist aufgetreten"
In xl2007 konnte ich diesen Fehler nicht feststellen.
> Nach OK wird der Code generell abgebrochen und
> Application.EnableEvents bleibt auf False.
>
> �ffnet man den Solverdialog direkt nach dem �ffnen von Hand und
> schlie�t ihn wieder (ohne weitere Aktion), dann l�uft der Code.
>
> Irgendwelche Ideen dazu?
Die Meldung kenne ich aus meinen Versuchen unsere Mappe in verschiedenen
Umgebungen laufen zu lassen.
K�nnte es ggf. sein, dass es zu Konflikten mit den eigentlichen Namen der
Prozeduren im Solver-AddIn kommt?
Ist ev. noch eine andere Mappe offen, die einen Verweis auf das
Solver-AddIn gesetzt hat?
Wie sieht es aus wenn Du jeweils ein 'my' vor die einzelnen Funktionsnamen
setzt - einfach um einen Namenskonflikt wirklich auszuschliessen?
Ich teste auch mal weiter, wenn ich dazu komme.
"Frank Arendt-Theilen" schrieb:
> Mit den beiden folgenden Prozeduren kannst du gezielt den Verweis auf
> den Solver entfernen bzw. setzen. Die Prozedur "AddSolverReference"
> setzt voraus, das der Solver im Dialogfeld "AddIns" gelistet wird.
>
> Public Sub RemoveReference()
> Dim myReference As Object
> Const strReferenceName As String = "SOLVER"
> For Each myReference In ThisWorkbook.VBProject.References
> If myReference.Name = strReferenceName Then
> ThisWorkbook.VBProject.References.Remove _
> ThisWorkbook.VBProject.References(myReference.Name)
> End If
> Next
> End Sub
ich habe aktuell ein Problem unter Excel 2003 mit gebrochenen Verweisen auf den PDFCreator.
Ich m�chte nun pr�fen, ob der Verweis gebrochen ist und den Verweis entfernen.
Leider erhalte ich mit deiner Syntax einen Fehler, weil die Name-Methode bei gebrochenen
Verweisen einen Fehler liefert.
Auch habe ich versucht auf den Index des Verweises zu referenzieren, geht auch nicht.
Aufruf:
CheckReference("PDFCreator","{1CE9DC08-9FBC-45C6-8A7C-4FE1E208A613}")
Public Function CheckReference(strRefName As String, strGUID As String) As Boolean
Dim objRef As Object
Dim VBProjekt As Object
Set VBProjekt = ThisWorkbook.VBProject
For Each objRef In VBProjekt.References
If objRef.IsBroken Then
' Pr�fe GUID
If objRef.GUID = strGUID Then
' Entferne Reference
' Name-Methode schl�gt fehl bei gebrochenem Verweis
' VBProjekt.References.Remove VBProjekt.References(objRef.Name)
' Fehler: Objektbibliothek nicht registriert
VBProjekt.References.Remove objRef
End If
Else
If objRef.Name = strRefName Then
CheckReference = True
End If
End If
Next
End Function
Kennt jemand eine L�sung, um einen gebrochenen Verweis zu entfernen?
Mit freundlichen Gr�ssen
Melanie Breden
--
- Microsoft MVP f�r Excel -
www.melanie-breden.de
Ribbon-Programmierung f�r Office 2007 http://tinyurl.com/59awla
> Kennt jemand eine Lösung, um einen gebrochenen Verweis zu entfernen?
Ich hatte schon in diese Richtung entwickelt, ist aber noch nicht 100%
fertig.
Die angehängte Routine repariert beim mir VBA-Verweise unter XL2000
und XL2002 zuverlässig.
BTW, falls das jemand unter XL2007 braucht: Ich habe ein FileSearch-
Klassenmodul (ohne Propertytests) hier liegen.
Andreas.
Option Explicit
Sub RepairReferences()
'Prüft alle VBA-Verweise und versucht den Pfad zu reparieren
'Z.B. der Pfad zu SOLVER.XLA ist je nach Excel-Version _
verschieden, wird aber von Excel nicht verwaltet.
Dim fs As Object, I As Integer, J As Integer
Dim OldRefPath As String, NewRefPath As String, TempPath As _
String
Dim StatusBarState As Boolean
With ThisWorkbook.VBProject.References
I = 1
'Durchlaufe die Verweise
Do While I <= .Count
'Verweis kaputt?
If .Item(I).IsBroken Then
'Statusbar aktivieren
StatusBarState = Application.DisplayStatusBar
Application.DisplayStatusBar = True
Application.StatusBar = "Gebrochener Verweis gefunden, " & _
"versuche zu reparieren, bitte warten Sie..."
'Zugriff auf das Dateisystem eines Computers.
Set fs = CreateObject("Scripting.FileSystemObject")
'Pfad zum alten Verweis holen
OldRefPath = .Item(I).FullPath
'Starte Versuch einer Suche
With Application.FileSearch
.NewSearch
'Dateiname extrahieren
.Filename = fs.GetFileName(OldRefPath)
'Pfad extrahieren
TempPath = fs.GetParentFolderName(OldRefPath)
'Gibt es diesen Ordner?
Do While Not fs.FolderExists(TempPath)
'Nö, eine Ebene höher starten
TempPath = fs.GetParentFolderName(TempPath)
Loop
Set fs = Nothing
'Ist der Pfad "C:\" oder weniger?
If Len(OldRefPath) <= 3 Then
'Pfad nicht vorhanden, vielleicht liegt das Ding bei _
der Application?
TempPath = Application.Path
End If
'Suche nach dem Verweis...
.LookIn = TempPath
'...in den Unterverzeichnissen...
.SearchSubFolders = True
'...und los:
Select Case .Execute
Case 0
'Keine Datei gefunden, Fehlermeldung ausgeben?
'Nächster Verweis
I = I + 1
GoTo NextRef
Case 1
NewRefPath = .FoundFiles(1)
Case Else
'Mehrere Dateien möglich, User auswählen lasssen?
'Nächster Verweis
I = I + 1
GoTo NextRef
End Select
End With
Application.StatusBar = "Datei gefunden, setzte neuen " & _
"Verweis..."
'Diesen Verweis entfernen
.Remove .Item(I)
'Den neuen hinzufügen
.AddFromFile NewRefPath
NextRef:
'Statusbar zurücksetzen
Application.StatusBar = False
Application.DisplayStatusBar = StatusBarState
Else
'Nächster Verweis
I = I + 1
End If
Loop
End With
End Sub
"Andreas Killer" schrieb:
> Die angeh�ngte Routine repariert beim mir VBA-Verweise unter XL2000
>und XL2002 zuverl�ssig.
vielen Dank, kann ich gut gebrauchen!
>> Die angeh�ngte Routine repariert beim mir VBA-Verweise unter XL2000
>>und XL2002 zuverl�ssig.
leider zu fr�h gefreut :-(
wie bei den anderen Routinen auch, erkennt Excel bei einem gebrochenem Verweis
in meinem Fall nicht alle Eigenschaften, so auch die FullPath nicht :-(
Ich kann hier nur die Guid, IsBroken, Major, Minor und den Type ermitteln.
So bleibt mir im Moment nur, den Benutzer auf einen
defekten Verweis hinzuweisen.
> wie bei den anderen Routinen auch, erkennt Excel bei einem gebrochenem
> Verweis
> in meinem Fall nicht alle Eigenschaften, so auch die FullPath nicht :-(
Hmm, interessant. Kannst Du mir mal so ein File (Version vor XL2007
als XLS) zuschicken?
Kannst ja allen Code, Tabellenbl�tter vorher entfernen, der kaputte
Verweis bleibt ja vorhanden.
Andreas.
"Andreas Killer" schrieb:
> Kannst ja allen Code, Tabellenbl�tter vorher entfernen, der kaputte Verweis bleibt ja vorhanden.
Datei ist an dich unterwegs.
Melanie Breden schrieb am 20.10.2009
> wie bei den anderen Routinen auch, erkennt Excel bei einem gebrochenem Verweis
> in meinem Fall nicht alle Eigenschaften, so auch die FullPath nicht :-(
JA, gebrochene Verweise wirken sich auf die unm�glichsten Methoden aus, die
teilweise nichts mit dem eigentlichen Verweis zu tun haben. Sehr beliebt in
diesem Zusammenhang sind die Textfunktionen.
> Ich kann hier nur die Guid, IsBroken, Major, Minor und den Type ermitteln.
>
> So bleibt mir im Moment nur, den Benutzer auf einen
> defekten Verweis hinzuweisen.
Wie w�re es anstelle des harten Verweises denn mit 'late binding'?
Klappt das aus bestimmten Gr�nden nicht?
"Thomas Ramel" schrieb:
>> wie bei den anderen Routinen auch, erkennt Excel bei einem gebrochenem Verweis
>> in meinem Fall nicht alle Eigenschaften, so auch die FullPath nicht :-(
>
> JA, gebrochene Verweise wirken sich auf die unm�glichsten Methoden aus, die
> teilweise nichts mit dem eigentlichen Verweis zu tun haben. Sehr beliebt in
> diesem Zusammenhang sind die Textfunktionen.
in meinem Fall sind nur einige Eigenschaften des defekten Verweises nicht verf�gbar
> Wie w�re es anstelle des harten Verweises denn mit 'late binding'?
> Klappt das aus bestimmten Gr�nden nicht?
Das Problem hat hier Nichts mit early oder late binding zu tun, zumal
ich auch bereits die late binding Variante verwende.
Das Problem liegt IMO an dem Verweis auf den PDFCreator selbst,
denn andere gebrochene Verweise lassen sich ja scheinbar problemlos
aus der Verweis-Auflistung entfernen.
Melanie Breden schrieb am 20.10.2009
> Hallo Thomas,
>
> "Thomas Ramel" schrieb:
>>> wie bei den anderen Routinen auch, erkennt Excel bei einem gebrochenem Verweis
>>> in meinem Fall nicht alle Eigenschaften, so auch die FullPath nicht :-(
>>
>> JA, gebrochene Verweise wirken sich auf die unm�glichsten Methoden aus, die
>> teilweise nichts mit dem eigentlichen Verweis zu tun haben. Sehr beliebt in
>> diesem Zusammenhang sind die Textfunktionen.
>
> in meinem Fall sind nur einige Eigenschaften des defekten Verweises nicht verf�gbar
Das spielt keine Rolle - es reicht wenn eine Eigenschaft nicht verf�gbar
ist, damit das Projekt nicht mehr kompiliert werden kann.
>> Wie w�re es anstelle des harten Verweises denn mit 'late binding'?
>> Klappt das aus bestimmten Gr�nden nicht?
>
> Das Problem hat hier Nichts mit early oder late binding zu tun, zumal
> ich auch bereits die late binding Variante verwende.
Hmmm, wenn es m�glich ist, den PDF-Creator mit late bindig anzusteuern, ist
kein Verweis darauf mehr notwendig.
Das h�ngt aber stark davon ab ob diese Variante von PDF-Creator unterst�tzt
wird. Es gibt Bibliothekten, bei denen dies nicht m�glich ist.
> Das Problem liegt IMO an dem Verweis auf den PDFCreator selbst,
> denn andere gebrochene Verweise lassen sich ja scheinbar problemlos
> aus der Verweis-Auflistung entfernen.
Ja, das ist ein weiteres Problem, das offenbar dem PDF-Creator eigen ist.
> Datei ist an dich unterwegs.
Ich hatte da heute morgen vielleicht eine Eingebung, wenn der Pfad
schrott ist aber die GUID noch da ist, vielleicht kann man dann ja den
Verweise darüber repaprieren?
Hab noch nicht mit Deiner Datei probiert, weil ich keinen PDFCreator
zum Testen hab, könnte aber gehen.
Andreas.
Option Explicit
Function WorkBookProtected(Optional WB As Workbook = Nothing) As _
Boolean
'True wenn das VBA-Project geschützt ist
If WB Is Nothing Then Set WB = ThisWorkbook
WorkBookProtected = WB.VBProject.Protection <> 0
End Function
Function RepairReferences(Optional WB As Workbook = Nothing) As _
Integer
'Prüft alle VBA-Verweise und versucht den Pfad zu reparieren
'Mögliche Rückgabewerte:
' True (-1) wenn alles okay ist
' 0 wenn kein Zugriff auf die Verweise möglich ist
' sonst die Nummer des nicht reparablen VBA-Verweises
Dim fs As Object, I As Integer, J As Integer
Dim OldRefPath As String, NewRefPath As String, TempPath As _
String
Dim OldMajor As Long, OldMinor As Long
Dim StatusBarState As Boolean, AppPathSearched As Boolean
'Fehlerbehandlung etablieren
On Error GoTo ExitPoint
'Welche Mappe?
If WB Is Nothing Then Set WB = ThisWorkbook
'Zugriff auf die Verweise
With WB.VBProject.References
I = 1
'Durchlaufe die Verweise
Do While I <= .Count
'Nummer merken
RepairReferences = I
'Verweis kaputt?
If .Item(I).IsBroken Then
'Statusbar aktivieren
StatusBarState = Application.DisplayStatusBar
Application.DisplayStatusBar = True
Application.StatusBar = "Gebrochener Verweis gefunden, " & _
"versuche zu reparieren, bitte warten Sie..."
AddOverGUID:
'Wenn die GUID hin ist, dann über Pfad einfügen
On Error GoTo AddOverPath
'GUID holen
OldRefPath = .Item(I).GUID
'Haben wir eine gültige GUID?
If Not ValidGUID(OldRefPath) Then GoTo AddOverPath
'Versuche die Versionen auszulesen
On Error Resume Next
OldMajor = .Item(I).Major
OldMinor = .Item(I).Minor
On Error GoTo ExitPoint
'Diesen Verweis entfernen
.Remove .Item(I)
'Wieder hinzufügen
.AddFromGuid OldRefPath, OldMajor, OldMinor
'Nächster Verweis
GoTo NextRef
AddOverPath:
'Wenn ein unerwarteter Fehler raus
On Error GoTo ExitPoint
'Pfad zum alten Verweis holen
OldRefPath = .Item(I).FullPath
'Zugriff auf das Dateisystem eines Computers.
Set fs = CreateObject("Scripting.FileSystemObject")
'Starte Versuch einer Suche
With Application.FileSearch
.NewSearch
'Dateiname extrahieren
.Filename = fs.GetFileName(OldRefPath)
'Pfad extrahieren
TempPath = fs.GetParentFolderName(OldRefPath)
'Gibt es diesen Ordner?
Do While Not fs.FolderExists(TempPath)
'Nö, eine Ebene höher starten
TempPath = fs.GetParentFolderName(TempPath)
Loop
Set fs = Nothing
'Ist der Pfad "C:\" oder weniger?
If Len(OldRefPath) <= 3 Then
'Pfad nicht vorhanden, vielleicht liegt das Ding bei _
der Application?
TempPath = Application.Path
AppPathSearched = True
End If
'Suche nach dem Verweis...
.LookIn = TempPath
'...in den Unterverzeichnissen...
.SearchSubFolders = True
'...und los:
SearchAgain:
Select Case .Execute
Case 0
If Not AppPathSearched Then
.LookIn = Application.Path
AppPathSearched = True
GoTo SearchAgain
Else
'Keine Datei gefunden, Fehlermeldung ausgeben?
Exit Function
End If
'Nächster Verweis
I = I + 1
GoTo NextRef
Case 1
NewRefPath = .FoundFiles(1)
Case Else
'Mehrere Dateien möglich, User auswählen lasssen?
Exit Function
'Nächster Verweis
I = I + 1
GoTo NextRef
End Select
End With
Application.StatusBar = "Datei gefunden, setzte neuen " & _
"Verweis..."
'Diesen Verweis entfernen
.Remove .Item(I)
'Den neuen hinzufügen
.AddFromFile NewRefPath
NextRef:
On Error GoTo ExitPoint
'Statusbar zurücksetzen
Application.StatusBar = False
Application.DisplayStatusBar = StatusBarState
Else
'Nächster Verweis
I = I + 1
End If
Loop
End With
'Alles okay
RepairReferences = True
ExitPoint:
End Function
Private Function ValidGUID(GUID As String) As Boolean
'True wenn die GUID ein gültiges Format hat
ValidGUID = GUID Like "{" & _
"[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]" & _
"[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-" & _
"[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-" & _
"[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-" & _
"[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-" & _
"[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]" & _
"[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]" & _
"[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]}"
End Function
"Thomas Ramel" schrieb
> Hmmm, wenn es m�glich ist, den PDF-Creator mit late bindig anzusteuern, ist
> kein Verweis darauf mehr notwendig.
> Das h�ngt aber stark davon ab ob diese Variante von PDF-Creator unterst�tzt
> wird. Es gibt Bibliothekten, bei denen dies nicht m�glich ist.
da hatte ich wohl einen Gedankendreher...
mein Hinweis auf LateBinding bezog sich zuletzt auf die Referenz-Bibliothek.
Ich habe nun nochmals versucht die Routinen des PDFCreator auf LateBinding
umzustellen was jetzt Gott sei Dank funktioniert.
Der einzige Nachteil dabei ist, dass der Benutzer vor dem Drucken ein Dialogfenster
zur Auswahl des Druckers angezeigt bekommt und den PDFDrucker aktivieren muss.
Dies habe ich jetzt so gel�st, indem ich mir den eingestellten Drucker merke, auf den
PDFCreator umstelle und zum Schlu� wieder den Standarddrucker aktiviere.
"Andreas Killer" schrieb:
> Ich hatte da heute morgen vielleicht eine Eingebung, wenn der Pfad
> schrott ist aber die GUID noch da ist, vielleicht kann man dann ja den
> Verweise dar�ber repaprieren?
da ich jetzt den PDFCreator �ber LateBinding ansteuer, kann auch kein
Verweis mehr verloren gehen und somit ist das L�schen �berfl�ssig geworden.
Trotzdem lieben Dank f�r deine Hilfe :-)
> Hab noch nicht mit Deiner Datei probiert, weil ich keinen PDFCreator
> zum Testen hab, k�nnte aber gehen.
Die aktuelle Version findest du hier:
http://tiny.cc/8cOyk
Public Sub RemoveIfReferenceIsBroken()
Dim myReference As Object
For Each myReference In ThisWorkbook.VBProject.References
If myReference.IsBroken Then
ThisWorkbook.VBProject.References.Remove _
ThisWorkbook.VBProject.References(myReference.Name)
End If
Next
End Sub
Am Wed, 21 Oct 2009 00:11:44 -0700 (PDT) schrieb Andreas Killer:
> Private Function ValidGUID(GUID As String) As Boolean
> 'True wenn die GUID ein g�ltiges Format hat
> ValidGUID = GUID Like "{" & _
> "[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]" & _
> "[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-" & _
> "[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-" & _
> "[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-" & _
> "[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]-" & _
> "[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]" & _
> "[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]" & _
> "[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]}"
> End Function
etwas k�rzer:
Public Function ValidGuid(strGUID As String) As Boolean
ValidGuid = LCase(strGUID) Like _
Replace("{%%%%%%%%-%%%%-%%%%-%%%%-%%%%%%%%%%%%}", _
"%", "[0-9,a-f]")
End Function
Viele Gr��e
Michael
--
http://michael-schwimmer.de
Masterclass Excel VBA ISBN-10: 3827325250
Das Excel-VBA Codebook ISBN-10: 3827324718
Microsoft Office Excel 2007-Programmierung ISBN-10: 3866454139
"Frank Arendt-Theilen" schrieb:
> mit der folgenden Prozedur hatte ich keine Probleme unter XL2007 bei
> meinen Versuchen den gebrochenen Verweis auf den PDFCreator zu
> entfernen:
>
> Public Sub RemoveIfReferenceIsBroken()
> Dim myReference As Object
> For Each myReference In ThisWorkbook.VBProject.References
> If myReference.IsBroken Then
> ThisWorkbook.VBProject.References.Remove _
> ThisWorkbook.VBProject.References(myReference.Name)
> End If
> Next
> End Sub
die Prozedur funktioniert bei mir unter Excel 2003 immer noch nicht:
Laufzeitfehler '-2147319779 (8002801d)':
Die Methode 'Name' f�r das Objekt 'Reference' ist fehlgeschlagen.
Keine Ahnung, was hier falsch l�uft, aber durch die LateBinding-Methode
schlie�e ich k�nftig die defekten Verweise aus!
> etwas k�rzer:
>
> Public Function ValidGuid(strGUID As String) As Boolean
> ValidGuid = LCase(strGUID) Like _
> Replace("{%%%%%%%%-%%%%-%%%%-%%%%-%%%%%%%%%%%%}", _
> "%", "[0-9,a-f]")
> End Function
Jau, das ist schick, danke.
Andreas.
>> Hab noch nicht mit Deiner Datei probiert, weil ich keinen PDFCreator
>> zum Testen hab, k�nnte aber gehen.
> Die aktuelle Version findest du hier:
> http://tiny.cc/8cOyk
Hab ich mir eben mal installiert und siehe da der Verweis ist nun
nicht mehr gebrochen.
Dann mal deinstalliert und versucht den Verweis zu entfernen, keine
Chance, will er einfach nicht. Egal ob ich das mit meiner Routine oder
der von Frank versuche, nix geht. (unter XL2002)
Dann hab ich gekuckt ob sich was �ndert wenn ich das Teil
deinstalliere und den Pfad bei der Installation �ndere, n�, auch jetzt
ist der Verweis i.O. ganz ohne Reparatur.
Tja, ein Entfernen geht problemlos wenn das Teil installiert ist und
auch ein Hinzuf�gen �ber die GUID l�uft wunderbar.
K�nnte es sein das an dem Rechner wo es nicht l�uft was faul ist?
Andreas.
"Andreas Killer" schrieb:
> Hab ich mir eben mal installiert und siehe da der Verweis ist nun nicht mehr gebrochen.
ja, das ist bei mir nach einer Neuinstallation auch so.
> Dann mal deinstalliert und versucht den Verweis zu entfernen, keine Chance, will er einfach nicht. Egal ob ich das mit
> meiner Routine oder der von Frank versuche, nix geht. (unter XL2002)
dito unter XL03
> Tja, ein Entfernen geht problemlos wenn das Teil installiert ist und auch ein Hinzuf�gen �ber die GUID l�uft wunderbar.
yep
> K�nnte es sein das an dem Rechner wo es nicht l�uft was faul ist?
Nein, das denke ich nicht.
Das Problem taucht auf, wenn der Verweis unter XL07 gesetzt wurde und
auf einem anderen Rechner, an dem ebenfalls der PDFCreator installiert ist
mit XL03 ge�ffnet wird, dann ist der Verweis gebrochen.
Meine Idee war nun, den Verweis zu l�schen und neu zu setzen, was ja leider nicht geht.
Aber mit der LateBinding-Methode gehts ja jetzt sehr gut.
Melanie Breden schrieb am 21.10.2009
> "Thomas Ramel" schrieb
>> Hmmm, wenn es m�glich ist, den PDF-Creator mit late bindig anzusteuern, ist
>> kein Verweis darauf mehr notwendig.
>> Das h�ngt aber stark davon ab ob diese Variante von PDF-Creator unterst�tzt
>> wird. Es gibt Bibliothekten, bei denen dies nicht m�glich ist.
>
> da hatte ich wohl einen Gedankendreher...
> mein Hinweis auf LateBinding bezog sich zuletzt auf die Referenz-Bibliothek.
>
> Ich habe nun nochmals versucht die Routinen des PDFCreator auf LateBinding
> umzustellen was jetzt Gott sei Dank funktioniert.
>
> Der einzige Nachteil dabei ist, dass der Benutzer vor dem Drucken ein Dialogfenster
> zur Auswahl des Druckers angezeigt bekommt und den PDFDrucker aktivieren muss.
> Dies habe ich jetzt so gel�st, indem ich mir den eingestellten Drucker merke, auf den
> PDFCreator umstelle und zum Schlu� wieder den Standarddrucker aktiviere.
Na, dann passt das doch recht gut, denke ich - freut mich geholfen zu
haben.