---

Hallo zusammen,

wir stellen in Zukunft auf ein neues Schriftkopf- und Freigabesystem um, das quasi alles aus IProperties zieht die im Laufe eines Bauteillebens so mehr oder weniger automatisch befüllt werden.

Dazu sind 2 Dinge nötig:
- Ich muss bei alten Dokumenten die neuen benutzerdefinierten iProperties (rund 40 Stück) irgendwoher holen
- Ebenso muss ich für einige Schritte im Prozess (z.B. Auswahl neuer Status, Qualitätseinstufung) die Auswahlwerte für die InputListboxen holen

Bisher wird beides über Excellisten realisiert in denen alle benötigten Properties, sowie die Werte für die Arraylisten hinterlegt sind.

Hat natürlich den Vorteil, dass ich das relativ einfach in einer Datei händeln kann und z.B. bei der zukünftig geplanten Erweiterung des Systems auf eine "extended-Version" des neuen Schriftkopfes nur dort anpassen muss.

Nachteil ist, dass die Excelverknüpfung wahnsinnig langsam ist ... einmal beim Aktualisieren aller Properties 20 Sekunden zu warten ist ja noch akzeptabel, aber bei jeder Erstfreigabe entweder die gleiche Zeit zu warten bis alle Arrays geladen sind oder vor der Anwahl des einzelnen Properties jeweils eine kurze Verzögerung zu haben ist einfach nervig und wird nicht zur Akzeptanz beitragen.

Daher nun die Frage gibt es eine andere schnellere Möglichkeit (entweder im Inventor intern oder über Zugriff auf eine externe Liste) diese Sachen zu holen.

Als Beispiel noch 2 Codeschnipsel (zum GoTo dann noch ein eigener Faden):

Holen der IProperties:

Dim Propertyliste As String
Dim i As Integer
Dim Anzahl As Integer
oCustompropertyset = ThisDoc.Document.PropertySets.Item("Inventor User Defined Properties")
i = 2
Suchproperty :
If Not GoExcel.CellValue("H:\[...]Propertyliste.xlsx", "Propertyliste_Auto", "A" & i) = ""
Try
Propertyliste = GoExcel.CellValue("H:\[...]Propertyliste.xlsx", "Propertyliste_Auto", "Propertyliste_Auto", "A" & i)
oCustompropertyset.Add("", Propertyliste)
i = i + 1
GoTo Suchproperty
Catch
i = i + 1
GoTo Suchproperty
End Try
End If

Wählen der Qualitätseinstufung:

Case xCostCenter
Dim Qualität As New ArrayList
i = 2
Suchqualität:
If Not GoExcel.CellValue("H:\[...]Propertyliste.xlsx", "Arrayliste", "B" & i) = ""
Qualität.Add(GoExcel.CellValue("H:\[...]Propertyliste.xlsx", "Arrayliste", "B" & i))
i = i + 1
GoTo Suchqualität
End If
iProperties.Value("Project", "Cost Center") = InputListBox("Aktuelle Auswahl: " & iProperties.Value("Project", "Cost Center"), _
Qualität, "", Title := "Qualitätseinstufung", ListName := "Wählen sie die Qualitätseinstufung")
GoTo Liste

Vielen Lieben Dank schon einmal für eure Tipps!

------------------
FÌr jede Fehlermeldung gibt es eine Lösung

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

---

zuerst sollten die mehrfachen Aufrufe, um den Inhalt einer Zelle zu lesen, weg. Besser den Zelleninhalt in eine Variable speichern, dann die Prüfung etc.

Code:

---

If Not GoExcel.CellValue("H:\[...]Propertyliste.xlsx", "Propertyliste_Auto", "A" & i) = ""
Try
Propertyliste = GoExcel.CellValue("H:\[...]Propertyliste.xlsx", "Propertyliste_Auto", "Propertyliste_Auto", "A" & i)

---

besser:

Code:

---

Propertyliste = GoExcel.CellValue("H:\[...]Propertyliste.xlsx", "Propertyliste_Auto", "Propertyliste_Auto", "A" & i)
If Not Propertyliste = ""
Try

---

BTW. da fehlt doch das "Then" (If bedingung Then )

------------------
Gruß KraBBy

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

---

