---

Hallo,

weiß jemand zufällig was der Laufzeitfehler 35010 ist? Dieser kommt sporadisch. Ich kann nicht mal nachvollziehen wann und wo. Kommt bei einem Wechsel in ein SUB. Die Stoppmarke im SUB wird nicht mehr erreicht. Mir ist nur mit Hilfe des Internets und Beobachtungen aufgefallen, das Makro kann wohl einen dynamischen Speicher nicht erzeugen. Starte ich das Makro einmal gleich bei Arbeitsbeginn kommt der Fehler nie. Während der Arbeit ist es Zufall. Auch dauert der erste Start länger. Ich weiß auch nicht ob die Excel- oder die SW-Routinen den Fehler erzeugen. Ich starte im Hintergrund Excel.

Ich kann nicht mal den Fehler mit "on error goto" abfangen. Wollte eine MsgBox dann bringen: "Bitte SW neu starten."

Das SUB läd Timerfunktionen aus der User32.dll. Aber Fensterfunktionen aus der User32.dll sind schon geladen.

Viele Grüße
Andreas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo

Gibt es eine Möglichkeit ein Makro zu Beginn der SolidWorks-Sitzung automatisch zu starten? Das mit: "-m "c:\Pfad\Makro.swp"" funktioniert nicht.

Der Laufzeitfehler wird vom VBA Compiler direkt erzeugt, nicht vom Makro. Deshalb kann ich diesen auch nicht mit einer Fehlerbehandlung abfangen und die MsgBox sieht bei der Fehlermeldung auch anders aus.

Der VBA Generator in SW arbeitet, wie ein Programmierer mir sagte, "on demand" Das Projekt liegt uncompelliert vor. Und wird nach Bedarf als Maschinencode erzeugt. Jetzt rufe ich die SUB auf, der Compiler schreibt seinen Maschinencode. Und da gibt es einen Stack Overflow. Der Stapelspeicher ist ein schneller Speicher aber begrenzt. Mit VBA- Mitteln nicht vergrößerbar.

Mit denm Zusatz "static" kann ich ganze Routinen in einen anderen, fast unbegrenzten Speicher laden. Dann kommt die Fehlermeldung beim Compellieren der main(). Und diese bekomme ich nicht in den anderen Speicher. (probiert)

Wenn SW frisch gestartet ist, ist der Stack wohl leer. Dann kann das Makro compeliert werden und bleibt dann im Speicher. Wie SW selbst einen Stack Overflow verhindert weiß ich nicht. Aber VBA ist wohl nicht berücksichtigt. Je mehr mit SW gemacht wurde, desto wahrscheinlicher kommt der Fehler beim Erststart des Makros.

Oder gibt es eine Möglichkeit das Makro einmal zu compellieren und verlinken und dann so abzuspeichern?

[Diese Nachricht wurde von KSAH am 01. Aug. 2023 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

vaaendwinsys.png

Hallo,

als bei mir funktionierte das Starten von SWX mit Macro mit der erweiterung "-m "Pfad zum Macro"" immer einwandfrei.

Ich hab zu dem Fehler nur gefunden das der "Virtuelle Arbeitsspeicher" überläuft, das liegt daran das Windows den Standardmäßig automatisch festlegt und da kommt Windows in manchen Fällen nicht schnell genug hinterher, du könntest mal versuchen hier mehr und fest einzustellen? Windows -> System -> Erweiterte Systemeinstellungen -> Erweitert -> Leistung / Einstellungen... -> Erweitert -> Virtueller Arbeitsspeicher.

Gruß
Bernd

------------------
--- Man muß nicht alles wissen, man muß nur wissen wo es steht ---

Staatlich anerkannte Deutschniete 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Servus,

ich weiß das mit dem virtuellen Speicher. Wenn ich das Makro weitergebe, muss es aber auch funktionieren.

Das Problem ist halt der Stapelspeicher füllt sich halt.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Servus,

scheinbar eine Lösung gefunden. Zumindest kann ich den Fehler nicht mehr reproduzieren, auch wenn ich den Speicher meines PC mit SW-Daten vollknalle.

über ein zweites kleines Makro rufe ich über RunMacro2 das eigentliche Makro auf. Diese Funktion kann das Makro sogar wieder entladen und es hat als Fehlermeldungen: "OutOfMemory" oder "Overflow". Die sind bisher auch nicht gekommen. Dafür ständig die Meldung, mein System wäre kritisch.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP