Chapter 1: Design desktop application

Designing desktop applications is a crucial skill for software developers aiming to create efficient, user-friendly software that runs on personal computers. In Kenya's growing tech ecosystem, desktop applications remain vital for sectors such as banking, education, healthcare, and government services, where offline or locally installed software is preferred. This chapter explores the foundational concepts, development stages, and tools necessary for designing desktop applications that meet professional standards and user needs.

1.1 Desktop application design tools

A desktop application is a program installed on the user's own computer and run from there, such as a job-card program on a garage counter or a booking program at a hotel front desk. Designing one well depends on three things: a grasp of the basic programming concepts that every desktop program uses, a structured process that carries the work from the first request to the finished product, and tools that suit the project. The code examples in this topic use C# and Windows Forms in Visual Studio, because Windows Forms keeps the link between a control, the event it raises and the method that answers it short and easy to read. The same ideas apply in Java Swing, Qt and other desktop frameworks.

1.1.1 Basic desktop application programming concepts

Four ideas sit at the base of almost every desktop program. An event says that something happened, an object holds data and behaviour, a control is an object the user can see and use, and a method is the block of code that does the work. When a cashier clicks a button (event) on a form (a control that holds other controls), a method runs and changes the data held in objects, and the screen is updated to show the result.

Data management and storage

Desktop applications often read and write data in files or databases, so the developer must understand data structures such as lists and arrays, file handling for text and CSV files, and database connectivity. A small single-computer program may keep its data in an SQLite file, while a program shared by several computers in one office may use a database server such as Microsoft SQL Server. Example: a stock program for a hardware shop keeps every item in one SQLite file on the shop computer, so it works without a server and without internet. Planning tables and relationships is taught later in the unit under Designing the Database.

Error handling and debugging

A robust application expects things to go wrong, such as a letter typed where a number is needed, and handles the problem without crashing or losing data. Exception handling with try and catch lets the program show a clear message and carry on, while debugging tools help the developer find faults before the application is delivered. Example:

try
{
    int quantity = int.Parse(txtQuantity.Text);
    // use the quantity here
}
catch (FormatException)
{
    MessageBox.Show("Enter the quantity as a whole number.");
}

If the user types "ten", int.Parse throws a FormatException, and the catch block shows a message instead of letting the program stop. Stepping through code to find faults is taught under Performing Debugging with Tools.

1.1.1.1 Events

An event is a signal that something has happened: a button was clicked, a key was pressed, a form finished loading, a timer ticked or a message arrived from another program. Desktop applications use event-driven programming, in which the flow of the program is decided by these events and not by a fixed top-to-bottom order. After it starts, the program waits in a loop and runs a method only when an event it has asked about takes place. In Windows Forms this loop is started by Application.Run, which keeps the first form open and passes every mouse click and key press to the right control.

An event has four parts:

• Event source: the control or object that raises the event, such as a button named btnAddItem.
• Event: the named signal the source can raise, such as Click.
• Event handler: the method that runs when the event is raised, such as btnAddItem_Click.
• Event arguments: an object, usually named e, that carries details about the event, for example which key was pressed.

The handler is linked to the event by subscribing to it. The Visual Studio designer writes this line when you double-click the button, but it can also be written by hand:

btnAddItem.Click += btnAddItem_Click;

private void btnAddItem_Click(object sender, EventArgs e)
{
    lblStatus.Text = "Item added: " + txtItemName.Text;
}

The parameter sender is the control that raised the event, and e holds its details. A handler can react to what the user is typing. In this example a hardware shop till recalculates the line total each time the quantity box changes:

private decimal unitPrice = 250m;

private void txtQuantity_TextChanged(object sender, EventArgs e)
{
    if (int.TryParse(txtQuantity.Text, out int quantity))
    {
        lblLineTotal.Text = (quantity * unitPrice).ToString("N2");
    }
}

When the cashier types 4, the label shows 1,000.00, because 4 × 250 = 1,000.

Common events a developer meets in desktop applications:

