SoftMaker.de

• Statuszeile BM: Anzeige aktueller Spaltennr. ist unabhängig vom Caret immer 1 wenn die Zeile mit TAB beginnt.
• Die Function im folgenden Skript (- Exzerpt) produziert einen "Type mismatch". Ich komm einfach nicht dahinter...
  
  Code:
  Sub Main
     Dim pm as Object
     Set pm = CreateObject("PlanMaker.Application")
     Dim subStr$, cllAddr$, cllName$, shtName$
     cllAddr = "Steuer!J12"
     shtName = Left(cllAddr, InStr(1, cllAddr, "!"))
     cllName = Right(cllAddr, Len(cllAddr) - Len(shtName))
     subStr = FormatReference (shtName & cllName)
     Set pm = Nothing
  End Sub
  
  Function FormatReference (referedCell$) As String
     Print "FormatReference: referedCell=", referedCell
     Dim lnkRange As Object
     Set lnkRange = pm.Range(referedCell)
     ' formatStr = bla bla bla
     ' FormatReference = """&TEXT(" & referedCell & ";" & formatStr & ")&"""
     Set lnkRange = Nothing
  End Function

Danke!

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Hallo Hoffie,

schön dass es dich doch noch gibt.

Ich habe dein Script getestet, bekomme nur die Meldung "Programm erfolgreich abgeschlossen", wenn ich "Sub main" und "End Sub" auskommentiere, wenn ich aber "main" aufrufe, bekomme ich auch deine Fehlermeldung. Irgendwie muss es mit "referedCell" zusammenhängen, wenn ich nämlich die Zeile mit "Print" auskommentiere, kommt die Fehlermeldung mit der Zeile "SET".

Das einmal als Hinweis, mir fehlt jetzt leider die Zeit zum ausführlichen testen.

Das find' ich auch , wenn auch leider mit wenig Zeit für SMO lately.

Seltsam: Wenn ich "Sub Main" und "End Sub", ODER die "Print" - Zeile auskommentiere, tritt der Fehler in der "Set lnkRange" - Zeile auf. Sonst schon beim Print - Befehl.

"Programm erfolgreich abgeschlossen" scheint bei mir ausgeschlossen.

Seltsam seltsam...

Danke Dewes!

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Ich habe mal folgendes gemacht


Dann läuft das Script ohne Fehlermeldung. Ich kenne nicht deine Gründe, warum du "cllAddr" aufteilst.

Bei der Übergabe an die Function mit "(shtName & cllName)" scheint es irgendein Problem zu geben.

Ich hab den Fehler gefunden, aber ... Oh La La kommt mir über die Lippen!

Du hast mir den Anfang bereitet zum herum zu probieren. Hab Deinen Vorschlag eingebaut (nur die 3. Zeile davon - reicht ja) - und was passiert? Typ-Fehler bei "Set lnkRange". Und warum? Weil ich die "Print" - Zeile auskommentiert hatte! Denn als ich die reaktivierte, wurde das Programm erfolgreich abgeschlossen. Ahem... Ein "Print referedCell" scheint den Typfehler bei dem folgendem "Set lnkRange = pm.Range(referedCell)" auszumerzen...!?

Das Schärfste daran: Die Tabelle "Steuer", auf der die Zelle "Steuer!J12" sich befindet, existierte gar nicht im offenen PM-Dokument. *stöhn* - naja, egal. Im originalen Skript passierten all diese Ungereimtheiten nicht, also habe ich darin weiterprobiert mit Deiner Idee. Ich habe das Zusammenfügen von Blattname und Zelladresse in die Funktion verlegt, zunächst ohne Erfolg:


Du hattest recht - es lag irgendwie am "referedCell"

Also:
"pm.Range(Zellbereich$)" kann keine Angabe vom Arbeitsblatt in "Zellbereich$" verarbeiten. Es geht nur so:
"pm.ActiveWorkbook.Sheets(BlattName$).Range(Zellbereich$)", wobei in "Zellbereich$" kein Blattname stehen darf.

Deine berechtigte Frage warum ich die Zelladresse aufteile hat spätestens jetzt eine Antwort bekommen
Im Ernst: Ich muss im Skript auch Zellbereiche verarbeiten. Z.B. für den Bereich "Steuer!J12:J25" muss ich "Steuer!" puffern, um die Funktion separat für "Steuer!J12" und "Steuer!J25" aufzurufen. Das Skript kopiert eine Formel in eine Nachbarzelle, wobei die Formel in ganzer Länge als Textformel erscheint. Die Verweise auf Zahlen darin bleiben erhalten, und die Zahlenformate werden in Text nachgebildet. Das verwende ich um für den Empfänger meines PM-Dokuments eine Berechnung nachvollziehbar zu machen. Ich habe es in 2008 hier gepostet. CreateStringFormula.bas in neuester Version ist hier angehängt, mit Symbol.

