Text and code by Ron Maupin.
I had to build my enhanced INI class that replaces the database. My Modula-2 version used a doubly-linked list (section) of doubly-linked lists (key/value pairs) for the INI. Delphi’s generics made this much easier, and I now use the TDictionary, although it could be done with TStringList. I used the Delphi ability to have an array property (IniFile[Section,Value]) to simplify assignments and set it as the default property of the INI object. I also didn’t want to get lost in the weeds of having different properties or methods for different data types, so I built some record helpers in the application for different data types that simplify assignment (IntVar := IniFile[Section,Value].ToInt or IniFile[Section,Value] := BoolVar.ToStr).
A quick look at the todo list revealed: today is the day to add the following new functionality to my Delphi application: allow the user to change the visibility of some user interface elements on a one-could-say very complex form. There are several controls on the form some users could find to be “too advanced” and they basically will never need em. Naturally, users would prefer such elements to be made invisible to make their final user interface experience less complex (messy) – so that they can better focus on those elements that are important to them.
The first idea is simple: let’s provide an enumeration listing those controls that can be hidden by the user. Let’s group those in a set type variable and expose as a property. Add (inside the configuration screen) a list of checkboxes allowing the user to specify what elements he/she wants to see and what should be hidden. All set, let’s do some coding…
In this application I’m saving all application / user specific configuration settings in an INI file. The TIniFile exposes various WriteSomeValueType procedures. There’s no WriteSet. Oh, so the question to solve before we do any coding: “how to preserve (save/load) set type property value in an INI (or in a database) ”
The DelphiZXingQRCode unit, ported from ZXing by Debenu, allows to easily add QR Code generation to your Delphi VCL applications.
While the DelphiZXingQRCode was designed to support VCL applications (and be used in newer as well as in older Delphi versions), it can also easily be “upgraded” for Fire Monkey applications – be it desktop or mobile (Android, iOS).
A QR code (Quick Response Code) is a specific 2D barcode that gained popularity during the last years when mobile phones with cameras allowed mobile phone users to quickly scan the image and get more info on a product, business, event, offer, URL address, …
If you need to include the generation of QR barcode images in your Delphi application, you might want to take a look at Debenu’s open source “DelphiZXingQRCode” – a Delphi port of the QR Code functionality in ZXing, an open source barcode image processing library.
In a Delphi application, the THintWindow class implements the small pop-up window that appears over a control at run time, when the control has its ShowHint property set to True (and has a value assigned to the Hint property).
The implementation of the THintWindow (at least what gets displayed by it, not how) is rather simple: it will display whatever string value is assigned for the Hint property of a control. If you want more control over what gets displayed by the hint window, and how, and when the hint window will popup – you can create your own version by extending the THintWindow class.
To use your own hint you would assign your own class to the global HintWindowClass variable at application start-up time, so that the new hint window type is used for hints. You can even fine tune the display of the hint window just before it pops-up using the OnHint and OnShowHint events of the TApplicationEvents.
That’s all nice and clear. But, what if the control you are using is Virtual Treeview which has its own version of the hint window implemented in TVirtualTreeHintWindow? What if you want to extend this by including some graphics along with the text that the hint window displays? Further, what if you need to have different hint values for every node displayed by the tree?
Of course, you are not working on a new application – all logic is already there, lots of methods and events already implemented.
The answers: here’s how to simply extend both the TVirtualTreeHintWindow and the TVirtualStringTree to add some node specific graphics to the hint window displaying node specific hints.
Finally, the sample project for my full text search implementation in Delphi is ready. The idea involves providing a user of my application the ability to do full text (Google like) searches on a set of documents by searching inside document content. For the task, I’ve selected SQLite for the database and FireDac for the database connectivity and operations.
As a second step in my goal to implement full text search functionality in my Delphi application I had to create a sample SQLite database supporting FTS queries.
Full text search models in databases allow to do what Google does with web documents – quickly search for documents containing some word (token).
Ah … real world problems require some proof-of-concept almost-finished implementation solutions.
This time I’m into figuring out what would be the best way to introduce full text search in one of my Delphi applications.
Starting with Windows Vista (and Windows Server 2008) the Windows API arsenal has a new and more powerful way of performing file operations like copy, move, delete and similar file and folder shell actions. The old (but still valid) SHFileOperation function is now replaced by the IFileOperation interface.
The IFileOperation exposes methods to copy, move, rename, create, and delete Shell items as well as methods to provide progress and error dialogs.
I’m a huge fan of one big gem in the Delphi third party controls arena: Virtual Tree View.
Whatever issue I had to solve in my applications harvesting the power of the TVirtualStringTree, the component had the answer, either through vast amount of properties or through nicely exposed events.
The only solution I was not able to find straight forward, or out of the box, is how to have a visual indication that the currently focused node is not visible in the tree. Not “not visible” as hidden but not visible as currently not in view.