Deinen Code muss ich mir selbst nochmal ansehen - gerade am Handy kann ich mir die Funktion nicht so richtig vorstellen.

Bezugnehmend auf den Beitrag von dir im anderen Faden hier noch eine Idee die mir kam.

Bitte die Formatierung entschuldigen - ich hoffe man versteht was ich meine:

Dim Propertyliste as New Array List
i = 2 (Startzeile)
Do While Not Excelzelle "A" & i = ""
Propertyliste.add Excelzelle
I = i+1
Loop

For j = 2 to i
Try
Propertyset hinzufügen Propertyliste(i)
Catch
End Try

Wäre das lauffähig und vor allem schneller?

------------------
FÌr jede Fehlermeldung gibt es eine Lösung

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

---

Wenn ich deinen Gedanken richtig interpretiere, dann macht es kaum einen Unterschied. Es dürfte egal sein, ob das Lesen aus Excel und iProp-Erstellung in 1 oder 2 Schleifen erfolgt (vielleicht im Detail sogar nachteilig, weil etwas overhead für jede Schleife nötig ist).
Du gehst ja selbst davon aus, dass die Schnittstelle zu Excel die Bremse ist. Demnach ist es ein Vorteil, die Zugriffe darauf auf das nötigste zu begrenzen.

Also dann evtl so:

Code:

---

i=2
tmp = goExcel.blabla(..., "A" & i)
Do Until "" = tmp
  Try
    PropSet.Add (..., tmp)
  EndTry
  i+=1
  tmp = goExcel.blabla(..., A & i)
Loop

---

Da gibt es die Zeile mit goEcxel zusätzlich vor dem Do.

Ein andere Ansatz evtl hier zu finden: Funktionen für Excel-Datenverknüpfungen
GoExcel.CellValues() liest mehrere untereinander stehende Zellen.
Ich könnte mir vorstellen, dass das "optimiert" ist und schneller läuft als selbst die Zellen einzeln zu lesen.

Dort steht auch, dass der zweite Aufruf von goExcel.CellValue() keine Angabe von Datei und Tabellenblatt braucht. Keine Ahnung ob das einen Unterschied macht. Im schlimmsten Fall führt die Angabe dazu, die Datei neu zu öffnen.

Und noch ein Gedanke: die exceldatei liegt auf Laufwerk H:. Ist vmtl ein netzlaufwerk. Macht es einen Unterschied in der Geschwindigkeit, wenn die Datei lokal liegt?

------------------
Gruß KraBBy

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

---

Ich habe deinen Gedanken jetzt mal weiterverfolgt und zumindest bei dem "großen" Part bringt das einen signifikanten Zeitgewinn von ca. 30 auf knappe 5 Sekunden also würde ich sagen Mission Accomplished und herzlichen Dank!

------------------
FÌr jede Fehlermeldung gibt es eine Lösung

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

---

Hallo

Excel für das Speichern der Werte zu nutzen ist nicht ideal. Ändern sich die Werte so häufig, das man die auslagern muss? Hart codiert wäre es definitiv scnhneller. Eine halbwegs verständliche Doku dazu und die Pflege ist einfacher als in ein paar Jahren z.B. das Netzlaufwerk samt Pfad sicher zu stellen.
Wenn es denn unbedingt sein muss, noch eine paar Idee dazu:

Die PropertySets sind für jedes Dokument die gleichen. Beim ersten Dokument die Namen und Werte in eine globale Variable/Array/NameValueList speichern und in allen weiteren Dokumenten erst schauen ob die globale Variable/Array/NameValueList existiert. Nur wenn das nicht existiert, aus der Exceldatei holen. Globale Variablen bestehen, solange sie nicht zerstört werden, für die Dauer der Inventorsitzung.

@KraBBy
Ich meine das GoExcel.NameRangeValue zwar die Möglichkeit bietet einen benannten Bereich in Excel mit seinem Namen anzusprechen, ABER der Bereich darf nur aus einer einzigen Zelle bestehen.
Für das Einlesen eines Zellranges in ein Array oder eine NameValueList in einem Rutsch, müßte man die Excel-API nutzen.

Generell könnte man, wenn nur Daten aus Excel ausgelesen werden, auch mal die aktive Excel engine kontrollieren. Die für diesen Fall ausreichende LibXL ist schneller und sollte aktiviert sein. Müssen Zellwerte neu berechnet werden usw. muss die COM Variante aktiviert werden. Diese startet im Hintergrund ein volles Excel. Das dauert dann aber zu Beginn entsprechend länger.

