---

Hallo,

kann mir bitte jemand sagen, was notwendig ist, um VBA-Makros in VB-Programme zu konvertieren. Am liebsten in VB2008 Express?

Wie viel Aufwand ist das?

Was genau muß gemacht werden?

Gibt es Konvertierungs-Tools?

Gibt es Tutorials oder Bücher zu dem Thema?

PS: habe schon gesucht, aber nix schlaues gefunden! (VB ist zu kurz als Suchbegriff)

lg
Didi

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

---

Hi didi,

Konvertierungstools sind mir dort nicht bekannt. Der Aufwand ist auch nicht zu verkennen, wenn du etwas portieren willst.
Schau dir mal die .Net-Labs an. Ich weiss jetzt nur nicht ob dort auch Beispiele auf dem COM-Schnittstelle dabei sind.

Wenn du nach was zu dem Thema VB.NET suchst solltest du vielleicht mal den Begriff VB durch VisualBasic ersetzen. Dann bekommst du auch mehr Treffer.

Ich würde die VBA-Sachen so lange weiter laufen lassen, wie es geht und irgenwann die Sachen in .Net komplett neu erstellen. Da handelst du dir auch keine Probleme mit Altlasten ein.

Gruß, Carsten

[Diese Nachricht wurde von Carsten1210 am 05. Mai. 2009 editiert.]

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

---

Hi Didi,

Zitat:

---

Original erstellt von Goofy007:
..PS: habe schon gesucht, aber nix schlaues gefunden! (VB ist zu kurz als Suchbegriff)

---

Vielleicht ein anderen Suchbegriff eingeben  z.B. "VB6 nach VB.NET konvertieren"

Aber davon ab ist eher interessant wie deine Projekte aufgebaut sind.
(ActiveX, OCX ....)

Weiss nicht wie es bei der Express Version ist. Bei der Enterprise Version gibt es einen Konverter der (Vorraussetzung installiertes VB6) aus einfachen VB6 Programmen .net Proggis macht.

Aber im Endeffekt würde ich es so machen:
- alte Projekte so weiter laufen zu lassen
- neue Projekte auf .Net beginnen

Ein Konverter übersetzt auch nur den alten Kram in schlechtern Kram.
Der ist dann kaum noch "Wartbar".
Bei alten Projekten ist meist auch die GUI stark mit dem Programmcode verbunden. Da ist dann mal Zeit aufzuräumen.

Wilfried Stelberg

------------------
Warum lisp'eln wenn's auch anders geht.
www.ib-stelberg.de

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

---

Hallo Didi!

Suchst du vll. so etwas wie das hier?

------------------
Gruß, Stephan
www.stbartl.at

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

---

Danke für euere Beiträge,

das hilft mir schon mal weiter.

lg
Didi

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

---

Hallo nochmal,

da ihr alle eine Portierung nach .NET für nicht schlau haltet, hätte ich gerne noch gewußt wie viel Aufwand es denn wäre aus den VBA-Makros ein VB6 Programm zu manchen. VBA ist ja meines Wissens eigentlich ein VB6 Code. Da müsste es ja leichter gehen. Oder?

Der Grund für diese "komische" Fragerei ist übrigens, daß eine Firma daran interessiert wäre einige meiner Makros kommerziell zu vertreiben. Die wollen aber keinen sichtbaren Quellcode verkaufen. Statt dessen soll es ein (VB-)Programm mit Kopierschutz werden.
Und ich muß jetzt abschätzen wie viel Arbeit diese Portierung sein wird.

lg
Didi

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

---

Hi Didi, 

Zitat:

---

da ihr alle eine Portierung nach .NET für nicht schlau haltet

---

...dem kann ich grundsätzlich nur zustimmen.

Zitat:

---

viel Aufwand es denn wäre aus den VBA-Makros ein VB6 Programm zu manchen

---

...das wird schwer, das kann von paar Minuten bis Wochen gehen. Ohne die Codes zu sehen ist es nicht möglich, eine Abschätzung zu geben.