• Click: raised when the user clicks a button, menu item or other control.
• TextChanged: raised each time the text in a text box changes, useful for live totals and search boxes.
• KeyPress: raised when a character key is pressed, useful for blocking letters in a number box.
• SelectedIndexChanged: raised when the user picks a different item in a combo box or list.
• Load: raised once before a form is first shown, the usual place to fill lists and set start values.
• FormClosing: raised when the user tries to close a form, where the program can ask whether to save first.
• Tick: raised by a Timer object at a fixed interval, for example to refresh a clock or check for new data.

One user action can raise several events in a fixed order. Pressing a letter key in a text box raises KeyDown, then KeyPress, then TextChanged, and finally KeyUp when the key is released, so the developer chooses the event that matches the job.

1.1.1.2 Objects

An object is a self-contained item in a program that holds data and the code that works on that data. It is created from a class, which is the blueprint. A class StockItem describes what every stock item has, such as a name, a quantity and a unit price, and each StockItem object made from it holds the values of one real item. This object-oriented approach organises large programs into small, reusable parts that can be tested and changed one at a time.

Every object has three kinds of members:

• Properties: the data the object holds, such as Name, Quantity and UnitPrice.
• Methods: the actions the object can perform, such as StockValue().
• Events: the signals the object can raise when something happens to it.

public class StockItem
{
    public string Name { get; set; } = string.Empty;
    public int Quantity { get; set; }
    public decimal UnitPrice { get; set; }

    public decimal StockValue()
    {
        return Quantity * UnitPrice;
    }
}

var hinge = new StockItem { Name = "Door hinge", Quantity = 40, UnitPrice = 120m };
decimal value = hinge.StockValue();

The keyword new creates the object, and StockValue() returns 40 × 120 = 4,800. A second object, such as a padlock with its own quantity and price, holds its own values and does not affect the hinge.

In a desktop application almost everything is an object. A button, a text box and the form itself are objects with properties such as Text and Enabled. Some objects have no visible part, such as a Timer, a database connection or a file reader, and they are called non-visual components.

These principles and benefits of object-oriented programming make objects useful:

• Encapsulation: an object keeps its data private and offers only the properties and methods that are safe to use, so other code cannot put it in an invalid state.
• Inheritance: a new class takes the members of an existing class and adds its own. Every Windows Forms control inherits from the Control class, so all of them share properties such as Visible and Size.
• Polymorphism: different objects respond to the same method call in their own way. Calling ToString() on a number, a date or a StockItem runs the version that belongs to each type.
• Abstraction: the programmer works with what an object does and not with how it does it, as when calling MessageBox.Show without knowing how the window is drawn.
• Reuse: a class written once, such as StockItem, can serve the stock screen, the sales screen and the reports.

1.1.1.3 Controls

A control is an object that shows information to the user or takes input from the user. Buttons, text boxes, labels, lists, grids and menus are controls, and together they form the graphical user interface (GUI) of the application. Good use of controls gives intuitive navigation and makes the program usable with little training. In Windows Forms every control inherits from the Control class in the System.Windows.Forms namespace, so each has properties such as Name, Text, Enabled, Visible, Location and Size.

Controls are placed in the form designer. The developer drags a control from the Toolbox onto the form, sets its properties in the Properties window and double-clicks it to write the handler for its default event. Each control gets a meaningful name with a short prefix that shows its type, such as btnSave for a button, txtCustomerName for a text box and lblTotal for a label, so the code stays readable.

Controls fall into groups by what they do:

• Command controls: buttons, menus and toolbars that start an action.
• Input controls: text boxes, combo boxes, check boxes and radio buttons that collect data from the user.
• Display controls: labels and picture boxes that show text or images.
• List and data controls: list boxes, list views and data grids that show many items or records.
• Container controls: panels, group boxes and tab controls that hold and arrange other controls.

Because controls are objects, they can also be created and placed by code while the program runs. Example: an order form for a tailoring workshop adds a Clear button when the user starts a new order.

private void ShowClearButton()
{
    Button btnClear = new Button();
    btnClear.Text = "Clear";
    btnClear.Location = new Point(20, 60);
    btnClear.Size = new Size(80, 28);
    btnClear.Click += btnClear_Click;
    Controls.Add(btnClear);
}