------------------
MfG
Ralf

RKW Solutions GmbH
www.RKW-Solutions.com

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

---

Zitat:

---

Original erstellt von rkauskh:
Beim ersten Dokument die Namen und Werte in eine globale Variable/Array/NameValueList speichern und in allen weiteren Dokumenten erst schauen ob die globale Variable/Array/NameValueList existiert. Nur wenn das nicht existiert, aus der Exceldatei holen. Globale Variablen bestehen, solange sie nicht zerstört werden, für die Dauer der Inventorsitzung.

---

Wie geht das genau (globale Variable, die ihren Wert behält)? Sicher, dass das mit iLogic geht?

Zitat:

---

@KraBBy
Ich meine das GoExcel.NameRangeValue zwar die Möglichkeit bietet einen benannten Bereich in Excel mit seinem Namen anzusprechen, ABER der Bereich darf nur aus einer einzigen Zelle bestehen.
Für das Einlesen eines Zellranges in ein Array oder eine NameValueList in einem Rutsch, müßte man die Excel-API nutzen.

---

Ich habe von GoExcel.CellValues() geschrieben. Hab es auch ausprobiert, ist aber ohne zeitlichen Vorteil. s.u.

Heute habe ich einen kleinen Versuch aufgesetzt, um 40 Zellen Excelinhalt zu lesen:
- COM
- GoExcel.CellValue OHNE Angabe von Datei und Tabellenblatt
- GoExcel.CellValue MIT Angabe von Datei und Tabellenblatt
- GoExcel.CellValues
In absteigender Laufzeit (es waren rund 1,6 / 0,5 / 0,3 / 0,3 s).
Die COM-Schnittstelle habe ich vielleicht nicht ganz fair behandelt, weil der erste Aufruf von GoExcel etwas länger dauert und ich das bei dessen Zeitmessung ausgenommen habe. So eine Berücksichtigung habe ich bei COM nicht gemacht.

------------------
Gruß KraBBy

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

---

Noch eine Erkenntnis aus meinen Versuchen. Aus einer (lokalen) Textdatei zu lesen geht sehr schnell.

Code:

---

Dim sArray() As String
sArray = System.IO.File.ReadAllLines("C:\TEMP\iPropTest_A.txt")
'jede Zeile der Datei wird ein Element des Array
'dauert ca 1 ms

Dim sTxt As String = ""
For Each el As String In sArray
   sTxt &= el & vbCrLf
   'als Beispiel, wie man wieder an die einzelnen Texte dran kommt
Next

---

Ich glaube, das wäre meine favorisierte Herangehensweise. Dafür sorgen, dass diese Informationen lokal in mehreren txt liegen. Diese werden dann von der Regel gelesen.
Ob man die lokale Erstellung der txt auch von der Regel machen lässt, hängt davon ab, ob man evtl. schon was zur Verteilung von Dateien auf die Clients hat (bestehendes Anmelde-Skript oder so). Was eben einfacher handhabbar erscheint. Im Fall der Regel, müsste man eine Logik entwerfen, die prüft, ob die xl auf dem Server aktueller ist, als die lokalen txt. Nur dann die xl liest und txt erstellt bzw. aktualisiert.

------------------
Gruß KraBBy

[Diese Nachricht wurde von KraBBy am 18. Jul. 2022 editiert.]

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

---

Auch hier noch einmal herzlichen Dank für eure Antworten!

Grundlegend würde ich schon gerne bei dem Lesen aus einem externen Dokument bleiben.

Die neuen IProperties werden zwar nur einmal gelesen (zmd. solange man auf der aktuellen Schriftkopfversion ist), da könnte ich mir durchaus vorstellen, dass man die hart codiert abruft. Da wird sich vermutlich auch nur noch einmal bei der Umstellung von der jetzigen Variante auf die Variante ERP-System gröber was ändern müssen.

