---

Hallo Forum

Ich hab da ein paar allgemeine Fragen zum Programmieren in VBA oder VB.Net.

- Was bedeutet eigentlich das kleine „o“ von den Variablennamen (z.B.: oDoc, oPath, …)
- Sollen alle Variablen immer am Anfang einer Sub deklariert werden oder dort wo sie als zum ersten Mal gebraucht werden?
- Wie macht ihr das mit den Einrückungen im Programmcode, immer nach einem If, wo noch?
- Wann fügt ihr eine Leerzeile ein?
- Verwendet ihr die Anweisung „Option Explicit“, oder ist die überflüssig?
- Macht ihr eigentlich eine Dokumentation eurer Makros? (also eine Art Bedienungsanleitung)
- Werden bei euch Formulare und Module strikt getrennt? (also nur wenig Code in den Formularen) Ich hab öfter sehr viel Code in den Formularen.
- Speichert ihr eure Makros alle in der Default.ivb, oder habt ihr für jedes Projekt eine eigene .ivb?
- ….

So, dass sind einmal ein paar Fragen die mich immer wieder beschäftigen.

mfg
3D-User

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

---

Hallo

Das "o" steht einfach nur für "Object". Man signalisert damit den Variablentyp. Vorschrift ist das nicht, aber hilfreich wenn der Code umfangreicher wird. "Leider" gibt es mittlerweile viel mehr Typen als Buchstaben. Deswegen taucht das "o" als allgemeiner Bezeichner so oft auf. Weitere Beispiele:
s - String
b - Byte
d - Double
i - Integer
a - Array

Ich deklariere vorzugsweise zu Beginn, weil man sich sonst schlicht einen Wolf sucht, wenn man später die Deklaration sucht.
Einrückungen mach ich zur Strukturdarstellung bei IF's, jegliche Schleifen und Select's und überall da wo es nach meinem persönlichen Geschmack die Lesbarkeit des Codes erhöht.
Leerzeilen (gern auch mal 2 oder 3) zur optischen Trennung von Codeblöcken. Eine längere If-Anweisung z.B. könnte man am Ende so optisch besser vom nachfolgenden Code absetzen.
Ich verwende Explicit immer. Ich mag es nicht, wenn Software anfängt zu "denken" und selber errät welchen Typ eine Variable haben soll. Da kommen u.U. seltsame Ergebnisse raus.
Es empfiehlt sich am Anfang ein paar Kommentarzeilen zu hinterlassen, die einem selbst und anderen die grundsätzliche Funktionalität erläutert. Weiterhin Kommentare an Schlüsselstellen im Code. Es macht keinen Sinn (in meinen Augen) jede Zeile zu kommentieren. Wer mehr lesen will, soll sich ein Buch kaufen.  Eine externe Bedienungsanleitung wird erstellt, wenn sie notwendig ist. Gibt man seine Programme nach außen, ohne direkte Supportmöglichkeit, geht's eigentlich nicht ohne. Spätestens bei für den User unsichtbaren Funktionen sollte das dokumentiert werden. Es müssen ja nicht 3 in Leder gebundene Bücher sein, eine Kurzanleitung reicht meistens. Im Zweifel einen Anwender drauf loslassen und gucken wie weit er kommt und welche Fragen auftauchen.
In Formularen halte ich es möglichst kurz. Warum? Man hat mir mal gesagt ich soll das so machen.
Die default.ivb wird irgendwann sehr groß und die Liste im Editor entsprechend unübersichtlich. Somit beantwortet sich die Frage eigentlich von allein oder? 

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

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

---

Hallo

Danke rkauskh, scheinbar bist du der einzige der hier Antwortet.
Programmieren für Inventor ist wohl nicht der Renner.
Nur was für Spezialisten eben!

Mfg
3D-User

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

---

Hallo

Es kann ein paar Tage dauern, da nicht jeder jeden Tag Zeit hat. Nicht jeder möchte sich zu allgemeinen Themen äußern. Ist ja freiwillig.

Im Grunde ist die Art der Codestrukturierung eine Glaubens- oder Ansichtsfrage. Und ein beliebtes Streithema über "die richtige" Art. Es gibt eine Reihe empfohlene Vorgehensweisen, aber keinen Zwang. Dem Compiler ist am Ende die ganze Mühe egal, er feuert's alles raus.
Ja, die Programmierung ist weniger verbreitet als die Anwendung. Ist bei anderen Programmen aber nicht anders. Ich verwende Excel auch mehr als ich drin rum programmiere. Wäre auch schlimm, wenn es anders herum wäre.