@Softmaker:
Obiges in Fett könnte gelegentlich in die Hilfe aufgenommen werden. Und, man beachte den (unwesentlichen) Fehler in BM in Zeile 1 im obersten Post hier.

NACHTRAG: Mit "Empfänger meines PM-Dokuments" meinte ich eigentlich den Empfänger eines Ausdrucks oder eines pdf-Exportes davon. Im Dokument selbst kann man ja relativ leicht eine Formel nachvollziehen. Dennoch ist das Skript auch sehr nützlich um sofort und übersichtlich eine Kontrolle der Eingangswerte einer Formel zu haben.

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Hatte endlich mal die Zeit, dein Script zu testen.

Fehlermeldung: "Error in line: 386 - Invalid procedure call or argument"

Wenn ich die Zeile ersetze durch


funktioniert es, mit einem Schönheitsfehler, siehe Anhang Zeile "B3" bzw. "A3"

Super, Dewes, ich danke Dir!

Den Fehler in Zeile 386 hab ich korrigiert (in obigem Download). Hatte ja gerade ermöglicht, dass eine Zelle, auf die in der Formel verwiesen wird, auf einem anderen Arbeitsblatt stehen kann. Ich hatte dabei Zellen auf demselben (aktiven) Blatt (der wesentlich häufigere Fall) vergessen. Jetzt geht beides.

Den Schönheitsfehler erkenne ich nicht, bräuchte dazu Nachhilfe. Falls es aber dieser ist: Es ist Absicht, dass die oben oder links plazierte Textformel rechtsbündig ist. Das ergibt eine bessere Ausrichtung zur Formelzelle, vor allem bei langen Formeln.

Du hast schlauer Weise auch =Summe(...) getestet. Eine unüberwindbare Schwäche ist die Textumwandlung von Funktionen, die Zellbereiche als Argumente haben. Das lässt sich nicht besser machen, denn die Bereiche könnten ja riesig sein. Dieser Fall ist zwar selten, aber wenn es darauf ankommt, muss man halt die Textformel per Hand nacharbeiten, z.B. den Zellbereich (von: x bix: Y) mit einem Namen ersetzen.

Was interessanterweise auch zutage trat ist, dass das von Excel abgeschaute Zahlenformat "Standard" eine haarstäubend unlogische Sache ist. Sie lässt sich nur mit immensem Aufwand und nur größtenteils in der Textformel nachbilden und hat nur ganz geringe Vorteile. Typisch amerikanisches Denken, von hinten durch die Brust. Für mich gehört eine unformatierte Zahl mit spaltenfüllenden Vor- bzw. Nachkommastellen abgebildet. Und wenn die Spaltenbreite es erfordert, wird halt in exponentieller Schreibweise angezeigt. Dann, und wirklich nur dann, ist die Zahl in fast jeder Zellenbreite auch zu sehen. Nur dann gibt es extrem selten den Fall "*****", bei dem man ja gar nicht entscheiden kann wie man die Zahl sinnvoll formatiert.

Gruß und Danke nochmal!

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Mit Schönheitsfehler meinte ich nicht die rechtsbündige Ausrichtung, sondern dass das Gleichheitszeichen "=" am Schluss der Formelausgabe auftaucht und nicht am Anfang, das kann unbedarfte Anwender verwirren.

Die Ausrichtung und Lage des "=" hängen zusammen. Rechtsbündig bedingt ein "F(x,y,z) =", linksbündig ein "= F(x,y,z)". Spätestens bei einer längeren Formel wird deutlich, dass so das Gleichheitszeichen näher am Ergebnis bzw. der Formelzelle steht. Es hat sich bewährt. Auf dem Dialog zur Lage steht ein Satz zur Ausrichtung.

Zum Fehler noch etwas:
Im Skript hab ich ein Kommentar entdeckt in der Funktion "ResolveNamedRange". Dort musste ich feststellen, dass Set rangeObject = pm.ActiveWorkbook.Range(rangeName$) auch bei benannten Bereichen nur auf dem aktiven Arbeitsblatt funktioniert. Das ist natürlich besonders fatal, weil der Blattname unbekannt und nicht ermittelbar ist. Um das Zahlenformat des Bereichs auszulesen musste ich diese Funktion schreiben mit einer OnError Schleife durch alle Arbeitsblätter. Eine haarsträubende Krücke, nicht? Da ist das PM Objektmodell noch nicht ganz fertig.

Mensch Meier, ich hab das Skript in 1988 "erfunden" als Makro in Lotus 1-2-3 für MS-DOS. Danach hab ich es überalhin portiert denn es ist sicherlich das meist benutzte Skript von mir, ich kann gar nicht mehr ohne.

Danke für Deine Hilfe, Dewes!

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original