The Controls.Add call is what puts the new button on the form. The individual controls, their properties and their events are taught in detail later in the unit under Types of controls and objects.

1.1.1.4 Methods

A method is a named block of code that performs one task. It may take values in, called parameters, and may send a value back, called the return value. A method that sends nothing back is declared void. Writing the code of a program as small methods, each with one job, makes it easier to read, test and reuse, and an event handler is itself a method that runs when its event is raised.

A method has a signature made of its return type, name and parameters:

private decimal CalculatePrintCost(decimal pricePerPage, int pages, int copies)
{
    return pricePerPage * pages * copies;
}

Calling CalculatePrintCost(5m, 20, 3) for a printing shop job of 3 copies of a 20-page document at Ksh 5 a page gives 5 × 20 × 3 = 300, so the method returns 300. The caller can store the result:

decimal cost = CalculatePrintCost(5m, 20, 3);
lblCost.Text = "Ksh " + cost.ToString("N2");

Methods fall into these groups:

• Built-in methods: methods that ship with the framework and the controls, such as txtName.Clear() to empty a text box, txtName.Focus() to move the cursor into it, MessageBox.Show(...) to display a message and Close() to close a form.
• User-defined methods: methods the developer writes for the program's own tasks, such as CalculatePrintCost.
• Constructors: special methods with the name of the class that run when an object is created with new and set its starting values.
• Overloaded methods: several methods with the same name but different parameters, so Print(string text) and Print(string text, int copies) can both exist.
• Static methods: methods called on the class itself and not on an object, such as int.TryParse.

1.1.2 Application development stages

Developing a desktop application follows a structured process from the first request to the finished product. Each stage has its own purpose and produces something that the next stage uses, so a mistake caught early costs far less to put right than one found after delivery.

Requirement analysis

This first stage gathers and records what the users and other stakeholders need the application to do. The output is a requirements document or a list of user stories. Example: for a car wash, the developer finds out that the owner needs to record each wash, see the takings of each service and print a daily takings summary, and writes each need down so it can be checked later.

Design

Design plans the architecture of the application, the layout of each screen and the way data flows between screens and storage. The output is design documents such as wireframes, data flow diagrams and a database plan. Clear design documents guide every developer on the team and reduce guesswork, especially when several people write different parts of the same program.

Implementation (Coding)

During implementation, developers write the source code according to the design. Following agreed coding standards, such as consistent names, short methods and comments where the reason is not obvious, keeps the code maintainable and lets it grow without becoming tangled. The output is working code kept in version control.

Testing

Testing checks that the application does what the requirements say and finds defects before the users do. Several kinds of test are used, including unit, integration, system and user acceptance tests, and each finds a different kind of fault. The output is a test report that lists what passed, what failed and what was fixed.

Deployment and maintenance

Deployment makes the application available to the users by installing it on their computers and configuring it. Maintenance then continues for as long as the application is used: faults are fixed, updates are issued and new features are added as the business changes. An application that keeps a small business's records, for example, must be updated whenever a new report or a new tax rule is needed.

1.1.3 Identifying Desktop Application Design Tools

The right tools depend on the project requirements, the developer's skills and the computers the application will run on. Identifying them early speeds up development and avoids changing tools half way through a project. The main groups of tools are listed below.

Integrated Development Environments (IDEs)

An IDE combines a code editor, a compiler, a debugger and build automation in one program. Examples include Microsoft Visual Studio, Eclipse and JetBrains Rider. Visual Studio is widely used for C# desktop applications because it includes a form designer and a debugger.

GUI design tools

GUI design tools let developers build and preview screens without writing every line of layout code. Qt Designer and the Windows Forms Designer allow drag-and-drop placement of controls, which makes interface work faster and lets the developer see the result at once.

Version control systems

Tools such as Git and Subversion record every change to the code, show who made it and let the team return to an earlier version when a change causes trouble. They are essential in team projects, where several developers edit the same code base. Using them well is taught later in the unit under Documenting Source Code Changes.

Database management tools

Tools such as SQL Server Management Studio and SQLite Studio help design, view and manage the databases that desktop applications depend on. Using them to inspect tables while testing helps keep data consistent and queries efficient.