Bezüglich dem Ansatz mit der NameValueList komme ich gerade nicht ganz mit bin mir aber auch nicht sicher ob wir uns richtig verstanden haben. Es geht bei diesem "Propertyholen" nicht um hunderte Dokumente die auf einmal den neuen Schriftkopf erhalten, sondern grundsätzlich bleibt alles was einmal freigegeben wurde beim alten Schriftkopf (ich würde mal sagen unsere Standardteile belaufen sich auf maximal 5% aller Teile). Nur wenn wirklich mal an einem dieser Teile eine Revision gemacht wird, wird dieses auch den neuen Schriftkopf erhalten.
Anders kann das natürlich in Zukunft einmal aussehen, wenn wir eben irgendwann (also vermutlich 2050 oder so         ) mal ein ERP-System haben. Dann wäre es gut, wenn alles was irgendwann villeicht nochmal gefertigt wird auf dem gleichen Stand ist, wobei auch dann m.E. nicht zwingend, da die zusätzlichen Properties keine absolut Konstruktionsrelevanten Informationen enthalten die nicht schon vorhanden sind, sondern nur zusätzliche Infos z.B. Einbauorte für den Monteur, Oberflächenbehandlung zusätzlich zu auf der Zeichnung im Property vermerkt etc. - Also alles Sachen die jetzt auch schon da sind nur halt als "dumme Texte"

Anders könnte

Die ganzen Arraylisten für das Ausfüllen der Properties brauche ich aber in 5 verschiedenen Regeln die ich dann separat pflegen müsste. Hier würde ich eigentlich schon recht gerne dabei bleiben, denn aus Erfahrung ändern sich die Sachen oft (z.B. kommen öfters mal neue "Einbauorte" hinzu).

Jedenfalls vielen vielen Dank für die Mühe. Ich hänge nun ein paar Tage hauptsächlich an etwas anderem etwas fest werde aber dann eure Ideen probieren und Rückmeldung geben!

------------------
FÌr jede Fehlermeldung gibt es eine Lösung

[Diese Nachricht wurde von chense am 18. Jul. 2022 editiert.]

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

---

Moin

Sorry, mit den GoExcel.NameRangeValue war ich gedanklich in der Zeile verrutscht.

Globale Variablen, Shared Variablen oder in deutsch gemeinsam genutzte Variablen gibt es in iLogic schon eine ganze Weile. Bisher können meines Wissens aber nur Strings und Zahlen gespeichert werden. Größter Nachteil ist in meinen Augen, das jede Regel darauf zugreifen und die Werte verändern bzw. löschen kann. Daher würde ich sie nur lesend verwenden.

Aus einer Excel in ein Textfile und von dort aus weiter? Da wird die Liste möglicher Fehlerpunkte nicht unbedingt kürzer. Das würde ich mir so nicht antun.
Ich bleib dabei, hart codiert am Beginn der Hauptregel ist mM die bessere Wahl. Die Werte sind quasi statisch. Eine Änderung alle paar Monate macht da nix, vorausgesetzt es gibt eine passende Doku/Kommentare im Code. Weiterer Vorteil; wird ein Wert geändert verwendet die Regel ihn ohne weiteres Zutun ab dem nächsten Durchlauf. Kein Kopieren von A nach B, kein Inventorneustart oder erneute Anmeldung an Windows falls ein Startskript involviert ist usw.
Ist das ganze als externe Regel auf das Netzlaufwerk gelegt, ist nur ein Änderungspunkt vorhanden und die Änderung gilt sofort für alle User.
Die Arraylisten können als Argument beim Aufruf der untergordneten Regeln einfach übergeben werden und stehen dann auch in diesen Regeln zur Verfügung. Ein erneutes hart codieren in diesen Regeln ist nicht erforderlich.

Ein knappes Beispiel zur Argumentübergabe. Die Argumente (Zeichenketten, Zahlen, Arrays, Objekte, was auch immer) werden in eine NameValueMap verpackt und jeweils mit einem sinnvollen Namen versehen. Dadurch kann in der Zielregel mit diesem Namen auf den gewünschten Value zugegriffen werden.

Code:

---

'Regel0
Sub Main
'Erzeugen der Arrayliste
Dim MyPropList = New ArrayList()
MyPropList.Add("PropName1")
MyPropList.Add("PropValue1")
MyPropList.Add("PropName2")
MyPropList.Add("PropValue2")

'Erzeugen einer NameValueMap
Dim NVmap As Inventor.NameValueMap = ThisApplication.TransientObjects.CreateNameValueMap()

