HOME > RSS Feeds > Delphi Kylix
Add To:  Subscribe with My Yahoo!  Subscribe with Google  Subscribe in NewsGator Online  Subscribe in Rojo  Subscribe with Pluck RSS reader  Subscribe with Bloglines  Add to AOL Subscribe to this feed using your favorite reader  

 
Loading an XML Document into the DOM
In this article we will look at the code that we used to create a program that enabled us to load an XML document into DOM. This article is the fourth part of a four-part series that covers Delphi, XML, and the DOM.

Delphi Wrapper Classes and XML
In this article we will look at a partial listing of the xmlintf unit and then write a program to demonstrate how to use DOM in Delphi. We began our discussion of this topic in the previous article. This is part three of a four-part series.

Delphi and the DOM
Welcome to the second part of a four-part series on Delphi and the DOM. In the first article, we discussed Delphi and XML. Now that you have some idea of the core elements of XML documents, we can talk about how to manipulate them in Delphi.

Delphi and XML
Extensible Markup Language, or XML, is a simplified version of SGML. It is currently receiving a lot of attention. XML is essentially a markup language, meaning that it uses symbols to describe its own content. It also enables you to identify and organize your information in a more accurate and flexible way. This article is the first in a four-part series that introduces you to using XML with Delphi and the DOM.

Internet Access: Client Service
When a workstation is switched on in our Internet cafe we need to have a way of ensuring that the client application, which communicates with the server, is also started. There are two ways of doing this: manually and automatically. You will probably want the application to load automatically. Windows services will let us accomplish this task. Keep reading to find out what they are and how to use them.

Finishing the Client for an Internet Access Control Application
Last week we began our discussion of the client side of an Internet access control program. This week we'll continue to cover the important parts of the code. We'll start with the reading thread, then go to the ini file. Keep reading to be enlightened.

The Client for an Internet Access Control Application
Recently we finished a series covering the server side for an Internet access control application; now we're ready to take on the client. The client application is what the Internet users will see shortly before a workstation is activated or when a session is completed. It is responsible for both time and user access management as you will see in the rest of the series. Crucially, it is also responsible for processing all communication between itself and the server.

User Management for an Internet Access Control Application
In this part of the Internet access control application, we are going to discuss the last section of the server application that deals with user management. The term user management is somewhat misleading in the context of our application because it is not actually users of the Internet café that we are referring to, but rather the staff members. This section will deal with how staff members allocate Internet sessions to users and also how staff members with administration level access can add, remove and change new staff member details.

Important Procedures for an Internet Access Control Application
In the preceding article we started to explore the code that makes up the server communication. If you haven’t read that article, please make sure to do so, because almost everything that I will be discussing in this article will directly reference code that we discussed there. A lot of the things that we will be discussing here will make sense once you have read the previous article.

Server Code for an Internet Access Control Application
In the preceding article we dealt with the functional requirements of the server application as well as with the components that make up the server interface. In this article we will continue to build on the concepts that we discussed there and at the same time explore the code that runs the server application.

Constructing the Interface for an Internet Access Control Application
In this third part to a six-part article that shows how to build an application for Internet access control, such as you might find in an Internet cafe, we will mainly be dealing with the functionality of the main server application. This is the application that will provide us with both the interface and capability to manage client sessions.

Building a Server Application for an Internet Cafe
If you're building an Internet access control application, such as you might find in an Internet cafe, you can't do it without some way to keep track of the staff members who log users into the computers. This article, the second part of a six-part series that covers the entire application, will deal with user authentication, including the setting up of a database to track the important information.

Building an Internet Access Control Application
If you’ve ever visited an Internet café, you've noticed that there is usually a timer on the screen that tells you how much time you have left to use the Internet. In this series of articles we will discuss both the underlying architecture of such an application as well as the code involved, culminating in creating an example application.

Client Dataset: Working with Data Packets and Applying Updates
This article is the fifth part of my series on the Client Dataset available in Delphi. It will focus on how to work with data packets by using the features of client dataset/dataset provider components.

Using the Client Dataset in an N-Tiered Application
My last two articles demonstrated the use of the client dataset in a two-tier application. The two-tier architecture may be effective in some situations but in many circumstances it suffers from some serious drawbacks. This is where the concept of an n-tiered or multi-tiered architecture comes in.

Using the Client Dataset in Two-Tiered Client/Server Applications
Client-server based applications have a number of advantages over file-based applications. To make such an approach work, however, the client dataset requires a provider component. This article will introduce you to the dataset provider component.

Using the Client Dataset in File-Based Architecture
A client dataset can be used as a fully functional file-based dataset in a single-tier application as well as the client part of a multi-tiered application. A file-based application is the simplest form of database application, and it does not require a database server to save data in. Instead, it uses MyBase, the ability of client datasets to save themselves to a file and to load the data from a file.

Demystifying the Client Dataset
The TClient Dataset component available in Delphi encapsulates a lot more features than one would expect from a dataset component. TClient DataSet is a specialized component that holds data in-memory and can be used effectively in different application architectures. It does not require a database connection to work and for that reason it is suited to file-based application architecture.

Working with INI Files in Delphi
Microsoft has taken steps to phase out .ini or initialization files, but they are too useful in too many situations to completely disappear just yet. For example, there are specific cases where you would want to use an INI file when developing a cross-platform application. This article explains how to create and use an INI file in Delphi.

Creating Data Link (UDL) Files in Delphi
The connection string required to connect to a database server may be created during design time or run time. There are circumstances under which you may want to store the connection string entirely outside the application, however. In those instances, Microsoft Data Link files are useful, as this article will explain.