Hallo,
ich habe schon im Forum erfahren, dass es keine Möglichkeit gibt, in einer Zelle den Inhalt des dortigen Kommentares an den Inhalt einer anderen Zelle zu binden.
Deshalb suche ich nach einem Makro, das
Kann mit jd. helfen?
LG
Grüezi ch-ex-laie (?)
ich habe schon im Forum erfahren, dass es keine Möglichkeit
gibt, in einer Zelle den Inhalt des dortigen Kommentares an
den Inhalt einer anderen Zelle zu binden.
…wo genau hast Du das erfahren?
Deshalb suche ich nach einem Makro, das
- bei Änderung einer bestimmten Zelle in einem bestimmten
Tabellenblatt- einen Kommentar neu setzt (oder einen bestehenden
überschreibt) und dabei den Inhalt einer bestimmten Zelle als
Kommentartext einfügt.Kann mit jd. helfen?
Wie wäre es mit der folgenden VBA-Funktion, die Du auch im Tabellenblatt verwenden kannst:
Public Function CommentAdd(Quelle As Variant, rngCommentCell As Range) As Boolean
'© [email protected], 28.08.2007, 23.12.2007
'Fügt einen Kommentar einer beliebigen Zelle hinzu
'das klappt auch aus einer Zelle des Tabelenblattes heraus
On Error GoTo ErrorHandler
With rngCommentCell(1, 1)
If Not .Comment Is Nothing Then
.Comment.Delete
End If
Dim rngZelle As Range
Dim strComment As String
If TypeName(Quelle) = "Range" Then
For Each rngZelle In Quelle
If rngZelle.Text "" Then
If strComment "" Then
strComment = strComment & vbLf & rngZelle.Text
Else
strComment = rngZelle.Text
End If
End If
Next rngZelle
Else
strComment = Quelle
End If
.AddComment strComment
.Comment.Shape.TextFrame.AutoSize = True
CommentAdd = True
End With
Exit Function
ErrorHandler:
CommentAdd = False
End Function
Mit freundlichen Grüssen
Thomas Ramel
–
OT Nachfrage zu CommentAdd
Grüezi Thomas,
Public Function CommentAdd(Quelle As Variant,
rngCommentCell As Range) As Boolean
'© [email protected], 28.08.2007, 23.12.2007
'Fügt einen Kommentar einer beliebigen Zelle hinzu
'das klappt auch aus einer Zelle des Tabelenblattes herausOn Error GoTo ErrorHandler
With rngCommentCell(1, 1)
If Not .Comment Is Nothing Then
.Comment.Delete
End If
Dim rngZelle As Range
Dim strComment As String
„füher“ habe ich gelegentlich in der Meinung dadurch den Code zu beschleunigen bestimmte Dim-Anweisungen in Z.B. eine If-Schleife gelegt o.ä.
Erst seit relativ kurzer Zeit weiß ich daß dies Blödsinn ist. Wenn der Code der Prozedur kompiliert wird, so werden anfangs alle Dim Anweisungen eingelesen/kompiliert, egal wo sie im Code stehen.
Seitdem schreibe ich alle Dim-Anweisungen zuoberst, dann ggfs kommen die Wertzuweisungen an die Variablen, dann kommt der eigentliche Code.
Nun sehe ich bei deinem Code daß du die Dim-Anweisungen erst später in den Codeablauf schreibst.
Jetzt meine Frage, hat das Gründe die ich nihct kenne?
Und, analog zur ungarischen Notation zu Präfixen für Variablennamen, gibt es da „ungeschriebene“ Gesetze, letztlich kann ja Jeder machen was er will, haben sich da Vorgaben herauskristallisiert wodran sich viele halten. Also in welcher Reihenfolge ich anfangs einer Prozedur etwas schreibe.
Zum Bleistift, schreibt man das so:
Sub x()
Dim Urschrei As Jodler '
))
Urschrei=„c:\Kishon\Jodler.wav“
Application.ScreenUpdating=False
…
Oder so:
Sub x()
Dim Urschrei As Jodler '))
Application.ScreenUpdating=False
Urschrei=„c:\Kishon\Jodler.wav“
…
Und wenn es keine „Übereinkünfte“ dazu gibt, wie machst da das normalerweise?
PS: **ist kürzer als
Danke ^ Gruß
Reinhard**
Grüezi Reinhard
„füher“ habe ich gelegentlich in der Meinung dadurch den Code
zu beschleunigen bestimmte Dim-Anweisungen in Z.B. eine
If-Schleife gelegt o.ä.
Erst seit relativ kurzer Zeit weiß ich daß dies Blödsinn ist.
Wenn der Code der Prozedur kompiliert wird, so werden anfangs
alle Dim Anweisungen eingelesen/kompiliert,
egal wo sie im Code stehen.
Ja, eigentlich hast Du da recht
Seitdem schreibe ich alle Dim-Anweisungen zuoberst, dann ggfs
kommen die Wertzuweisungen an die Variablen, dann kommt der
eigentliche Code.
…und auch das macht durchaus Sinn.
Nun sehe ich bei deinem Code daß du die Dim-Anweisungen erst
später in den Codeablauf schreibst.Jetzt meine Frage, hat das Gründe die ich nihct kenne?
Nö, reine Tagesform und nach Lust und Laune.
Vermutlich erschien mir das logischer, als ich den Code geschrieben habe.
Und, analog zur ungarischen Notation zu Präfixen für
Variablennamen, gibt es da „ungeschriebene“ Gesetze, letztlich
kann ja Jeder machen was er will, haben sich da Vorgaben
herauskristallisiert wodran sich viele halten. Also in welcher
Reihenfolge ich anfangs einer Prozedur etwas schreibe.
Nein, da gibt es IMO keine Vorgaben. Wie gesagt kommt das bei mir immer im Laufe des Codes zustande.
Bei sehr langen Code kann es Sinn machen, wenn die Deklarationen im Block gemacht werden in welchem die Variablen letztlich auch Verwendung finden. Ich mag dann nicht ganz nach oben springen um die Variable zu deklarieren und dann wieder zurück um sie einzusetzen. In diesen Fällen scheint es für mich ‚logischer‘ zu sein, sie später zu deklarieren.
Das mag auch bei den obigen Zeilen Pate gestanden haben.
Sub x()
Dim Urschrei As Jodler '
Urschrei=„c:\Kishon\Jodler.wav“
Application.ScreenUpdating=False
…Oder so:
Sub x()
Dim Urschrei As Jodler '
Application.ScreenUpdating=False
Urschrei=„c:\Kishon\Jodler.wav“
…Und wenn es keine „Übereinkünfte“ dazu gibt, wie machst da das
normalerweise?
Eben, ganz so wie man möchte - das ist wohl persönlicher Stil, der sich in solchen Unterschieden dann herausschält.
PS:
Bei mir jodelt dein Code leider nicht… 
PS: ist kürzer als
Oh, stimmt eigentlich - Danke für den Hinweis, dann (auch) ich bin ja prinzipiell schreibfaul.
Mit freundlichen Grüssen
Thomas Ramel
–