VBA migrate VB

  • VB.NET

Es gibt 10 Antworten in diesem Thema. Der letzte Beitrag () ist von petaod.

    VBA migrate VB

    Hi,

    ich habe eine ziemlich großes Projekt über Jahre in VBA, zuletzt in Office 360 geschrieben.

    Über die Zeit sind eigentlich alle Tabellen-Operationen rausgeflogen und ich benutzte nur noch die Excel Forms mit einer selbstgeschriebenen Datenbank.

    Der nächste logische Schritt wäre die Migration des kompletten Projekts nach Visual Basic.

    Nun habe ich gegoogelt und bekomme unterschiedliche Vorschläge, wie ich z.B. die Userforms aus VBA nach VB bekomme, aber ich bekomme nur den Code importiert aber nicht die zugehörige Userform.

    Kann mir jemand einen Tip geben, wie ich eine VBA Form nach VB(.net) importiere.

    Ich habe die Form in VBA schon exportiert und 2 Dateien (.frm und .frx) vorliegen.

    Der Import in VB ergibt eine Start.frm (was so richtig wäre), aber nur mit Code als Inhalt und einem komischen Header:

    Visual Basic-Quellcode

    1. VERSION 5.00
    2. Begin {C62A69F0-16DC-11CE-9E98-00AA00574A4F} Start
    3. Caption = "Bitte Aktion wählen:"
    4. ClientHeight = 11130
    5. ClientLeft = 45
    6. ClientTop = 330
    7. ClientWidth = 18720
    8. OleObjectBlob = "Start.frx":0000
    9. StartUpPosition = 1 'Fenstermitte
    10. End
    11. Attribute VB_Name = "Start"
    12. Attribute VB_GlobalNameSpace = False
    13. Attribute VB_Creatable = False
    14. Attribute VB_PredeclaredId = True
    15. Attribute VB_Exposed = False
    16. Option Explicit
    17. Private Sub BUT_Info_Click()
    18. Dim i As Integer
    19. .......

    Wie bekomme ich die eigentliche Form da rein ?

    Das sind immerhin 16 Forms mit insgesamt 300+ statischen und dynamischen Controls etc.drin.

    Das nachzubauen wäre sehr aufwendig. Ich hoffe, hier gibt es einen einfacheren Weg.

    Vielen Dank vorab für die Hilfe.

    *Topic verschoben* ~ Marcus Gräfe
    Korrekte Code-Tags gesetzt ~ EaranMaleasi

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „EaranMaleasi“ ()

    Sehe ich ähnlich. Abreißen und neu bauen wie ich als Handwerker sagen würde.
    Dabei kann man auch gleich den VB Legacy-Mist rauswerfen und durch .net ersetzen.

    Ist zwar erstmal natürlich mehr Arbeit, aber bevor du da ewig Zeit in irgendwelche Konverter reinsteckst, die dir ein nicht funktionierendes, veraltetes Programm rauswürfeln: mach es neu.
    Und es gibt keine Möglichkeit die Userforms nur mit Ihren Objekteigenschaften zu migirieren ?

    DIe fast 7000 Zeilen Code in den Forms und Modulen würde ich sowieso Stück für Stück per Hand portieren.
    Da ist mir ein Konverter definitiv zu unsicher.

    Aber die Userforms nachbauen finde ich extrem aufwendig.
    Da muss alles passen da die Datenbank Darstellung in den unterschiedlichen Unter-Forms sich anhand der objekt-Namen orientiert.
    Sprich in der Datenbank gibt es einen Wert wohin er das schreiben soll der sich grob aus Ziel-Userform.object.name.typ zusammensetzt.
    Ist heute als Lösung nicht mehr ganz nachzuvollziehen, damals war es einfach so gut gelöst und vor allem skalierbar.
    Die Datenbank ist idz immens groß geworden, diese zu manipulieren möchte ich eigentlich nicht in Angriff nehmen.

    Alternative Ideen ? Vielen Dank im voraus.
    Vergiss "Konverter". Bei so etwas komplexen macht alles Andere außer abreißen und neu bauen meiner Meinung nach echt keinen Sinn.

    Ich habe vor Jahren ein Access Projekt mit etwa 185.000 Zeilen Code in VB .Net übernommen, dabei den Code um 90% eingekürzt weil in .Net vieles einfacher ist.

    Die Formulare mögen fummelig sein, allerdings wird das, wenn du erstmal drin bist, der kleinste Teil sein.

    Die größte Umstellung für dich wird der Zugriff auf die Datenbank sein. Bisher dürftest du mit Recordsets in VBA arbeiten oder? Die gibts so in der Form nicht mehr.
    "Die größte Umstellung für dich wird der Zugriff auf die Datenbank sein. Bisher dürftest du mit Recordsets in VBA arbeiten oder? Die gibts so in der Form nicht mehr. "


    Nein, ich habe eine richtige Datenbank komplett selber programmiert mit einfachem Push/Pull/Extract/Overwrite und einer sehr schnellen Suchfunktion für die Datensätze.
    Da sehe ich im umsetzen des Codes keine Probleme, ich muss mir nur nohchmal den Dateizugriff von VB und die Unterschiede zu VBA (es sind keine Exceltabellen sondern ein eigenes Dateiformat) anschauen.
    Hi community,

    am 7. September 2020 habe ich diesen thread gestartet, nun ist es vollbracht. :)

    Das gesamte Projekt geht nun in die BETA-Test Phase, sprich ich klemme gerade die Test-Datenbank der letzten Monate ab und schalte die Firmen-DB auf.
    Drückt mir die Daumen, BackUps sind gemacht.


    Ich wollte nun einfach mal Rückmeldung geben, wie so eine große VBA->vb.net Portierung funktioniert und was man so beachten sollte:

    1. UserForms baut man neu. Alles andere ist sinnlos.

    2. Man kann zwar große Teile des Codes aus VBA kopieren und irgendwie hinstricken.
    Spätestens bei OPTION STRICT ON ist das aber imho zum Scheitern verurteilt.

    Man muss an so vielen Stellen umdenken und den alten "Schrott" durchkauen und massiv verändern --> sinnlos.

    Ich habe die alten Module Prozedur für Prozedur neu programmiert.
    Idee und Ablauf übernommen, wo es sinnvoll war, ansonsten NEU.
    Aufgrund der wirklich weitreichenden Möglichkeiten in vb.net Daten zu verarbeiten war das auch absolut notwendig.
    Und da kratze ich definitiv erst an der Oberfläche, was meinen aktuellen Wissensstand angeht....

    3. Option STRICT ON ist Pflicht. Ich habe nichts bis dato gefunden, was nicht geht. Man braucht halt nur ein bissel Grips und den Willen viel zu Lesen.
    Und das "Late binding" hat mir mit Sicherheit ein paar neue graue Haare gebraht.

    4. Womit wir schon beim nächsten Punkt sind: GOOGLE hilft, und die community in diesem Forum auch.

    Anfangs, und da bin ich ehrlich, war ich schon oft verwundert über manche kryptischen Antworten oder gar Forderungen, auch hier im Forum.
    Die sind aber nur krytisch gewesen, weil ich mich mit dem Thma nicht richtig beschäftigt habe bzw. falsch gefragt habe. (was mir immer noch passiert)
    Ich habe noch nie soviel zum Programmieren gelesen und recherchiert wie im Laufe dieses Projekts.

    Und das lohnt sich, ich freue mich wie der riesige alte Moloch von Jahren vba-Gefrikel nun zu einem sauber strukturierten und lesbaren Code geworden ist.
    Das da immer noch viel Verbesserungpotential schlummert ist mir klar und wird mich die kommenden Jahre bei der stetigen Erweiterung dieses Projekts begleiten.
    Was alleine an neuen Ideen und Verbesserungen einfach durch Recherche und konsequentes umsetzen entstanden ist, aus heutiger Sicht eine deutliche Verbesserung der Benutzbarkeit/GUI und Funktionalität in vielen Bereichen, von dem Geschwindigkeitszuwachs der DB_Funktionen will ich gar nicht erst reden, der ist einfach nur immens.

    5. Dokumentiere Deinen Code, von Anfang an.
    Ich habe mir sooft in den letzten Monaten die Haare gerauft etc, da stehen total kryptische Sachen in meinem alten vba-Code, die zwar (irgendwie) funktionieren, die Erörterung deren Sinn und Zweck mich aber viel Ambition und Zeit gekostet haben. Und zum Teil stellte es sich am Ende als obsolete oder total banal raus.

    6. Refakturie regelmässig und immer wieder. Es wird besser. Jedesmal. Großes Ehrenwort.

    Abschließend ein großes Lob und vielen Dank an Euch alle hier. Daumen hoch für Eure Hilfe und Euer geteiltes Wissen.

    P.S.: Los seit ihr mich allerdings noch nicht. Ich habe da noch 3 weitere solche alten xlsm Dinger die migriert werden wollen und diverse Ideen für die Zukunft :D

    165 Versions-Schritte bis dato, nur noch 3 TODOs (alle DB-related) und immer noch grosse Ambitionen:


    Dieser Beitrag wurde bereits 11 mal editiert, zuletzt von „Mabbi“ ()

    :thumbsup:
    Es ist auch meine Erfahrung, dass eine Migration von VBA nach VB.Net ein komplettes Redesign erfordert, wenn man es richtig machen will.
    Du hast jetzt den Vorteil, dass der gesamte Code aus deiner Feder stammt und du bei allen Methoden und Klassen weißt, was sie tun.
    Das erleichtert dir bei der Wartung die Arbeit erheblich.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --