Developing applications that use multiple monitors in Delphi

Windows can map multiple monitors to virtual desktops so that we can use this to design a handy application.

PowerPoint, for example, gives full play to the dual-monitor advantage (which most laptops support), it can play slides on one monitor, and a note on another displays to control the playback process, so that users can make business speeches with should also launch. So how do we develop this application? This article will show you if you use Delphi to implement a multiple monitor application.

Windows also supports cloning display, with each display outputting the same content, which is also useful for some applications. Some graphics cards also support two monitors, but they are not really a multi-monitor, but virtual high-resolution display mode (such as 2048x768 or 1024x1536), through the video card to display the screen to two monitors respectively. Both of these display modes are not the Zhongdian described in this article, and are also very simple, so we will not repeat them.

Windows supports up to 10 monitors, and Windows maps all displays to a large virtual desktop. You can interpret the monitor as a partial view of the desktop. These displays can be arranged arbitrarily in the display properties according to the physical location of the monitor. If the display is irregular, some parts of the virtual desktop may not be visible on any one of the monitors. To keep one form from appearing between two monitors, Windows takes a monitor as the primary display. When you start your computer, the logon dialog box appears on the primary monitor. The vast majority of program launches are shown in the primary monitor.

According to the above introduction, it is not difficult to find a few important concepts: desktop, display, the main display and so on. First of all, we must understand these concepts and their previous relationship. This is the key to mastering a multi-monitor application development approach. Understanding these concepts, the rest of the section is very well understood.

The desktop actually refers to the logical area that Windows can display. You can actually display a form outside of your desktop. This does not mean, however, that all parts of the desktop are displayed on a single display (as explained earlier), but conversely, any display of a display is necessarily part of the desktop.

The desktop is a rectangular area that can be used to describe the size of the desktop through vertex coordinates (TOP,LEFT) and wide height. Why do we need vertex coordinates? Because vertex coordinates are not taken for granted (0,0). So where is it (0,0)? It's a long story, but let's take a look back at a concept we just mentioned-the main monitor. Windows wants general programs to be initially displayed to the primary display, because people are accustomed to focusing on a display that is closest to them. Windows is also unlikely to force users to use the leftmost display as the primary display, so the application needs to be calculated to show itself to the main display. However, most users have only one monitor (two displays are too much of a place), and the general application does not want to go to great lengths to calculate where the main display is and where it should be displayed. So Windows proposes a reasonable solution: take the vertex coordinates of the main display as the origin of the coordinate system. As a result, ordinary programs need to be considered in a single display environment.

The monitor is a local view of the desktop. It's like looking out the window through the windows and standing in front of different windows can see different pictures. Similarly, the display is also a rectangular area, which can also be described by vertex coordinates (TOP,LEFT) and width-height. Vertex coordinates are relative to the origin of the desktop coordinate system, that is, the vertex relative to the primary display.

The concept of a workspace is simple, which refers to a rectangular area in the monitor except for the taskbar and other forms docked on the desktop.

Windows provides a set of APIs for the development of multiple-monitor applications. The VCL encapsulates these APIs and is naturally integrated into the entire framework, making it easy to develop multiple-monitor applications. Here is a description of what's relevant.

Among the VCL, I am afraid that Tcustomform is the most familiar, and it is the base class of all forms. The Tcustomform position property is used to set the real position of the form, and two of its optional values are worth caring for: one is Poscreencenter, and when the Position property is set to Poscreencenter, The window is displayed to the center of the main display, the other is Podesktopcenter, and when the Position property is set to Podesktopcenter, the form is displayed in the center of the entire desktop. If you set this property to Podesktopcenter, and the program runs on a system with multiple monitors, the window will show up between two monitors, causing unnecessary trouble to the user. Therefore, even if our program is not designed for multiple monitors, we should handle this value carefully. Another property is Defaultmonitor, which is similar to the position and determines which monitor the window initially displays. It has four alternative values: Dmdesktop,dmprimary,dmmainform and Dmactiveform. Their meaning is as follows:

Value

Meaning

Dmdesktop

No special treatment

Dmprimary

Displays the form to the first monitor. This is again a trap, literally understood to be the primary display, and in fact it refers to screen.monitor[0] this monitor.

Dmmainform

Display a form to the monitor on which the main form resides

Dmactiveform

Display a form to the monitor on the desktop where the active form resides

Tcustomform also has a read-only common property (without published) monitor, which provides access to a reference to the display instance of the form, which is closely associated with Defaultmonitor.