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.
Memory, Match Up, Concentration … there are many names for a simple card game I’m certain you’ve been playing with your friends at some point during your childhood. I’m also certain you are still playing it from time to time (at least I do with my kids). Just a few months ago, I’ve tried my “luck” against a robot in CosmoCaixa, Barcelona (image).
The rules of the game are simple: cards are laid face down on a surface and two, per turn, are flipped face up. If the flipped cards are a match pair (same looking, same rank, save value) the player claims (wins) the pair and plays again. If they are not a match, cards are flipped face down again, and the next player takes turn. The game ends when all the pairs have been claimed and the player with the most claimed pairs is the winner. If all players have the same number of claimed pairs we can agree to have a tie, or to have the last player be the winner.
I’ve always been a fan of such simple games – from my point of view they are a perfect pick if you want to start learning programming – have fun and sharpen your developer skills at the same time.
While there are Delphi implementations of the game you can find online – most of them have heavily mixed the visual presentation of the game (user interface) with the model (implementation of the game logic).
In my version of Memory, I’d like to separate the user interface (front end) from the game logic (back end) as much as possible. I want to create a game model in OOP style – where the game logic does not interact (or as less as possible) with the front end.