Speziell, wie wahnsinnig und menschenverachtend die inzwischen geworden ist.

Es ist aber nicht mein einziges Steckenpferd ;-). Es klang sicher schon gelegentlich an, daß ich Programmierer bin. Ich pflege seit mehr als 10 Jahren eine Branchenlösung für Abfallbetriebe, Containerdienste. Das Ganze ist für kleine Betriebe mit weniger als sagen wir mal 5 AP für die EDV. Das sind nach meinem Wissen so ca maximal so um die 50 Leute die mit der Software bedient werden. Die meisten Dateneinträge dürften Wiegungen sein. Für jede komplette Wiegung braucht es, so gut wie immer zwei Wiegungen. Ich denke, die Software wurde schon zu DOS Zeiten entwickelt, vielleicht liege ich damit aber auch schief. Wie auch immer, die Programmiere haben m.E. a) relativ typisch in MS Access programmiert und b) wenig über die Menge an Code nachgedacht. Im Zweifel lief es wohl so. Da läuft was, wir kopieren es und passen es halt an. So gibt es Redundanzen noch und nöcher, aber natürlich nicht komplett, das wäre ja zu einfach. Wo man die Redundanzen sehr gut sehen kann, ist an folgendem Code:

Private Sub DruckAngeboSum_Click()
On Error GoTo Err_DruckAngeboSum_Click

Dim objOut As CMediaOutput
    
    Set objOut = generateMediaOutputObjects(ActiveControl.Name)
    objOut.doOutput

'Dim intAntwort As Integer
'Dim strNeueZeile As String
'strNeueZeile = Chr$(10) & Chr$(13)
'
'Dim intSchleife As Integer
'Dim lngNr As Long
'Dim lngDrucker As Long, strBericht As String
'
'Dim WSP1 As Workspace, DB1 As Database, Tabelle1 As Recordset
'Set WSP1 = DBEngine.Workspaces(0)
'Set DB1 = WSP1.OpenDatabase(strDatenbankGlo)
'
'Set Tabelle1 = DB1.OpenRecordset("HT_Nummernkreise", DB_OPEN_TABLE)     ' Tabelle öffnen.
'
'If Forms!HF_AuftrAnkErz!AngebotKz = True Then
'    ' Rückfrage mit Speicherung der Antwort
'    intAntwort = MsgBox("Für diesen Auftrag wurde bereits ein Angebot gedruckt!" & strNeueZeile & "Wollen Sie diesen Ausdruck wiederholen?", 33, "Angebot drucken?")
'    If intAntwort = 2 Then
'        GoTo Exit_DruckAngeboSum_Click
'    End If
'End If
'
'' Firma Beller
'If strKundeNr = "143" Then
'    strBericht = "BR_DruckAngebotAnkErzoSum_Bel"
'Else
'    strBericht = "BR_DruckAngebotAnkErzoSum"
'End If
'
'ordneDruckerZu "Angebot", strBericht, HAUPT_DRUCKER
'
'' Prüfen ob Kontrollkästchen für Seitenansicht aktiviert
'' wenn aktiviert dann Seitenansicht, ansonsten Ausdruck auf Drucker
'If Me!Seitenansicht = True Then
'    If strKundeNr = "143" Then
'        strBericht = "BR_DruckLiefschAuftrAnkErzNot_Bel"
'    Else
'        strBericht = "BR_DruckLiefschAuftrAnkErzNot"
'    End If
'    DoCmd.OpenReport strBericht, acViewPreview
'Else
'    Tabelle1.MoveLast ' Letzten Datensatz suchen.
'    setzeFelder Forms!HF_AuftrAnkErz, Tabelle1, DRUCK_BEREICH_ANGEBOT
'    erhoeheNummer Tabelle1, "AngebotNr"
'
'
'    druckeBericht "Angebot", strBericht, Me!AnzahlDrucke
'
'
'    Forms!HF_AuftrAnkErz!AngebotKz = True   ' Setzen der Druckkennziffer
'    Forms!HF_AuftrAnkErz.Refresh
'
'    ' Logbucheintrag
'    If DLookup("[Benutzerverwaltung]", "HT_SysParameter") = True Then
'        Call SetzeBenutzerLog("Drucke Angebot o. Summen Ankauf Erz.-Preis! Auftrag Nr: " & CStr(Forms!HF_AuftrAnkErz!AuftragNr) & ", Angebot Nr: " & CStr(Forms!HF_AuftrAnkErz!AngebotNr))
'    End If
'End If
  