'Hinzufuegen der Arrayliste
NVmap.Add("PropList", MyPropList)

'Aufruf des zweiten Regel mit Argumentuebergabe
iLogicVb.RunRule("Regel1", NVmap)

End Sub

'Regel1
Sub Main()
'Pruefen ob Argument vorhanden ist
If RuleArguments.Exists(“PropList”) Then
'Argument an Variable haengen
'alternativ muss man sonst RuleArguments("PropList")(0),RuleArguments("PropList")(1) usw. schreiben)
tmp = RuleArguments("PropList")
'Ausgabe der Werte zur Demo
MsgBox(tmp(0) & " ::: " & tmp(1) & vbCrLf & tmp(2) & " ::: " & tmp(3))
Else
'Damit man merkt falls nichts angekommen ist
MsgBox("Nothing received")
End If
End Sub

---

------------------
MfG
Ralf

RKW Solutions GmbH
www.RKW-Solutions.com

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

---

Danke Ralf, da habe ich wieder einiges gelernt. SharedVariable kannte ich noch nicht. Hier steht, dass die auch andere Informationen speichern können, als nur Text und Zahl. Habe ich aber nicht ausprobiert.

Bzgl. Deinem Beispiel zur Argumentübergabe müsste es mE umgekehrt aufgebaut werden. Es gibt eine (1) Regel, in der die iProperty-Namen und Werte etc. hart codiert stehen und in Variablen/Arrays geschrieben werden. Diese Regel wird dann aber von mehreren anderen Regeln aufgerufen, die dann die Infos weiter verarbeiten.
Folgend Dein Beispiel umgestrickt. Regel1 ist dann eine von mehreren, die für verschiedene Fälle / Ereignisauslöser gemacht sind (sofern ich mir das ganze richtig vorstelle).

Code:

---

'Regel0
Sub Main
Dim NVmap As Inventor.NameValueMap

'wurde etwas übergeben?
If RuleArguments.Arguments IsNot Nothing Then
NVmap = RuleArguments.Arguments
Else
MsgBox("Rule arguments were not received.", , "")
Exit Sub
End If

'Erzeugen der Arrayliste
Dim MyPropList = New ArrayList()
MyPropList.Add("PropName1")
MyPropList.Add("PropValue1")
MyPropList.Add("PropName2")
MyPropList.Add("PropValue2")

'Hinzufuegen der Arrayliste
NVmap.Add("PropList", MyPropList)

End Sub

'Regel1
Sub Main()

'Erzeugen einer NameValueMap
Dim NVmap As Inventor.NameValueMap = ThisApplication.TransientObjects.CreateNameValueMap()

'Aufruf der anderen Regel, Übergabe der NameValueMap
' die wird dort befüllt
iLogicVb.RunRule("Regel0", NVmap)

Dim tmp = NVmap.Item("PropList") 'evtl. sollte vorher noch auf Existenz geprueft werden

'Ausgabe der Werte zur Demo
MsgBox(tmp(0) & " ::: " & tmp(1) & vbCrLf _
& tmp(2) & " ::: " & tmp(3))

End Sub

---

------------------
Gruß KraBBy

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

---

Hallo

Stimmt, der Typ des SharedVariable Value ist Object. Da kann alles rein.

Ich bin bei dem Beispiel davon ausgegangen das es eine Hauptregel gibt, die je nach Situation eine oder mehrere weitere Regeln aufruft und in diesen werden die Listen benötigt. Darum sollte die Liste einmal zentral in der Hauptregel erstellt und als Argument bei Bedarf an die abhängigen Regeln übergeben werden. In meinem Fall wird eine Liste möglicherweise einmal umsonst erstellt, da keine der abhängigen Regeln aufgerufen wird.
In deinem Fall wird bei jedem Aufruf von einer der Regeln die Liste neu erstellt und am Ende dieser Regel wieder zerstört. Das können, je nach Menge sehr viele Aufrufe zum Erstellen der immer gleichen Liste sein.
Da es hier aber nicht um Millionen von Dateien geht, denke ich ein möglicher Performancevorteil einer der beiden Varianten ist eher theoretischer Natur.
Was mich stutzig macht, iLogicVb.Rule übergibt die RuleArguments ByVal (laut Doku). ByVal wäre aber eine Kopie der NameValueMap, die unabhängig vom Original in der aufrufenden Sub ist. Ein "Zurückschreiben" der Werte dürfte in diesem Fall gar nicht funktionieren. Dafür müsste die NVmap ByRef übergeben werden. 

