Tag Archives: oop

Partially Reimplementing / Overriding Interface Implementation

1 Reply

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.
Continue reading →

Memory 3D – Full Source Code Delphi Game

1 Reply

Memory3D“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.
Continue reading →

Coding a Game of Memory in Delphi – The User Interface

Leave a reply

Delphi Memory game in actionIn 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.
Continue reading →

Coding a Game of Memory in Delphi – OOP Model

Leave a reply

Memory game vs robot at CosmoCaixa, Barcelona 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.
Continue reading →

Delphi Interceptor (/Interposer) Classes -> TButton = class(TButton)

6 Replies

Have you ever needed for a specific Delphi control, like a TButton, to have just one more property or a method that is a “must have” for your current application?

Most Delphi developers, when they need a TMySuperButton, would either look for a third-party VCL solution or would try creating a derived control.

What if you do not want to have this MySuperButton permanently in the Component/Tool Palette – since it solves one problem only for this particular application you are developing?

What’s more … how about having a TButton with more properties and methods, some application specific extra behavior, and not TMySupperButton?

How about extending what TButton has without the need to create a derived class with a different name?
Continue reading →

The (Open) Case Of Dangling Pointers (Invalid Object References) In Delphi

25 Replies

dangling-pointer-delphiI guess you might not know what the term “dangling pointer” means, but if you have ever done some more complex programming in Delphi (where you do not only put controls on a form and handle a few events – rather you create and use objects at run-time) you might have experienced weird Access Violations when you tried accessing properties of an object you though is “Assigned” (or not nil).
Continue reading →