Exit_DruckAngeboSum_Click:
    On Error Resume Next
'    Tabelle1.Close
'    DB1.Close
    Exit Sub

Err_DruckAngeboSum_Click:
    If err = 2501 Then
        Me!Schließen.SetFocus
    Else
        MsgBox Error$
    End If
    Resume Exit_DruckAngeboSum_Click

End Sub

Die drei Zeilen Code oder so sind das was nach dem Überarbeiten bleibt.
Ein paar Dinge dürften Programmierer in neueren Sprachen durchaus verunsichern, das sind die Label zu denen man springt. Ja, das kann man inzwischen anders lösen und nein, es ist recht typisch für VBA. Man sieht, nur für die Fehlerbehandlung kommen „locker“ 5- 10 Zeilen Code zu jeder Funktion. Insgesamt sind es über 500 000 Zeilen an Code und viele Methoden gehen über mehrere Seiten.

Wie man sehen kann, gibt es keine Trennung der Bereiche. In einer Methode/Funktion gibt es Zugriffe auf die Datenbank, Manipulation der UI und Interaktion mit dem Benutzer. Ich befürchte, daß ist immer noch Stand der Dinge bei sehr vielen Access Programmen. Als wirklich ernsthaftes Problem sehe ich das Fehlen von brauchbaren Testmöglichkeiten an. AFAIK gibt es AccUnit zum Testen, das bekomme ich hier nicht installiert und ich bin derzeit immer noch zu faul um mich dahinterzuklemmen.

Die Klasse, in der ich es auslagerte, sieht der Code nun so aus:

Public Sub doOutput()
    Dim bAdjustNumber As Boolean
    Dim objControl As CControlNummernKreise
    
    

On Error GoTo HandleError
    Dim iAuswahl As Integer
    If outputMedia = outMediumPreview Then
        outputPreview
        GoTo HandleExit
    End If
    
    
    bAdjustNumber = True
    If NZ(actForm(textFieldNumberName), "") <> "" Then
        iAuswahl = askToReprintIfPrintedBefore()
        If iAuswahl = vbNo Then
            GoTo HandleExit
        Else
            bAdjustNumber = False
        End If
    End If
   
    Set objControl = actualizeFormDataBeforePrint()
         actualizeNumberCircle objControl, bAdjustNumber
         Set objControl = Nothing
        
         actionBeforePrint
             If outputMedia = outMediumPrinter Then
                 outputPrinter
             Else
                 outputEmail
             End If
         actionAfterPrint
    actualizeFormDataAfterPrint
    writeLog

    
    
HandleExit:
    On Error Resume Next
    Exit Sub


HandleError:
    If err.Number <> 0 Then
       MsgBox "Error " & err.Number & " (" & err.Description & ") in procedure doOutput."
    End If
    GoTo HandleExit


End Sub

Sicher noch reichlich zu kritisieren, aber ich denke, eine Verbesserung ist zu erkennen.
Der Witz an dieser einen Methode ist: Die kann ich so an ungefähr 8 Stellen so benutzen und muß da nichts mehr anfassen. Ich muß die Daten entsprechend vorbelegen

Case FRM_AUFTRAG_ANKAUF_ERZ
If sKundeNr = "143" Then
objResult.reportName = "BR_DruckAngebotAnkErz_Bel"
Else
objResult.reportName = "BR_DruckAngebotAnkErz"
End If            
objResult.logEntry = "Druck Angebot Ankauf Erz. m. Summen Auftrag Nr: " & NZ(objResult.orderNo, 0) & _
                                 ", Angebot Nr: " & NZ(objResult.actForm(objResult.textFieldNumberName), "")

            objResult.lblFuerKLNr = "Lieferant Nr:"

            Set objParameterAngebot = parDruckAngebot_WH()
            objParameterAngebot.mainTableName = "HT_AuftragAnkaufErz"
            objParameterAngebot.subTableName = "UT_AuftragAnkaufErz_Positionen"
            objParameterAngebot.fieldNameKLNo = "LieferantNr"