Debugging and profiling tools

Debuggers built into IDEs, or standalone ones, help find and fix faults. Profiling tools measure how much time and memory each part of the program uses, which matters for resource-heavy applications such as a program that prints thousands of labels for a warehouse.

1.1.4 Overview of desktop application design tools

A broad view of the available tools lets the developer pick the right one for each job. The table lists common tools with their capabilities and typical uses.

Visual Studio is used to build Windows Forms and WPF applications for Windows computers. Qt Creator suits applications that must run on more than one operating system from the same code. Xamarin, the earlier tool for this job, reached end of support in May 2024, so new projects use .NET MAUI.

1.1.5 Criteria for selecting tools

The choice of tools affects development speed, application quality and how easily the application can be maintained. The developer weighs each candidate tool against criteria drawn from the project and from the client's situation.

Platform compatibility

The tool must support the operating systems the application will run on. An application meant only for Windows computers is well served by Visual Studio, while a program that must also run on Linux computers points towards Qt Creator.

Language support

The languages a tool supports should match the skills of the team and the needs of the project. A team that already writes Java will be productive in Eclipse, while a team that writes C# will choose Visual Studio or Rider.

Community and vendor support

Strong community or vendor support brings regular updates, bug fixes, documentation and answers to questions. A tool with active forums and thorough documentation is easier to learn and to rely on for years.

Integration with other tools

A tool that works smoothly with version control, database tools and testing tools makes the whole workflow quicker. Visual Studio, for example, works with Git and Azure DevOps from inside the same window.

Cost and licensing

Budgets limit the choice, especially for start-ups and small firms. Open-source tools such as Eclipse and SQLite Studio cost nothing to use, while commercial tools may charge for licences but offer support and extra features, so the developer should read the licence terms before choosing.

1.1.6 Case studies of tool selection in real-world applications

Each case below is a hypothetical example that shows how the criteria lead to a choice. The same project can lead to different tools when the team, the budget or the computers are different.

Stock and billing program for a hardware shop

A small software firm is asked to build a stock and billing program for a hardware shop whose computers all run Windows. The developers know C#, so they choose Microsoft Visual Studio with Windows Forms, because it has a form designer and a debugger, and use SQL Server Express for the data. Platform and language criteria decided the choice.

Label printing program for a printing shop

A printing shop wants the same program to run on its Windows office computers and on a Linux computer in the workshop. The developers choose Qt Creator and C++, because Qt builds the same application for both systems and can be used under an open-source licence, which keeps licence costs down when its terms are met. Platform compatibility and cost decided the choice.

Parcel handling program for a courier office

A courier office needs a modular desktop application, and its development team writes Java. They choose Eclipse with JavaFX for the screens, because the language fits their skills and the application can be divided into separate modules. Language support decided the choice.

Booking program for a salon

A salon owner wants a low-cost booking program kept on one computer. The developer uses SQLite Studio to design the database and Git for version control, both free and supported by large communities, so the project stays within a small budget. Cost and community support decided the choice.

Desktop and tablet program for a small hotel

A small hotel wants its reception software on the front-desk computer and on a tablet that staff carry around. The developer chooses Visual Studio with .NET MAUI, which lets most of the code be shared between the Windows and mobile versions, so the work is done once and maintained in one place. Integration and code sharing decided the choice.

Chapter Summary

This chapter explored the essential tools and concepts involved in designing desktop applications, beginning with fundamental programming elements such as events, objects, and controls. It outlined the stages of application development and provided a detailed overview of various design tools, alongside criteria for selecting the most appropriate ones, supported by real-world case studies. The process of designing application functionality was examined through techniques for gathering user requirements, translating these needs into application features, and prioritizing functionality based on user feedback. Attention was given to creating effective user interfaces, emphasizing principles of design, the use of wireframes and prototypes, and the importance of user testing to refine the interface. The chapter also covered the design of application output, discussing different types such as reports and visualizations, the qualities that define good user output, and methods for testing and validating this output to ensure reliability and usability. Together, these topics provide a comprehensive foundation for developing desktop applications that meet user needs and perform effectively.