One of my current projects I work on in my sparetime is Pecunia, which is an OSX app to manage multiple online banking accounts, organize financial data and provide answers about your money (e.g. monthly income and where it is spent). Pecunia is open source on Github and also available free of charge from the OSX appstore. Read in the README.md file why this is mostly useful for german users only and hence the Pecunia homepage is german-only.
One part of this application is a Swift library to managed IBANs (International Bank Account Numbers) and related data (like the BIC and other financial institutes data, e.g. the name, address etc.). It helps to create valid IBANs for bank codes and account numbers and helps with their validation. The name of this library is IBANtools and in this blog post I'm going to explain it and how it can be used (not only for german users).
One of the most common features in a code editor is without doubt code completion (aka auto completion). Every programmer has seen this before and an explanation is no longer necessary. Still it makes sense to recall what *exactly* code completion is supposed to do. It should provide the programmer with a list of strings that can appear at a given position in the code (usually the one where the caret is). It is also sensible to require code to be syntactically correct up to the invocation point. Otherwise it is really difficult to predict what the user wanted to write actually.
Implementing code completion is a non-trivial task and there are different approaches possible. This posting describes a way to accomplish that with relatively few core code, as I have done it in MySQL Workbench. It delivers very precise results and requires only few changes to adjust it to different languages.
Virtual Treeview 5.4.0 has been released and with that release I'll step back officially from maintaining the Virtual Treeview component. I moved to C++/C#/Objective-C projects a few years ago already and have hence no motivation to develop the control further. I simply don't use it anymore.
GraphicEx has not got much love in the past years but there are still quite a number of users who still have it in their code base. This however means GraphicEx must be updated to compile with the latest compilers/IDEs. Additionally, some bug fixes have been incorporated, plus some enhancements, creating what I internally called GraphicEx II. So far however I have never found the time to publish those changes.
Years ago I was working on a project that required XML files to specify a graphical user interface (GUI) based on SWT and Eclipse, written in Java. Comming from the Windows world and being familiar with resource files I thought it would be a cool idea to use those resource files (*.rc) to generate the GUI dialogs. This would allow reusing already designed dialogs to save some time. For this task I needed a parser that was able to recognize the content of resource files.