gen, aber die Logik dieses Teils geht nicht verloren. Ich denke, daß ist einer meiner Lieblingstechniken, einen Algorithmus austüfteln und dann möglichst nicht mehr anfassen zu müssen. Sollte was schiefgehen, dann habe ich hier eine zentrale Anlaufstelle, um es zu korrigieren und muß nicht die Korrektur 8 mal wiederholen.
Leider macht es einem VBA unglaublich schwer Code wiederzuverwenden, denn obwohl das hier eine Klasse ist, kann ich nicht einfach davon ableiten und nur die Sachen umschreiben, die ich brauche. Ja, es gibt Interfaces, aber die muß man dann von a-z in allen Klassen implementieren, das ist einfach schlecht und dürfte Leuten, die mit Java, Python, Ruby oder so gut wie jeder anderen OO-Sprache programmieren, die Tränen in die Augen treiben. Die Dinge sind aber nun mal, wie sie sind. Modularer bekäme man es nur hin, wenn man jede Methode in ein eigenes Interface auslagerte und dann die Interfaces implementierte, die einzige zugängliche Methode wäre dann z.B. für

 If outputMedia = outMediumPreview Then
        outputPreview
        GoTo HandleExit
    End If

outputTo aber man müsste halt all notwendigen Daten in diesem Interface hinterlegen und bräuchte zumindest ein paar Parameter oder ein Parameter Objekt.

Dann könnte man ein Interface haben für eine Klasse mit dem Namen OutputPreview
und den Wert so setzen

objIf as OutputInterface
if Test_If_Angebot then
  set objIf = new OutputInterfaceAngebot 
...
:..

und riefe es so auf
objIf.outputTo

Es geht leider nicht anders und dann bekommt man eben auch so etwas:

Case FRM_AUFTRAG_ANKAUF_ERZ
            If sKundeNr = "143" Then
                    objResult.reportName = "BR_DruckAngebotAnkErz_Bel"
                Else
                    objResult.reportName = "BR_DruckAngebotAnkErz"
                End If
               
                objResult.logEntry = "Druck Angebot Ankauf Erz. m. Summen Auftrag Nr: " & NZ(objResult.orderNo, 0) & _
                                     ", Angebot Nr: " & NZ(objResult.actForm(objResult.textFieldNumberName), "")
                                     
                objResult.lblFuerKLNr = "Lieferant Nr:"
            
                Set objParameterAngebot = parDruckAngebot_WH()
                objParameterAngebot.mainTableName = "HT_AuftragAnkaufErz"
                objParameterAngebot.subTableName = "UT_AuftragAnkaufErz_Positionen"
                objParameterAngebot.fieldNameKLNo = "LieferantNr"

Hier muß ich einfach festhalten MS hat sich einiges bei VBA gedacht aber a) nicht zu Ende und b) mangelhaft an bestimmten Stellen.

Es gibt durchaus eine Menge Fans von Access. Vom Standpunkt von guter OO-Programmierung ist VBA ein Sanierungsfall. Dabei könnte es so einfach sein. VBA als Mitglied der .NET Sprachfamilie und gut wär’s. Ich verstehe nicht, warum es MS nicht macht. Die Unterstützung durch Werkzeuge ist so in den 80 er Jahren des letzten Jahrtausends hängen geblieben. Ja, man kann in VBA auch riesige Programme schreiben, es tut aber weh ….

Wo MS-Access (mit VBA) vollkommen mangelhaft ist
1) Keine integrierten Tests
2) An Objekten orientiert, aber nicht OO-mässig zu programmieren
3) Grauenhafte Benutzung in einem RCS (hier benutze ich TortoiseGit) , Problem: Groß/Kleinschreibung geht munter durcheinander, es gibt IDS, die sich einfach ändern
4) Keine Unterstützung für die Trennung von UI, Daten und dem Programm. Wie geschrieben, der Code ist heute noch typisch für Ms Access. Man bekommt halt schnell was zusammen …
5) der SQL Editor ist eine Zumutung!

Wo es glänzt
1) mal eben was zusammenstoppeln ist schnell erledigt
2) der Direktbereich, man kann während der Laufzeit anhalten und sich alles anschauen, kein rekompilieren nötig
3) preisgünstig

Es ist klar MS will, daß wir MS-SQL mit C# benutzen, es ist nicht überzeugend, daß dies für kleine Betriebe eine bessere Lösung als eine MS-Access basierte wäre.