Noch eine Ergänzung oder besser ein Vorschlag zur default.ivb:
Leg dir dort eine Reihe von Modulen mit allgemeinen, immer wieder auftauchenden Funktionen an. Zum Beispiel ein Modul "Properties". Da packst du dann Public-Funktionen rein, die immer wirder kehren. Für benutzerdefinierte iProps z.B. Existiert ein Property, Lesen des Inhalts, Schreiben des Inhalts, Erzeugen des iProps und Löschen des iProps. Das Ganze dann jeweils für Document, PartDocument, AssemblyDocument, DrawingDocument und evtl. noch für PresentationDocument. Da kommt schnell ein  schöne Liste zusammen. Danach das Ganze für die anderen PropertySets noch mal und schon kannst du ein neues Modul "Parameters" anfangen und da Funktionen zum Bearbeiten von Parametern ablegen.
Da die Funktionen alle Public sind, kommst du über Properties.Funktionsname von überall wieder dran und sparst du zukünftig viel Getippse. Je früher man damit anfängt, umso besser. Die Module können Stück für Stück erweitert werden.

Hier mal ein möglicher Ansatz für ein Propertie-Modul:

Code:

---

Option Explicit

Public Function CheckExistUserProperty(ByVal oPartDoc As PartDocument, ByVal sPropertyName As String) As Boolean
    Dim oProperty As Inventor.Property
    For Each oProperty In oPartDoc.PropertySets.Item("User Defined Properties")
        If oProperty.Name.ToUpper = sPropertyName.ToUpper Then
            CheckExistUserProperty = True
            Return
        End If
    Next
    CheckExistUserProperty = False
End Function
   
Public Function CheckExistUserProperty(ByVal oAssDoc As AssemblyDocument, ByVal sPropertyName As String) As Boolean
    Dim oProperty As Inventor.Property
    For Each oProperty In oAssDoc.PropertySets.Item("User Defined Properties")
        If oProperty.Name.ToUpper = sPropertyName.ToUpper Then
            CheckExistUserProperty = True
            Return
        End If
    Next
    CheckExistUserProperty = False
End Function

Public Function CheckExistUserProperty(ByVal oDoc As Document, ByVal sPropertyName As String) As Boolean
    Dim oProperty As Inventor.Property
    For Each oProperty In oDoc.PropertySets.Item("User Defined Properties")
        If oProperty.Name.ToUpper = sPropertyName.ToUpper Then
            CheckExistUserProperty = True
            Return
        End If
    Next
    CheckExistUserProperty = False
End Function

Public Function DeleteUserProperty(ByVal oPartDoc As PartDocument, ByVal sPropertyName As String) As Boolean
    Dim oProperty As Inventor.Property
    For Each oProperty In oPartDoc.PropertySets.Item("User Defined Properties")
        If oProperty.Name.ToUpper = sPropertyName.ToUpper Then
            Call oProperty.Delete
            DeleteUserProperty = True
            Return
        End If
    Next
    DeleteUserProperty = False
End Function

Public Function ReadUserPropertyValue(ByVal oPartDoc As PartDocument, ByVal sPropertyName As String) As String
    Dim oProperty As Inventor.Property
    For Each oProperty In oPartDoc.PropertySets.Item("User Defined Properties")
        If oProperty.Name.ToUpper = sPropertyName.ToUpper Then
            ReadUserPropertyValue = oProperty.Value
            Return
        End If
    Next
    ReadUserPropertyValue = ""
End Function

Public Function WriteUserPropertyValue(ByVal oPartDoc As PartDocument, ByVal sPropertyName As String, ByVal sPropertyValue As String) As Boolean
    Dim oPropertySet As PropertySet
    Dim oProperty As Inventor.Property
    oPropertySet = oPartDoc.PropertySets.Item("User Defined Properties")
    For Each oProperty In oPropertySet
        If oProperty.Name.ToUpper = sPropertyName.ToUpper Then
            oProperty.Value = sPropertyValue
            WriteUserPropertyValue = True
            Return
        End If
    Next
    Call oPropertySet.Add(sPropertyValue, sPropertyName)
    WriteUserPropertyValue = True
