Schlagwort-Archive: VBA

Hat sich kaum geändert

Wünsche und Beschwerden …

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 schweige mal höflich über den Stand von IDE für die ach-so-tollen-funktionalen-Programmiersprachen … Ausnahme vielleicht F# auf Windows

Ich bin überzeugt 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 …

Sieht so aus

Als ob ich zum Ende meiner Refaktorierung komme. Es scheint, ich konnte 4 verschiedene Formulare mit 4 verschiedenen Abfragen auf 1 Form mit 1 Abfrage umprogrammieren. Es ist IMHO hilfreich, das Wissen was man hat, in Objekten/Strukturen unterzubringen. Der Code ist bislang nicht perfektioniert, aber immerhin statt 4 Formen mit Code von 120 Zeilen ist es nur noch eine Form mit rund 140 +/- 20 Zeilen.

So sieht der ersetzte Code aus:

'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_DruckAngebot_Click
'    End If
'End If
'
'' Firma Beller
'If strKundeNr = "143" Then
'    strBericht = "BR_DruckAngebotAnkErz_Bel"
'Else
'    strBericht = "BR_DruckAngebotAnkErz"
'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
'    DoCmd.OpenReport strBericht, acViewPreview
'Else
'    Tabelle1.MoveLast                     ' Letzten Datensatz suchen.
'    setzeFelder Forms!HF_AuftrAnkErz, Tabelle1, DRUCK_BEREICH_ANGEBOT
'    erhoeheNummer Tabelle1, "AngebotNr"
'
'    Forms!HF_AuftrAnkErz!AngebotKz = True   ' Setzen der Druckkennziffer
'    Forms!HF_AuftrAnkErz.Refresh
'
'    ' Logbucheintrag
'    If DLookup("[Benutzerverwaltung]", "HT_SysParameter") = True Then
'        Call SetzeBenutzerLog("Drucke Angebot m. Summen Ankauf Erz.-Preis! Auftrag Nr: " & CStr(Forms!HF_AuftrAnkErz!AuftragNr) & ", Angebot Nr: " & CStr(Forms!HF_AuftrAnkErz!AngebotNr))
'    End If
'End If

Also grob 4 * 120 = 480 (es kommen wahrscheinlich noch ein paar Zeilen dazu, wegen eines Berichts, der genau auf die Anforderungen eines Kunden zugeschnitten war, die Logik ändert sich aber nicht, auf, sagen wir mal 160 LOC, 60 – 70 % weniger Code. Macht bei 500 000 Loc rund 600 / 500 000 * 100 = 0,12 % 😉 und 3 Formulare weniger … Nicht beeindruckend, wenn man aber betrachtet, in wie vielen Bereichen man das erreichen könnte. Wäre eine erste Schätzung, daß man den Code auf 160 / 600 = 26,6 % runter brächte, was dann auf gerade mal 125 000 Zeilen von Code hinausliefe, ohne Einbußen bei der Funktionalität. Wenn man dann noch die extrem aufwendige Übergabe an diverse Buchhaltungssysteme auf Datev herunterschraubte (was wohl jede Fibu in D einlesen kann) … Da kann man mal sehen, was nur eine andere Strukturierung an Vorteilen brächte und wie viel weniger Fehler gäbe es und wie viel einfacher wäre eine Korrektur? Sollte ich mal einen Fehler in den Angeboten finden, bräuchte ich nur eine Methode ändern statt … Mal sehen wie’s weitergeht. Es kommt wohl etwas dazu, weil es das Ziel ist, alle Reports auch als Email versenden zu können. Mal schauen…