Ziehe ich mal von FB rüber, womöglich mache ich da ja nicht mehr so lange mit …

Ich weiß, das Leben ist kein Wunschkonzert, aber trotzdem darf man Wünsche haben. Es gibt eine Reihe davon aus meinem Programmerleben:

– VBA als vollständiges Mitglied der .NET Familie, das Gleiche bitte auch für die WLanguage

– Ein vernünftiger Editor für VBA (ohne die MZ Tools wäre es noch schlechter) MS kann offensichtlich IDEs, warum nicht für die in Office benutzte PS? Man schaue sich mal OpenGenera an und den dort benutzen ZMACS, das ganze OS kann man in Lisp Dialekten programmieren.

– ein vernünftiges Test-Framework für Ms Access. Man versteht, warum es keine Tests gibt und alle Programme im Debugger „entwickelt“ werden.

– Vernünftige Editoren für Smalltalks (egal welches, alle sind unkomfortabel und das für so eine wunderbare Sprache wie Smalltalk

– Ein Smalltalk für die .NET Familie

– Vernünftige GUI, Report Builder oder Tools für die Behandlung von Dateien und Verzeichnissen, für Smalltalks und spezieller Pharo. Warum gibt es nicht was zumindest Gleichwertiges in diesem Bereich zu ja selbst MS Access?

– Ein wirklich nettere PS für Latex (auch wäre ein visueller Report Builder eine nette Sache) Latex läuft, ist stabil seit mehr als20 Jahren und bringt besser Sachen aufs Papier als so gut wie jedes andere Programm .

– Ein GUI-Builder, GUI-Framework, für Emacs, damit man endlich mal auch das von der manuellen Erstellung von GUIS wegkommt.

Ganz massiv stört mich diese Sachen bei Smalltalk. Wenn das in Java möglich ist, dann schon lange in Smalltalk aber nein, damit befleckt man wohl die „Reinheit“ von Smalltalk …

Und ja mich ärgert es auch speziell bei VBA, weil es da schon so

lange gibt und VB ein Meilenstein für die Entwicklung von Windows Programmen war. Was macht MS damit … Es ärgert mich noch mehr, wenn ich daran denke, worauf der Erfolg von MS basiert. Es war nicht zuletzt das Basic von denen, was MS an die Spitze brachte und dann macht man so was platt?

Bei Emacs ärgert mich etwas, daß es Emacs Lisp gibt. Warum konnte es kein Common Lisp sein? Stallmann kannte es doch …

Und nein, ein Guile-Emacs gibt es immer noch nicht ernsthaft …

Ja, ich weiß mach’s doch selber … Tja Punkt ist, brauche das nicht für C#, Java, C, C++, Delphi, FreePascal, TurboPascal, VB, Dolphin Smalltalk machen und ’ne Zillion von Libraries gibt es auch ….

Ich schweig mal höflich über den Stand von IDE für die ach-so-tollen-funktionalen-Programmiersprachen … Ausnahme vielleicht F# auf Windows, aber genau weiß ich das nicht, denn Ocaml fällt bei mir unter den gleichen „Horror“ wie C++ und Perl …

Ich bin der Meinung gute Werkzeuge sollte es auch für Programmierer geben und nein, die Anbieter von funktionalen Sprachen wie Haskell, leisten das nicht. Ernsthaft, wenn es um DBs geht und man, was für Anwender schaffen will, dann ist man mit MS Access besser bedient als mit jeder funktionalen PS.

Man verstehe vollkommen den Erfolg von Java, C# und so um Vergleich, weil diese Sachen einfach nützlicher sind. Und ja es dürfte mindestens ne Million mehr Anwender und Programmierer für MS Access geben als für alle funktionale PS zusammen …

Manch werden mich auslachen, es liegt doch nur an Dir, was Du nützlich findest. Ist das wirklich so? Bin ich da so eine Ausnahme? Die Prediger für die Nützlichkeit von anderen Programmiersprachen sitzen m.E. teilweise auf einem zu hohen Ross‘ , keine Ahnung, ob es an mir alleine liegt, ich glaube nicht. Wenn ich an die Haskell-Evangelisten denke, dann sehe ich meine Meinung bestätigt, die Common Lisper sind leider auch nicht so viel besser … Wer die „Genialität“ der Tools von denen nicht erkennt, ist wohl einfach nur ein dummy …