Sicher wird das Konvertieren von VBA nach VB6 leichter (verglichen zu VBA zu vb.NET).
Sicher ist auch der Code in VB6 besser vor debugging geschützt als in vb.NET (denn das (vor)komplilierte Ergebnis ist sehr leicht wieder in eine lesbare Version zu bekommen).
Sicher ist aber auch, dass Du mit dotNET eine weit höherere Performance als mit VB6 erzielen kannst.
Sicher ist auch, dass Du mit dotNET leichter auf unterschiedlichen Betriebssystemen-Arten (32bit - 64bit).

Und meine Vorgehensweise ist in solchen Fällen, dass ich das Konzept des alten Programms übernehme, aber den Code eigentlich zu 80% neu schreibe (und damit auch immer wieder etwas schlauer machen kann, das ich eben vor Jahren noch nicht wusste), kostet Zeit, bringt aber Qualität/Stabilität und Performance.

- alfred -

------------------
www.hollaus.at

---

Hallo Alfed,

danke für deine ausführlichen Erklärungen. Jetzt kann ich mir schon mal vorstellen mit welchem Aufwand, und mit welchen Vorteilen und Nachteilen ich da zu rechnen habe.

lg
Didi

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

---

In dem Video, das hinter meinem angegebenen Link zu finden ist, wird ja erklärt, wie man VBA in VB.NET umwandelt. Als Zwischenschritt muss man den Code aber in VB6-Code umwandeln, was ebenfalls anhand eines Beispiels gezeigt gezeigt wird. Da das Ganze auf das Ziel des VB.NET-Codes ausgerichtet ist, wird das Bsp. unter VB6 nicht getestet, glaub ich, aber eine Starthilfe ist es auf jeden Fall.

Und prinzipiell will ich zu VBA->VB.NET sagen:
Ich finde, das hängt vom jeweiligen Programm ab, ob es sinnvoll ist, das Umzuwandeln oder neu zu schreiben. So allgemein, finde ich, kann man nicht sagen, dass man VBA nicht zu VB.NET konvertieren soll.

------------------
Gruß, Stephan
www.stbartl.at

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

---

Hi Stephan,

ich fand das Video sehr gut. Ich kannte es nicht. Danke für die Info.

Noch zur Sache:
Ich finde auch das es davon abhängig ist was man da für Proggis hat.
Ausserdem sollte man bedenken das die VBA Proggis meistens (bei mir ist das so) eher Script Charakter haben. Da hat man mal schnell ein Problem gelöst.
Wenn man "richtige" Applicationen bauen will ist man dann schnell im ARX Bereich.
Für ein schnelles Proggi ist mir der Aufwand da zu hoch.
Zusätzlich ist bei der Migration zu bedenken, dass man auch unter .Net dann immer noch "nur" mit der Com Schnittstelle zu tun hat. Wer weiss wie die fortgeführt wird. Einige Interfaces sind ja jetzt schon nicht mehr enthalten.

Und als letzte Bemerkung:
Ich gehe mal davon aus das Autodesk noch was alternatives Ausgraben wird. Ein Script Editor der halt .Net versteht.

Wilfried Stelberg

------------------
Warum lisp'eln wenn's auch anders geht.
www.ib-stelberg.de

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

---

das wäre dann eher VSTA (Visual Studio Tools for Applications)

was ich daran nicht ganz kapier: Wenn Autodesk VSTA bringen will, warum warten die dann mit dem Abwürgen von VBA nicht bis VSTA in AutoCAD integriert ist (anstatt ein AutoCAD zu bringen, in dem NICHTS integriert ist). Damit es für mich richtig Sinn macht, sollte VSTA VBA DIREKT ablösen, von einer Version zur nächsten (ohne eine "leere" Version dazwischen) - sich sozusagen direkt die Klinke in die Hand geben. Außerdem gehen die meisten in letzter Zeit veröffentlichten Lern-Videos (inkl. des oben verlinkten) in Richtung .NET (da wird anscheinend von Autodesk viel in Richtung .NET-Lernen investiert). Und zu guter Letzt wird in manchen Beiträgen im Internet gesagt, VSTA sei fast genauso schwer zu erlernen, wie VB.NET.

