Quite some time has passed since working with multiple threads was introduced in Delphi (Delphi 2, way back in 1996). The TThread class at that time was a very lightweight wrapper around the Windows CreateThread function. Those “crazy” enough to venture into the world of parallel executing code aka multi-threaded applications know how (proper) writing and debugging of such applications can become frustrating (at least).
Some more time has passed, and in Delphi XE7, Parallel Programming Library (PPL) was introduced to simplify the efforts we have to invest when there are needs to have more tasks (a unit of work you need to get done) being executed at the same time / in parallel.
If, until “now”, you were afraid of even trying to understand how to implement parallel programming in your applications – you should not be so. I think each and every application can benefit in some way of code being executed in multiple treads. The “Using TTask from the Parallel Programming Library” from Embarcadero’s DocWiki has more than enough to get you started.
I’m not going to list examples when multi-threading can come handy – I’m certain all this is known. Also, I’m not going to repeat the words of so many who wrote articles and blog posts (here’s one and another) explaining what TTask is, how VCL is not thread safe and how you need to use some synchronization to update the UI of the application (being run in the main thread), how to wait for all tasks to finish their execution or how to speed up your loops using TParallel.For.
In Delphi, the reserved word “interface” has two distinct meanings. In a Delphi unit, “interface” denotes the start of a unit section used to declare public constants, data types, variables, procedures and functions visible and accessible to other units using this unit. In OOP jargon, an “object interface” or simply “interface” is a kind of a class with no implementation (but not like a class with abstract methods). An interface defines methods that can be implemented by a class (a class “implements” the interface). Object interfaces might be used when multiple inheritance is needed, and are frequently used when working with COM objects. For some intro to interfaces: Interfaces in Delphi Programming 101.
Delphi’s TComboBox combines an edit box with a scrollable list – with the Style property defining the display style of the combo. When set to csDropDownList there’s no edit box – users can only pick from the predefined items displayed by the list. If you need to react, when the selection changes, you will write code for the OnSelect event.
Now, presume our combo is a kind of a filter selector – when the selection changes you need to update some other UI control. For example, combo lists invoices and selecting one (item from its list) displays the selected invoice items in some grid control.
Depending on the number of invoice items, where they are stored, how you fetch them, and so on – the actual code to (fetch items and) refresh the UI might take longer time – whatever longer means. If you scroll quickly through the combo items – OnSelect will get fired for each visited item in the list and your application might appear irresponsible, lagging and slow.
One of the common problems we programmers face (and hopefully we are aware of) are memory leaks, or leaks of any other kind of resources. For example, Windows limit the number of GDI or USER32 objects that a process can allocate at one time. When things go down the wrong road you would want to have the tools to help you find (again) the correct path to free-what-you-create.
“If you want it to be playable and more interesting you need to jazz it up a bit!”
That’s what’s been cooking in my head from the time I’ve finished implementing the back end for the game of Memory (Match Up, Concentration, or whatever you are used to call it). As a proof of concept, I’ve coded a very simple application, aka the front end for the game – juts to have a workable user interface.
Now, the time has come to finish the series and introduce a more eye candy version of the game, one that’s not using dull buttons with numbers for field display values but that actually looks like card game type of Memory, with nice fancy images/icons for game fields. Why stop there? Why not go a step forward and introduce a new dimension for the game: make it 3D having fields appear on planes/layers, so players need to switch between planes to match a pair.
I guess you know you can run your browser in full screen mode using the F11 shortcut key. Windows Explorer also supports this feature.
Running in full screen, where an application UI covers the entire screen, over the TaskBar and any Desktop/Tool bars, is handy when a user has a limited screen size (laptops) or when you just want more to be visible by the browser or the Windows Explorer.
Running your application in full screen might also be handy if your users want to be focused only on your application’s window.
In my previous post, Coding a Game of Memory in Delphi – OOP Model, I’ve been developing the model, aka the back end, for the Memory (Match Up, Concentration, …) game. The idea was to separate the game logic from the user interface (aka the front end). As a result a few classes were introduced: TPlayer, TField and, of course, the main class/object TMemoryGame implementing all the code required to run the game.
Having only the model does not help us much if we actually want to play the game. Therefore, this time, we go into building the user interface in Delphi.
Since the TMemoryGame class is framework agnostic (and not platform specific), it is up for you to decide if you would like to do a classic Windows VCL application, a FireMonkey Android mobile game or something that works on a Mac. To make it quick and simple, I’ll go old-style VCL school.