VB6 und sourcetree / gitlab casesensitive/insensitve ?

  • VB6

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

    VB6 und sourcetree / gitlab casesensitive/insensitve ?

    Hi,

    ich habe mal eine Frage....

    Arbeite seit neustem in einem grossen und nun schon fast 30 Jahren bestehenden Projekt das aktuell in VB6 geschrieben ist.
    Ein schwiergiger Umstieg für mich, so eine Art back to the roots Ding. Aktuell ist aufgrund der notwendigen Hardware und nicht verfügbaren modernen 64-bit ocx-Dateien eine umfängliche Migration nach .net leider nicht ohne weiteres möglich.
    Das Projekts umfasst einige Anwendungen die über unterschiedliche Protokolle mit Servern kommunizieren. Die Hauptanwendung ist kompiliert über 30 Mb gross, der Gesamzumfang liegt kompiliert deutlich jenseits der 100 MB, dies als Info zu der Größe des Projekts.

    Nun schreibe ich Module, Klassen um oder baue neue Funktonen ein.
    Wenn ich dann meinen Branch in Sourcetree comitte ist alles in Ordnung, wenn ich einen anderen Zweig mergen oder selber in den main-branch comitten will, dann gibt mir die Differezanalyse in sourcetree Unmengen an Änderungen zusätzlich an, wo Variablen mal ganz oder teilweise in der Gross- und Kleinschreibung verändert wurden. Ich muss dann manchmal zig Blöcke verwerfen bis ich nur noch meinen neuen Coden sehe, obwohl ich die Variablen nicht verändert und auch gar nicht benutzt habe. DIes ist z.T. mal richtig zeitaufwendig und imho völlig unnötig.

    Es kommt sogar vor, wenn ich einen Zwischenstand comitte und ich in einem Modul nur einen Kommentar eingefügt habe, das die Schreibweise von Variablen an x Stellen in dem Modul abgeändert wird.

    Ich habe ja, wie einige hier wissen, lange Zeit an einem eigenen DB-Projekt geschrieben ganz ohne sourcetree und git-lab.
    Dies ist also in Sachen code-Verwaltung Neuland für mich.

    Kann mir bitte jemand einen Tip oder eine Lösung geben, wie ich diese nervige Umsetzung von Variablen in den Griff bekomme ?

    Vielen Dank vorab für Eure Hilfe
    Anbei ein Screenshot hierzu, In diesem Modul habe ich einfach nur einen Kommentar eingefügt und sourcetree zeigt mit fast 200 Änderungen an, alle sehen in etwas so aus ( das Beispiel zeigt einen Teil eines type-Definition):



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

    Wenn sich die Groß-/Kleinschreibung der Variablen ändert, dann musst du was dran gemacht haben (evtl. hast du Code von anderswo via Git eingefügt, der die Namen ändert). VB6 ändert Variablennamen leider projektweit, unabhängig vom Gültigkeitsbereich. Insofern macht Sourcetree hier alles richtig. Ich arbeite übrigens auch mit VB6 und Sourcetree (allerdings mit Gitea als Web-GUI).

    Eine Lösung für das Problem sehe ich bei VB6 nicht.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Wenn sich die Groß-/Kleinschreibung der Variablen ändert, dann musst du was dran gemacht haben

    Leider kenne ich auch dieses Problem. Bin mir aber nicht sicher ob das direkt etwas mit der Sourcecode-Verwaltung zu tun hat (verwenden TFS/Azure DevOps Server).
    Ab und zu, wenn ich ganz wo anders im Code etwas ändere, ändern sich auf einmal irgendwelche Variablennamen in der Groß-/Kleinschreibung.

    Eine Lösung habe ich leider nicht und nehme es so hin.
    Falls es wirklich viele Fälle sind (ist auch immer anders - teilweise keine, teilweise ein paar, teilweise mehrere), dann öffne ich die Form nochmal und ändere diese wieder "zurück".

    Falls wer eine Lösung dazu hat - bin ganz offen.

    LG
    ScheduleLib 0.0.1.0
    Kleine Lib zum Anlaufen von Code zu bestimmten Zeiten

    fichz schrieb:

    Bin mir aber nicht sicher ob das direkt etwas mit der Sourcecode-Verwaltung zu tun hat

    Nein, das hat nur was mit VB6 zu tun.

    Eierlein schrieb:

    Kommt drauf an, wie die Variablen GeDIMmt sind.

    Was meinst du damit? Wenn ich in Form1 sage Dim XYZ As String und in Module1 Dim xyz As String, so steht anschließend in Form1 ebenfalls Dim xyz As String. Dagegen lässt sich nichts tun.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Das ist tatsächlich ein bekanntes Problem in VBC. Man kann da nur eingeschränkt etwas dagegen machen. Hier gibt es eine gute Diskussion und Infos dazu: vbforums.com/showthread.php?90…-code-letter-case-jumping
    Mfg -Franky-

    Hallo,

    vielen Dank für Euer feedback, immerhin bin ich nicht alleine mit dem Problem.

    Ich habe zusammen mit meinem Chef einen interessanten Lösungsansatz erarbeitet und teste daran gerade.

    Die Idee ist, dass die vielzähligen Änderungen vielleicht auf eine quasi willkürliche Änderung des DIM Variablennamens zurückzuführen sind.
    Der Ansatz ist nun, das Projekt nochmal zu öffnen und die zugehörigen/betroffenen (wenigen) Dim Zeilen zu editieren und dort dann Explizit die "ALTE" schreibweise reinzuschreiben.
    Das ändert nach unseren aktuellen Tests die grösse des diffs massiv nach unten.

    So habe ich z.B. folgendes gefunden (noch am testen, sicher nicht der Wahrheit letzter Schrei):
    In einem Modul/Form ist die Variable x$ (gute alte Zei...hüstl) gar nicht definiert sondern wird einfach benutzt.
    In einem anderen Modul gibt es aber eine Dim X$ Zeile
    Wird hier nun bei einem commit irgendwo im Modul aus versehen x$ (nun klein) eingetragen werden in den Modulen wo das x$ nicht definiert sind aber z.B. ein Kommentar eingefügt (also eine Änderung der Anzahl der Zeilen stattfindet) dann alle X$ zu x$ in allen angefassten Modulen, auch bei nur kommentierenden Änderungen, es reicht sogar eine Leerzeile zu entfernen. Und dann hat man aus dem nichts eine unglaubliche Menge diff-Blöcke.

    Ich werde hierzu noch feedback geben, ob der Lösungsansatz mit einem moderaten zusätzlichen Editieraufwand zu den gewünschten Ergebnissen führt.

    Vielen Dank für Eure Unterstützung....

    Btw...noch eine Anmerkung in eigener Sache:
    Einige der altgedienten hier im Forum wissen eventuell noch, dass ich vor Jahren erst angefangen habe meine VBA(Excel) Projekte zu konvertieren nach VB2010, dann mit Eurer Hilfe nach .net und dort nochmals mit Eurer Unterstützung in relativ sauberen VB.Net Code mit Strict on und abgeschalteten alten VB-Befehlssätzen (bis auf VBCrlf und Konsorten)
    Durch Eure nachdrückliche Art, Hilfe und gutgemeinte Kritik habe ich idz. meinen kaufmännischen Job an den Nagel gehängt und arbeite nun schon einige Zeit als Vollzeit Entwickler in einer IT-Firma.
    Die Arbeit ist cool, die Kollegen sind gut und ich war Anfangs schon etwas verwundert, wieviel die Firma für einen Querseinsteiger mit hobbyniveau Programmiererfahrung und gutem kaufmännischen Rüstzeug anbietet, nicht nur finanziell sondern vor allem im Gesamtpaket.
    Da wo ich bin gehe ich jeden Tag mit einem Lächeln zur Arbeit und kehre genauso so nach Hause zurück. Heute frage ich mich eher, warum ich diesen für mich sehr schwierigen Schritt, weg von einem quasi sicheren aber zutiefst langweiligen Job, nicht schon früher gemacht habe.
    An dieser sehr positiven Veränderung für mich habt Ihr alle hier einen echten Anteil, Ihr habt mich gefordert, motiviert und unterstützt. Über Jahre. Dafür möchte ich einfach mal Danke sagen.

    Etwas sentimaental, aber ehrlich. Mfg...Mabbi

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

    Mabbi schrieb:

    In einem Modul/Form ist die Variable x$ gar nicht definiert sondern wird einfach benutzt.

    Das ist aber kein guter Programmierstil (weißt du bestimmt schon). Ich selbst habe in VB6 noch nie ohne Option Explicit gearbeitet (in 23 Jahren).
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

Facebook
Telefonspende