... and news regarding Access- und Delphi-Development
Dear users and customers in Russia and Belarus Please understand that we will currently not accept any orders from the Russian Federation or Belarus during the current conflict and the illegal invasion of Ukraine. Also we will not offer any support or technical assistance for the affected countries. We feel obliged to support the wide network of sanctions and to take a clear stance. #StandWithUkraine
Mit schöner Regelmäßigkeit werde ich auf Konferenzen und Events gefragt, mit welcher Sprache OASIS entwickelt wird. Wenn ich dann antworte, dass ich mit Delphi entwickle, ernte ich oft fragende Blicke, Stirnrunzeln und Verwunderung.
Warum denn ausgerechnet Delphi und nicht C#, C++ oder VB.Net?
Die Antwort ist eigentlich reichlich trivial: Weil ich's kann :-) Nein, nun mal im Ernst: Natürlich ist der Hauptgrund, dass ich Delphi im Gegensatz zu den anderen genannten Sprachen einfach besser beherrsche. Das schreibt sich fast so leicht runter wie VBA ... ganz einfach weil ich beide Sprachen fast täglich verwende.
Aber es gibt noch einen weiteren - für mich persönlich ganz wichtigen - Grund: Ich hasse sämtliche Arten von Laufzeitumgebung. Einer der Gründe, warum ich beispielsweise von Java überhaupt nichts halte. Als Entwickler habe ich keinen Einfluss darauf, welche Version der Java-Runtime auf dem Zielrechner installiert ist.
C# und alle anderen Sprachen aus dem .Net-Umfeld haben prinzipiell den gleichen Nachteil, denn das .Net-Framework ist ja nichts anderes als eine Laufzeitumgebung. Und wenn ich gegen eine bestimmte Version des Framework entwickle und die auf dem Zielrechner nicht installiert ist, muss der Anwender das nachholen.
Und sowohl bei der Java-Runtime als auch beim .Net-Framework kommt das Problem mit den Updates hinzu, auf die ich keinen Einfluss habe. Vor allem bei Java habe ich es bereits des Öfteren erlebt, dass eine Anwendung nach einem Update der Laufzeitumgebung plötzlich den Dienst verweigert.
Die Integration von TortoiseGit und TortoiseHG ist mittlerweile recht gut gelungen und wird inzwischen auch häufig eingesetzt.
Eine Sache ist aber bei der Integration irgendwie unter den Tisch gefallen: Der Assistent wurde nie so richtig mit den neuen Systemen ausgetestet. Auch die Beta-Tester hatten den wohl irgendwie nicht auf dem Schirm. Warum auch? Als inzwischen gestandene Profis in Sachen Quellcodeverwaltung benötigt man den ja auch so gut wie nie. Entwickler sind halt wie immer nur sehr schlechte Tester.
Da der bisherige Assistent nun mittlerweile auch etwas in die Jahre gekommen ist, habe ich beschlossen hier mal grundlegend zu renovieren. Die Komponenten von Developer-Express bieten dazu auch gleich das richtige Steuerelement an, so dass der neue Assistent dann auch in einem modernen, frischen und professionellen Look daherkommt.
Das Design ist soweit fertig, nun geht's an Feinarbeit in Sachen Funktionalität und an die Lokalisierung ...
Neben der kompletten Überarbeitung des Assistenten, die fast einer Neuentwicklung gleichkam, wurden einige weitere Features - vor allem auf Anwenderwunsch - integriert:
In der Einstellungsdatei (*.oasis) eines Projekts kann definiert werden, welche Systemobjekte im Ex- und Importdialog aufgeführt werden. Das ist vor allem dann sinnvoll, wenn jemand auf die Idee gekommen ist seine Objekte mit den Namen "MSys..." zu "verstecken".
In der Einstellungsdatei (*.oasis) eines Projekts kann definiert werden,dass für das Kontextmenü nicht nach verknüpften ODBC-Tabellen gesucht wird. Die führte in älteren Access-Versionen manchmal zu Problemen.
Mit "MethodeVorImport" kann eine Methode angegeben werden, die vor dem Import von Tabellen, Formularen usw. ausgeführt wird. Ist eine solche Methode angegeben, werden die Module als erstes importiert. Mit Hilfe der Methode kann dann z.B. Benutzername/Passwort für die Verknüpfung von ODBC-Tabellen vordefiniert werden.
Außerdem wurden jede Menge kleinerer Refactorings durchgeführt, die die Wartung, Fehlersuche und Erweiterungen erleichtern sollen. Sowas sollte sich eigentlich jeder Entwickler zu eigen machen: Padfinderregel ... hinterlasse den Code immer in besserem Zustand als Du ihn vorgefunden hast.
Warning: DOMDocument::loadHTML(): Unexpected end tag : li in Entity, line: 2 in /var/hosting/web/usr0000002/dev2dev.de/templates/yoo_finch/warp/src/Warp/Helper/DomHelper.php on line 47
Warning: DOMDocument::loadHTML(): Unexpected end tag : ul in Entity, line: 2 in /var/hosting/web/usr0000002/dev2dev.de/templates/yoo_finch/warp/src/Warp/Helper/DomHelper.php on line 47
We use cookies and embedded fonts on our website that are essential for the operation of the site. You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.