End Function

---

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

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

---

Hallo
Passend zum Thema Programmieren habe ich diese Woche einen Beitrag von Zuckerberg und Gates gelesen. Scheinbar fehlt es da an Nachwuchs.
http://futurezone.at/digitallife/14372-gates-und-zuckerberg-werben-fuers-programmieren.php

Also das mit den Funktionen ist genial. Ohne zu wissen das es eine “Strategie“ ist habe ich mir selber auch schon ein paar Funktionen zugelegt auf die ich immer wieder zugreife (z.B.: Verzeichnisse erstellen). Es auf Propertys (und ähnliches) auszuweiten ist absolut genial. Hier ist eine Gute Dokumentation wichtig, denn sonst verliert man bald den Überblick.

Noch eine Frage:
Ich habe das Problem, dass beim Aufruf eines VBA Makros mit Forms der Inventor scheinbar einfriert. Man kann keine eingaben ins Formular machen!  Das dauert ein paar Sekunden oder ein paar Minuten. Das einzige was man dagegen machen kann ist kurz ein anderes Programm (z.B Outlook) in den Vordergrund zu hohlen. Danach kann man sofort wieder normal weiterarbeiten.
Übrigens ist es egal ob ein großes Formular oder ein leeres Formular geöffnet wird. Ich habe auch schon herausbekommen das es mit aktivierten Hyper-Threading noch viel schlimmer ist. Möglicher Weise liegt es auch an dem 32-Bit VBA? (unsere Z400 sind alle 64Bit).
Kennst du dieses Phänomen auch, oder gibt es das nur bei mir?

Mfg
3D-User

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

---

Hi

Nei, das Problem trat schon mal auf. Leider keine Lösung.

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

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

---

Hallo,

das Verhalten mit der Verzögerung kommt bei uns auch von Zeit zu Zeit vor. Habe bis jetzt aber weder ein bestimmes Muster noch eine Lösung gefunden.

Gruß

Andi

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

---

Hallo

Hier noch zwei Anmerkungen zum Thema VBA-Verzögerung.
- Das gleiche Makro in einer 32-Bit Umgebung läuft einwandfrei.
- Das VBA-Form über iLogic aufgerufen läuft wesentlich besser.

Mfg
3D-User

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

---

Hallo,

passend zu diesem Beitrag noch eine Beobachtung zum Aufruf der Makros:
Nach mehrmaligem erfolgreichem Aufruf einiger Makros können diese
ohne erkennbare Ursache nicht mehr über den entsprechenden Button des
Makros aufgerufen werden.

Ein Aufruf des Makros direkt im VBA-Editor funktioniert aber noch.

Kommt das nur bei meiner Konfiguration vor, oder ist dieser Fehler bekannt?

------------------
Gruß Roland

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

---

Hallo,
Also dieses Verhalten konnte ich noch nicht beobachten!
Ich habe "nur" das Problem mit der Verzögerung.

Versuch mal das Makro über iLogic zu starten.

  iLogicVb.RunExternalRule("--VBAMakroName--")

Vielleicht geht's damit besser.

mfg
3D-User

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

---

Wir hatten an zwei Rechnern das Problem, daß die Makros überhaupt nicht mehr gestartet werden konnten. Ich hatte Office 2007 in Verdacht, was sich dann auch bestätigt hat. Bei einem Update hatte Microsoft gepfuscht. Es lag an einem Fehler in der Registrierung der MSCOMCTL.OCX.

Mit diesem Link habe ich es hinbekommen.

Gruß
Andi

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

---

Hallo

Nochmals zum Thema VBA-Verzögerung:
Da ist Licht am Ende des Tunnels!
http://modthemachine.typepad.com/

Zitat:
Inventor now supports VBA 7.  VBA 7 is able to run natively on both 32 and 64-bit Windows.  The previous VBA only supported 32-bit Windows, so this is great news for those running 64-bit Windows.  With earlier version of Inventor on a 64-bit system, in order to support VBA at all, Inventor would spawn a separate 32-bit process that would host VBA. This is no longer required and as a result there is no longer any delay when accessing VBA and your macros will also run much faster.  As a side benefit, the scroll button now scrolls the code window.

mfg
3D-User

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