Excel 365: VBA-Aufruf RowHeight sehr langsam

Hallo Christian,

schau mal hier rein:

https://docs.microsoft.com/de-de/office/vba/exc...

Wenn deine Mappe sehr berechnungsintensiv ist und dadurch langsam wird, solltest du vielleicht mit VBA berechnen lassen.

Claus

Danke, das war mir schon bewusst. Ich dachte bei der Performance ohnehin an schnelleres Rechnen in Excel und VBA. Da ist Excel leider recht langsam geworden. Besonders wenn man recht viel mit Matrix-Formeln arbeitet. Da es sich bei diesem Problem aber
um meinen Privat-PC handelt, ist es - wie gesagt - kein Problem. Im Büro habe ich eine andere "Maschine" ;-)

Hallo IlirU,

genau so hatte ich es.

Das Problem ist nur, dass meine Excel Datei ziemlich groß ist und auch VBA Code verwendet wird.

Dieser wird extrem langsam, wenn ich das ganze mit Matrixformel löse.

Daher hätte ich es lieber wenn möglich mit einer Pivottabelle gelöst.

Trotzdem vielen Dank für deine Hilfe!

Grüße

Elli

Hallo,

kannst du die Hilfe nicht aus VBA heraus aufrufen, um direkt die VBA-Hilfe zu bekommen?

Habe kein Office für Mac und kann es daher nicht selber testen.

Claus

maninweb schrieb am 03.08.2010 09:57 Uhr:

Erste Excel Instanz legt zum Beispiel zweite an. Aus der zweiten, schreibst Du, soll auf eine Prozedur der ersten Instanz zugegriffen werden. Das hieße, in der ersten Instanz müsste eine Mappe offen sein, die diese Prozedur (ich gehe jetzt von VBA
aus) zur Verfügung stellt. Die zweite Instanz müsste, damit diese auf die erste per Code zugreifen kann, ebenfalls Code aufrufen, der dann auch wiederum in einer Mappe ggf. Add-In der zweiten Instanz liegen muss; also auch eine Mappe in der zweiten offen sein
müsste.

Genau so. Das Problem ist eben, dass ich in der zweiten Instanz keinen fertigen Code habe, den ich ausführen könnte. Und wie ich gestern schon schrieb, kann ich ihn auch nicht dynamisch erzeugen, weil auf den Zielrechnern dem Zugriff auf das VBA-Projekt
nicht vertraut wird. Somit ist das einzige was ich von der zweiten Instanz habe, eine Variable "app":

Set app = CreateObject("Excel.Application")

Darüber muss alles laufen. Führe ich aber z.B. app.Run aus mit dem Namen des aktiven Workbooks und der Prozedur der ersten Instanz, so wird nicht etwa die Prozedur der ersten Instanz aufgerufen, sondern innerhalb der zweiten Instanz eine Kopie des Workbook
(schreibgeschützt) geöffnet und alle Änderungen dort durchgeführt. Das ist zwar absolut logisch, aber eben nicht das was ich brauche.

Peter

P.S.: Bisher behelfe ich mir mit einem dynamisch generierten VB-Script, dem ich den Namen der aufzurufenden Prozedur und ggf. weiter Argumente übergebe. Das Script holt sich dann die Excel-Instanz und startet mit .Run die Prozedur inkl. Weitergabe der übergebene
Werte. Das klappt, ist aber sehr langsam, weil immer wieder wscript.exe aufgerufen werden muss.

Darum dachte ich daran, eine zweite Excel-Instanz dauerhaft im Speicher zu halten und den externen Aufruf darüber abzuwickeln. Leider kriege ich das nicht hin.