------------------
MfG
Ralf

RKW Solutions GmbH
www.RKW-Solutions.com

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

---

Zitat:

---

Original erstellt von rkauskh:
Was mich stutzig macht, iLogicVb.Rule übergibt die RuleArguments ByVal (laut Doku). ByVal wäre aber eine Kopie der NameValueMap, die unabhängig vom Original in der aufrufenden Sub ist. Ein "Zurückschreiben" der Werte dürfte in diesem Fall gar nicht funktionieren. Dafür müsste die NVmap ByRef übergeben werden.  

---

Bis in die Doku habe ich mich gar nicht eingelesen, sondern nur ausprobiert. In dem vorher verlinkten Beitrag wurde das auch so gemacht.
Mein Erklärungsversuch: eine NameValueMap ist für sich ein Reference Type (im Gegensatz zu Value Type). Dh. eine Variable vom Typ NameValueMap enthält immer nur einen Verweis auf einen Speicherbereich mit dem Objekt. Wenn einer anderen Variable die erste Variable zugewiesen wird, dann wird nur der Verweis kopiert. Als Stichworte die Speicherbereiche Stack und Heap.
Es ist also bei einem Reference Type egal, ob ByRef oder ByVal übergeben wird (zumindest solange nur das Objekt selbst verändert wird. Wird ein anderes Objekt der Variable zugewiesen, ist es NICHT egal.)

Beispiel zu Reference Type:

Code:

---

Dim a As NameValueMap, b As NameValueMap
a = ThisApplication.TransientObjects.CreateNameValueMap()
a.Add("Name", "Value_a")
b = a
b.Value("Name") = "Value_b"
MsgBox( a.Item("Name"), ,"'Name' von a" )
'-> liefert "Value_b"
' weil beide Variablen a und b auf das gleiche Objekt verweisen.

---

------------------
Gruß KraBBy

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

---

Hallo zusammen,

ich möchte hier auch nochmal eine Rückmeldung geben. Das mit den NameValuemaps habe ich mir angesehen. Ist in einem anderen Projekt von mir sicherlich interessant hier benötige ich es eigentlich nicht, da normalerweise immer genau eine dieser Regeln aus der "Hauptregel" aufgerufen werden wird, sollte der User nicht irgendeinen Mist bauen.

Was die Performance deutlich verbessert hat war wie gesagt die Umstellung auf folgenden Code:

Code:

---

'Benutzerdefinierte Iproperties aus Excel erstellen
Dim Proplist As String
Dim ocustompropertyset As PropertySet = ThisDoc.Document.PropertySets.Item("Inventor User Defined Properties")
Dim tmp As String = GoExcel.CellValue("H:\QS\Konstruktionshandbuch\in Arbeit\Freigabeworkflow\Ablaufdiagramm Ilogic Freigabe.xlsx", _
"Propertyliste_Auto", "A" & i)
i = 2
Do Until tmp = ""
Try
ocustompropertyset.Add("", tmp)
Catch
End Try
i = i + 1
tmp = GoExcel.CellValue("H:\QS\Konstruktionshandbuch\in Arbeit\Freigabeworkflow\Ablaufdiagramm Ilogic Freigabe.xlsx", _
"Propertyliste_Auto", "A" & i)
Loop

---

Hier sprechen wir von fast 20 Sekunden Einsparung zum vorherigen.

Ebenso habe ich nun die ganzen GoTos aus meinem Code entfernt und alles durch Do-Loops ersetzt. In diesem Zuge erstelle ich die Arraylisten für meinen "Propertyhelper" jetzt auch nur noch einmal gesammelt vor der Helferschleife, das hat auch nochmal einiges gebracht - Es scheint so zu sein, dass das Erstellen von InputListBoxen in Verbindung mit Excel auch eine ziemliche Bremse darstellt, während die gesammelten Arrays (7 Stück a 3-6 Einträge) innerhalb kürzester Zeit fertig sind.

Danke also nochmal an alle!

------------------
FÌr jede Fehlermeldung gibt es eine Lösung

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