Das einzige, was für VSTA in AutoCAD spricht ist, dass Autodesk noch kein offizielles Statement gegen VSTA abgegeben hat. Meine Vermutung ist, dass Autodesk einmal versucht, den ehemaligen VBA-Programmierern VB.NET schmackhaft zu machen. Falls VB.NET doch nicht so gut aufgenommen wird kann man ja VSTA noch "hinterherschmeißen".

Insgesamt glaube ich also eher nicht so recht daran, dass da noch etwas Alternatives (ein Script Editor der .NET versteht bzw. VSTA) nachkommen wird.

------------------
Gruß, Stephan
www.stbartl.at

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

---

Hallo Stephan,

beim 2010 kann man es ja noch installieren. Ist wahrscheinlich der erste Erziehungsschritt und der "Fragebogen" ob es bitter aufstösst.

Ausserdem so nahtlos gehts wohl auch nicht da ich ja immer noch in meinen alten Code schauen muss. Von daher kann ich es verstehen das man VBA rauslässt, aber nicht das es kein VSTA oder ähnliches gibt.

Auf jeden Fall kann es nicht schaden sich .net zu nähern. Egal was da kommt wird es syntaktisch ein wenig anders sein.

Bei der Topobase gibt es z.B. beides. Gut dokumentierte .Net Api mit der man Zugriff auf alles hat. Die Funktionalität ist ein wenig anders. Hier werden sogenannte Plugins geladen. Das sind auch "normale" DLLs die ein Interface zum Proggi haben. Alle Events bei Laden, Menü etc. werden auch an die Plugins gesendet um sich da einzuklinken. Zur Erstellung gibt es Templates die schon die Grundstrukturen beinhalten.
Zusätzlich gibt es in Formularen "Scripteditoren". Da sind halt die Events auf die aus der Maske beschränkt. Man aber auch Zugriff auf das komplette Objektmodell.

Ich könnte mir vorstellen, das so was in der Art kommt. Aber schauen wir mal 

Wilfried Stelberg

------------------
Warum lisp'eln wenn's auch anders geht.
www.ib-stelberg.de

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

---

Hallo zusammen,

ich habe vor kurzem eine interessante Theorie erfahren (ich hoffe mal das sie nicht ganz eintrifft).

VBA ist ja eine Microsoft Sache. Und eben Micorsoft will VBA komplett ablösen. Soll heißen Autodesk muss seine Anwender (ob gewollt oder nicht) langsam darauf vorbereiten. Weiter wird behauptet, das unter Windows7 kein VBA mehr zur Verfügung steht - also auch nicht in den Office-Produkten!
Das heißt ein Betriebssystemwechsel kann das Aus für VBA bedeuten!
Kann das jemand bestätigen oder besser widerlegen?

Viele Grüsse

Martin

------------------
ACAD Map2006 3D, XP Prof. SP2
ACAD Map2010 3D, XP Prof. SP2

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

---

Hi Martin,

negativ, soll heissen die Vermutung ist nicht richtig.

VBA wird mit Office mitinstalliert, da hat imho das Betriebssystem keinen Einfluß; ich hab auch jetzt mit Windows7RC Office2007 installiert (brauchte ich eh) und bei Makro-Aufzeichnung erhalte ich schön brav VBA geöffnet 

Aber grundsätzlich ist's schon so, die Tendenz der zukünftigen VBA-Verwendung geht wohl zurück, und das wohl schon auch technisch von Microsoft beeinflußt. Erstmals zu bemerken bei allem, was mit 64bit zu tun hat, da hat Autodesk gerade noch einen Workaround hinbiegen können (und der läuft mit einer Performance, wenn man das überhaupt noch so nennen kann, die bei größeren Sachen einfach zu vergessen ist). Also längerfristig wohl alternative suchen.

- alfred -

------------------
www.hollaus.at