home » Auto-Moto » FireMonkey. What to read and see? What is FireMonkey? support for asynchronous HTTP requests

FireMonkey. What to read and see? What is FireMonkey? support for asynchronous HTTP requests

In the context of this blog, this project is primarily interesting because it is implemented on FireMonkey and is an amazing demonstration of the capabilities of this platform. And now, literally last week, the public beta of the product was released. Thus, blog readers can themselves "touch" the really difficult FireMonkey attachment.

A few words about the program. First of all, it should be noted that the current version of Sphere is positioned slightly differently. Yes, sometimes it happens ...

New SphereLive this is not just another messenger. First of all, it is a tool that allows you to effectively organize the educational process. It allows for distance lectures, private consultations, one-to-one lessons and other similar events. Moreover, it is equipped with almost everything necessary for work. Starting with a unique file transfer system and ending with a powerful billing subsystem.

At this stage, the prices for using the product are quite democratic. Subject to a limited number of listeners and a small amount of resources, the product can be used for free.

Naturally, the Sphere uses the main advantage FireMonkey - cross-platform. The application is now available in Windows and MacOS editions. Android version is expected from day to day.

Nevertheless, for me, SphereLive is interesting primarily as an innovative product with a whole range of original solutions. Sometimes it's just like “… wow, how did you do that?” By the way, one of the Sphere developers actively participates in discussions on the FireMonkey forum. In itself, this may serve as an occasion to download the application and discuss technical issues directly with the author. Believe me, there is something to see, there is a lot to learn.

TListView is one of the key components for building a mobile application interface in FireMonkey... This component is not the easiest to use, it often requires a significant amount of code, but it provides the developer with considerable freedom of action. Of course, in applications you can use and TListBoxwhere everything is much easier. But TListBox, perhaps good for displaying a fixed number of records, for displaying data from data sources, you definitely need to use TListView.

The main differences between TListView and TListBox are:

TListBoxItem- control, TListViewItem- no

AT TListBoxItemyou can add any controls using Parent. AT TListVIewItem- no.

TListVIewItemonly stores data for display

TListVIewItemitself renders the stored data through the method Render

Due to the actual manual rendering in TListVIewItem, an increase in speed and low memory consumption is achieved (storing only actual data)

To create your own version TListViewItem, you need to create your own item class, implement the required data (for example, time) in it and create an in-place editor for editing the time, register it, etc.

The very fact of improving performance and reducing memory consumption is a strong argument in favor of using TListView... But there is more.

In many Android I've seen the following implementation of lists in applications. When you click on a list item (Item, if you adhere to the selected terminology), a certain action is performed. Usually a new form is called to edit the data. But Long Tap does a completely different action. And these events do not overlap. In other words, Android applications can clearly distinguish between “long press” and “normal”. Moreover, none of these events are triggered when scrolling the list. A good example is the list of messages in Yandex Mail.

First of all, I want to congratulate all blog readers on the past holidays and wish you all the best in the coming year.

Due to understandable circumstances, I did not begin to make a traditional New Year's report, as well as make any plans for the year. However, life does not stand still, work is being done, and certain events in the Delphi world are happening. I undertake to publish a selection of missed "news from the world of Delphi" during the Christmas holidays in the near future. In the meantime, I'll tell you about the new device that I purchased.

You can find the characteristics on the official website. And the subjective impression is very pleasant. Attention is drawn to the fact that the device is literally stuffed with proprietary software from the manufacturer. And from the sellers got an impressive set of software as a gift. In operation, the smartphone is quite nimble and fully justifies its cost (about $ 200). By the way, I bought my previous phone GSmart 1362 for about the same money 2 years ago. But, as you probably guessed, the main interest for me was how the FireMonkey applications.

Before continuing the story about the timer - two news.

First, the first XE7 update came out. By tradition, it is available to registered users. You can find a list of fixed bugs. I wanted to see how the application behaves in the updated environment. Actually, no corrections had to be made, although the field for experiments remained.

Second piece of news. Embarcadero special offers have been extended until the end of the year:

Well, now directly to the topic of the post. Basically, all that remains for us is to try to run the already created application for Android. For this, we use what I wrote about in previous posts. Namely new. I debugged this application on Nexus 7, respectively added the view of Android 7 ″ Tablet. The design had to be "adjusted" only a little.

Probably only the lazy didn't write their own timer. And in the context of supporting development for mobile platforms, the task of writing a timer in Delphi can be considered a cult in general. So I thought, why, as an example of development FireMonkey applications do not parse exactly the timer. For Android, of course. Of course, this will be exactly my view of the task, which, although not particularly difficult, still has its own nuances. Perhaps you have any comments or suggestions, it would be great to discuss them in the comments. I am by no means an expert in the field of writing mobile applications, so any of your comments will be valuable to me.

We will develop the timer, in the English-speaking sense of this term. That is, the screen will display a dial and four buttons - “Start”, “Pause”, “Stop” and “Cancel”. The countdown will be in the forward direction (i.e., the time will increase). The option in which the time is set and the countdown is running is called Stop Watch in English terminology, perhaps I will try to implement it later. The application we are going to deal with is closer to a stopwatch in functionality.

Delphi XE7, allows us to significantly simplify the development process, due to the fact that now we can create and debug a real application for Win32, and then simply add form views for the necessary mobile devices and, having slightly tweaked them, get a working mobile application. Sounds too pretty to be true? Maybe. But I also want to check this statement by implementing the task.

The more frequently I’m asked my colleagues in private conversations if it’s possible to develop mobile applications in FireMonkey or is it a prototype rather than a production solution?

I think, now I can ensure even the out-and-out sceptics.

My bosom friend and colleague Tagir Yumaguzin told me about the project he took part a long time ago. Now, when this project is in pre-release state, we decided that this description will be interesting for the Delphi community. In the essence, this is a really large project implemented in FM. We are talking about Sphere Live project. A little article devoted to that project was recently published in Habrahabr.ru Alexey Glyzin, chief of ‘’ development department agreed to tell more about the project taking into consideration the audience of my blog.

A.B. - Alexey, in general, what your project is?

A.G.: - The idea has not appeared at once and instantly. Before the ‘Sphere’ project our team had been working on the project where stream audio / video technologies were implemented. Later we created our own software that was able to deliver multimedia streams to an unlimited amount of users including the feedback. But we needed to have a billing feature included.
The application had to comply the several requirements. First, the maximally simplified organization of conferences or transmission to the participants which amount we cannot predict. Second, the most important, is to give to our clients an opportunity to earn with our application and to reduce the complexity of the system, the amount of instruments needed to use to reach the goal. The ease of organization of courses, webinar or just a consultation.

A small notch in memory of FireDAC in the current version Delphi XE6... But first, a few words about where to look for answers to questions regarding FireMonkey... Russian-speaking users are now in a privileged position.

While preparing for the Kharkiv event as part of the RAD Studio XE5 World Tour, I encountered a small problem in working with SQLite through FireDAC... If the database filled in Windows application is transferred along with the application to Android, Cyrillic strings in the database stop being read (question marks are displayed instead of letters). However, if you fill in the database directly on your mobile device, Russian characters are read quite correctly. Data from the database filled in a third-party application, or in Delphi an application using other data access components also displayed fine. The meeting failed to find a solution, and I had to quote a well-known Ukrainian football specialist: “Let's figure it out!”

Unlike the latter, I managed to deal with the described problem. By default when connected to SQLite at FireDAC the ANSI string format is used.

If you force Unicode, then everything will work as it should. But there is also an unpleasant moment. Changing the format of the strings will have to re-create the list of fields in all data sets, as well as re-connect the components responsible for displaying and entering data. Therefore, it is better to take care of the encoding right away.

In the previous parts of this mini-series, we figured out how to create a database, its structure, and connecting to it from Delphi. In this part, I propose to understand the display of data from tables, starting with the simplest case.

A simple table data editor, usually part of a complex application. I usually use a separate form to edit tables. Let's start with a list of products. First of all, we need to create a DataSet to access the table data. In our case, it is quite possible to use the component TADTable... Let's put it in DataModule and specify the property value Connection... In the property editor TableName a list of tables will appear, from which we select a table Products... If you did everything correctly, you can assign to the property Active True. It is better to rename the component immediately (for example, ADTProduct). After that, I usually create a set of fields for the DataSet. Call the field editor (double-click on the component) and select the Add All Fields item in the context menu.

For those who are not in the know, I will explain the essence of this operation. Here we create a predefined set of DataSet fields. If we don't do this manually in design mode, then, in principle, nothing terrible will happen. RunTime will create this set automatically. But I still prefer to create it manually. There are several reasons for this. Firstly, it is more convenient to manage a set of fields, because we can create additional (calculated or lookUp) fields ourselves in design mode. We can also change the properties of the fields themselves. And besides, we get the opportunity to refer to the fields in the code by the name of the TField component, which, in my opinion, greatly simplifies the code writing.

As in the case of the VCL application, connect the component to the dataset TDataSource... This component will provide the link between the dataset and visual controls. The component's DataSet property must reference our dataset (ADTProduct). Below is a fragment of the DFM file

object ADTProduct: TADTable IndexFieldNames \u003d "ID" Connection \u003d ADConnection UpdateOptions. UpdateTableName \u003d "Product" TableName \u003d "Product" Left \u003d 64 Top \u003d 192 object ADTProductID: TADAutoIncField FieldName \u003d "ID" Origin \u003d "ID" ProviderFlags \u003d [pfInWhere, pfInKey] ReadOnly \u003d True end object ADTProductTitle: TStringField FieldName \u003d "Title" Origin \u003d "Title" Size \u003d 50 end object dsProduct: TDataSource DataSet \u003d ADTProduct Left \u003d 120 Top \u003d 192 end

Pay attention to one curious feature, the DataModule form file is saved not in FMX format, like a regular FireMonkey form, but in DFM format, like in VCL.

The next step is to create a procedure for opening the dataset, which we will need to call in RunTime when the program starts. Let's create it in the same DataModul. The procedure code is extremely simple:

procedure TDM. ConnectToDB; begin ADConnection. Open (); ADTProduct. Open (); end;

Place the procedure call in the OnCreate event handler for the DataModule.

Enough time has passed since the term FireMonkey became more or less familiar, if not for all developers, then at least those who use Delphi. During this time, books on FireMonkey, articles on FireMonkey, and entries about FireMonkey in numerous blogs appeared. All this is very interesting to read. But no theory can replace practice. And I, like many before, had an itch to try to write something using FireMonkey.

In doing so, however, a problem arose. For some reason, I decided that I just needed to implement some not very complex working project.

To explain why this turned out to be a problem for me, it will take some (I really want to write, lyrical) digression. An excursion into my past as a developer. Explain some of my views on programming with Delphi.

I must say that I started using Delphi on Windows 3.1, that is, from the first version. And since then I have been learning VCL. Studied in the original, so to speak. I watched, addressed, traced the sources. Again and again.

It is known that at various times the set of components shipped with Delphi included third-party components that were supposed to fill in the gaps in the VCL, and which probably went through some quality control before being included. Some of these components continue to ship today. Take the same Indy. I don't want to offend anyone, this is purely my personal opinion, which also applies to myself as a component developer: no set has been so deeply thought out and so well implemented as a huge and diverse VCL. No, I do not pretend to be the ultimate truth, and, of course, in the VCL itself there are many errors, solutions that cause misunderstanding, cause rejection and with which you want to disagree. But I always got the impression of a certain uniform style. There is, in my opinion, a beautiful and solid core in the VCL that supports the entire Delphi design, and around which the software infrastructure and the developer community itself are built. It is thanks in large part to the VCL, again, in my opinion, rumors about the death of Delphi are still rumors. And when third-party components were included in the VCL delivery, it was immediately noticeable, they were different.

But then a moment comes, and I hear that VCL is a technology that is outdated. Technology to be left in the past. Developers should implement all their new projects on FireMonkey, but about old ones ... it would be nice to transfer them to new rails. FireMonkey is everywhere and always. And I hear it from various sources. And quite persistently. No, no one kills the VCL. he stays with us. But he's not number one now. He must become a stunt double. At least that's how I understand what is being said about the future of the product.

In principle, I understand this alignment. A course for multiplatform, and, more importantly, cross-platform is taken. After all, what is VCL? Visual Component Library. Library of visual components. One can disagree with this. For example, I have always considered a lot of non-visual components, and not components, but just classes, an integral part of the VCL, and a huge number of third-party classes and components - a continuation, extension of the VCL. Well, I can't consider the successors of TDataset as part of the VCL. Although, for example, the term DBExpress Library says that it is, as it were, not a VCL. Apparently, Embarcadero really divides the monolithic, from my point of view, VCL into a number of separate libraries. No, of course, not entirely separate, but nonetheless. And if we accept this point of view, FireMonkey is intended to replace the visual part of the VCL (what should I call the complete library of classes and components, maybe Borland Component Library?).

What are the visual components of the library built around? Around the low-level, basic elements provided by the operating system. Window descriptors, fonts, windows themselves, input elements, messages, device contexts and much more - these are not concepts of a library supplied with Delphi, but concepts of an operating system. Yes, exactly, Windows. And if you want to build a cross-platform library, then it is logical to abandon the infrastructure offered by the operating system that executes a program written using the library.

This is exactly what FireMonkey is trying to do. They are trying to create an infrastructure based on the underlying mechanisms supported in various operating systems, capable of replacing the service offered by the operating systems themselves.

Many people remember trying to makecross-platform not only the library, but also Delphi itself... In parallel with Delphi 6, the Kylix product and the CLX library were released. All this was done in order to be able to develop for Linux. However, Linux lacks many of the basic GUI concepts that Windows does. Windowed interfaces are not native to Linux at all. This application is optional. And I had to write some kind of synthetic library. With its help, it was possible to write a program for both Windows and Linux. However, I still remember that feeling of not disappointment, no, rather, annoying inconvenience that I experienced when I tried to use the analogs of the visual components from CLX. I began to miss a lot. What I used to do without thinking when developing using the VCL turned out to be difficult, completely different, or simply impossible, using the CLX.

I felt about the same when switching from BDE to DBExpress. Old, familiar with the Field Test BDE (Borland already used it in Quattro Pro for Windows and Paradox for Windows, and it was called ODAPI, and then IDAPI, and was a cut above, in my opinion, Microsoft's ODBC) was declared obsolete technology, which should give way to new projects in new library. All the time I was missing something in DBExpress at first, especially knowledge.

At the same time, I in no way want to scold or criticize either the libraries listed above, or the solutions that led to their appearance. It is only about my impressions, sometimes, first impressions.

Now, it probably becomes a little clearer why the decision to write a small working project using FireMonkey brought a number of problems. For many years, in the development of projections, projects and projects, a certain stereotype has been formed, a certain pattern of what and how to do. And in my case, I had to face the fact that the template needed to be changed. Because you cannot transfer everything that you are used to using VCL to a project built on FireMonkey.

At the start of the project, I experienced a certain sense of déjà vu. Namely, a feeling of discomfort. For example, familiar input elements lack many properties. Tricks that have become firmly established in practice, based on tricks associated with knowledge of some features of the operating system, do not pass in the new context. Not to mention, some of the components have changed radically.

Well, another important nuance. What kind of projects do you usually have to do at work, if it (work) is not related to writing compilers, modeling systems, or something else highly scientific? I think that for most of them it is developing something related to using databases. Moreover, something highly scientific can also use the services provided by the DBMS.

Here another ambush awaited me. For some reason, when you come across in practice the fact that FireMonkey does not contain elements oriented to working with data stored in a database, you find yourself not quite ready for this (to put it mildly). Although I have already read about this many times and you know (theoretically) what to use. It's about Live Bindings.

I do not want to get involved in an argument about whether real cool programmers should use db-aware components or not. In practice, starting a new project, I was faced with the fact: I have to get used to both new visual components and a new way of extracting data for display, edit, and ultimately save. Which, again, is neither bad nor good. It just happened that way for me.

This concludes the post about first impressions. Next in line are stories about what and how was overcome while working on the project.

Delphi XE2, released last September, contains a record number of innovations.
Brief reviews of Delphi XE2 capabilities have already been published on Habré. But, obviously, the most striking innovation was the FireMonkey platform, and here I would like to pay a little attention to it.
I have made a small selection of links to materials that, I hope, will help you get a more or less adequate understanding of this platform. But first, for those who are not in the know, I will briefly tell you what FireMonkey is.
Embarcadero Technologies positions FireMonkey as a platform for building full-featured business applications for Windows, Mac and iOS. Moreover, this platform is native to each OS, i.e. no additional add-ons are used when running an application created with FireMonkey.
FireMonkey binds directly to the native (from the OS point of view) graphics library such as OpenGL or DirectX. Thus, it offers the best GPU solution.
The core of the FireMonkey architecture is a powerful class library (including visual components).
The target platform is selected during compilation.
The first version of FireMonkey only supports Win32, Win64, MacOSX and iOS, and Embarcadero plans to port it to several other platforms in the future.

What should be considered?

Despite the fact that the FireMonkey platform provides extensive tools for developing 3D applications, it cannot be considered as a game engine. FireMonkey is positioned precisely as a platform for developing business applications.
The product is now in the early stages of its evolution. And many of FireMonkey's functionality is undergoing changes, both qualitative and quantitative.

I hope that the links below will help you understand the main features of the new platform.
The official product page on the Embarcadero website (Russian)

Among the English-language material, I would like to highlight the series (eng.)

What to see?

As for the latest version of Delphi, there is more video on the product's features and how to work with it than ever before. Both official, from Embarcadero, and from independent developers. There are a lot of videos on YouTube about FireMonkey, you can just use the search. Among this abundance of material, I will single out a series of three videos from Marco Cantu - RAD in Action landing page., Thus giving my research a useful vector.

FireMonkey is the core technology of the "new Delphi". Please tell us about the goals, capabilities and technical aspects of the device of this fundamentally new library. With the passage of time, in hindsight, how difficult and justified was your refusal to further develop the hugely popular VCL?

It was chosen as the main direction for the development of Delphi technology to achieve a specific goal - multi-platform development from one environment, based on a single source code base, and without the need for cardinal retraining of developers. Within the framework of the now classic and super popular VCL, this was impossible, its connection with WinAPI was too close, one might say, “at the genetic level”.

VCL components did not have an "abstract" layer between the functional layer in terms of the interface and the mechanisms for displaying them. Functional level - how it behaves as a control, what events it reacts to, what kind of user interaction it provides. Display - Calling platform-oriented visualization methods as a kind of image formed by raster objects and vector primitives. FireMonkey initially implemented the principle of strict separation of the control into two components: "behavioral" and "visual".

Vsevolod Leonov, Embarcadero Technologies

The first will generally repeat not even the basics of VCL, but the essence of object-oriented programming. A component is a class, component classes form a hierarchy where families and modules can be distinguished. A component's class has little to do with how it is rendered.

The visual "picture" is generated dynamically, it is not hardcoded in the component class. The image or "style" in FireMonkey is loaded into the component when the application starts. We have a functional skeleton for a component, and the "skin" or "cladding" can be changed, but why? Precisely so that FireMonkey applications look authentic on any platform - Windows 7, Windows 8, Mac OS, iOS and, in the near future, Android. The traditional monolithic class structure of the VCL could not provide this.

The technological effectiveness of the approach plays a special role here. Basically, you can take the VCL library and "stuff" WinAPI and all other possible platform calls. This can still be done on a very limited subset of components, but the VCL contains several hundred components, so this approach could just kill the VCL. It was decided not to touch VCL, but to develop new opportunities on a new platform - FireMonkey. This technology even has a certain technical sophistication - at the time of building a project for a specific platform, the Delphi IDE connects the required compiler, and the interface components get the platform style.

For the user, this is one click and the same source code, for Delphi, it is a long-term hard work of developers to create such a multi-platform library.

When it became clear that FireMonkey would be introduced as a separate new platform, it was necessary to choose the right coexistence strategy: Embarcadero did not want to negatively impact VCL users in any way. Therefore, we chose the following plan: VCL remains ideologically and architecturally stable to ensure the highest possible compatibility, facilitating the migration of projects to modern versions. The development of FireMonkey will follow a natural and parallel path, without looking back at the VCL.

The weak point of this solution is the rather problematic migration from VCL to FireMonkey within one project. But for a new project, a developer can choose FireMonkey to ensure the multi-platform functionality of their resulting application. After the release of XE4 with iOS support, we can already talk about the bright competitive advantages of Delphi for starting mobile development in an enterprise environment, which will be increased after the implementation of the planned Android support.

Therefore, as such, there is no explicit "rejection" of the VCL development. The VCL part of Delphi also evolves in newer versions. This is 64-bit support, and the introduction of styling for visual components, and the implementation of the mechanism of flexible dynamic links or "binding", and the inclusion of the FireDAC library for working with databases in VCL projects. Just against the background of a giant qualitative leap due to FireMonkey, progress in the VCL looks somewhat undeveloped. Be that as it may, the VCL is an integral part of Delphi and will remain so for many years to come. While platform evolution and the current state of the art in desktop and mobile OS are such that the future is clearly with FireMonkey.

In the interview, we have already discussed iOS support, let's tell our readers about the support for other latest technologies from the latest RAD Studio XE4, such as Windows 8 and WinRT, 64-bit systems, macOS and so on. Can I list what else you can offer a modern programmer spoiled by innovations?

Most likely, a modern programmer is not "spoiled" by innovations. For large projects, any "innovation" often turns into a gigantic amount of work.

For example, everyone waited a long time, many immediately rushed to transfer their codes to the new platform. But it turns out that even very professional teams are not ready for this. Compiled 64-bit code does not mean workable. The "sins of youth" began to emerge, for example, the use of instructions on the assumption of a 4-byte address size. Lack of culture of conducting tests, coupled with technological unavailability to implement this process in a short time.

And here - the larger the project, measured, say, by the number of lines of source code, the more carefully and weighed programmers treat various kinds of innovations ranging from the appearance of the "button" in the interface to "syntactic sugar" in the compiler.

One of these “problematic” achievements was the release of Windows 8. Personally, as a PC user and just a modern IT specialist, Windows 8 is a delight. But for developers who were sent a batch of computers running Windows 8 with a technical specification for development for a new OS in the load, this means certain difficulties.

We have tried to provide the development support for the new interface of this OS as comfortably and painlessly as possible. Therefore, special styles have been introduced for both VCL and FireMonkey, and the programmer can either rebuild the application interface or re-create the application, which will be indistinguishable from the "native" Windows 8 in appearance. Of course, there is a need for “native” support for Windows 8 through WinRT. But here the prioritization of goals in modern conditions affects. Mac OS, iOS, Android in the near future do not yet give an opportunity to talk about full support for WinRT in the near future.

Embarcadero's strategic goal is, of course, multi-platform. The RAD Studio XE4 release was a key one, primarily due to iOS support. An active programmer using the VCL can start developing for iOS in a matter of hours. Even a simple mobile application can be instantly transformed into a powerful project that works within the existing infrastructure. Don't think that this is just a new compiler for FireMonkey and a new style to match the iOS interface.

This includes a new visual designer, built-in support for various form factors, and data access libraries, including the new FireDAC, and LiveBindings technology for flexible and dynamic binding to corporate data. All these innovations come in sync - for Windows, and for Mac OS, and for iOS. The Mac OS operating system is not developing so rapidly, so there are no such problems as the transition from Windows 7 to Windows 8. But Retina displays appeared, and this required special attention. Now any MacOS application created in Delphi XE4 automatically includes two styles - "normal" and "high definition".

So the same application can have the same high-quality “native” interface on any Apple desktop computer.

Embarcadero does not want to “surprise”, “amaze” or even “entertain” developers with its new innovative releases. Rather, on the contrary, the IT sphere is already full of various surprises: new devices, new platforms, new users, their new needs, new interaction scenarios. Add new software development technologies to this, and programmers simply will not have time to create new systems on existing ones - they will only do what to migrate from one environment to another, from an old library to a new one, from one language to another.

But we do not profess to reject everything new. We just want to ensure the continuity of everything - code, interface, project, even professional skills when new platforms and devices appear. We can say that we are fighting an unhealthy conservatism about new platforms at the expense of healthy conservatism in development tools. Don't expect exotic products, non-standard programming languages, and outlandish development tools from Embarcadero.

With us you will always find - visual development, classic languages, "native" code, and let the new target platforms be for your applications, created in the same proven classic way.

TRippleEffect a class for creating an effect that applies ripple waves to the texture of visual objects.

The ripple center is specified in the property Center... Other aspects of the ripple can be adjusted using properties Amplitude (Amplitude), AspectRatioand Phase (Phase). The number of ripple waves is determined by the property Frequency (Frequency).

The following table shows the impact results TRippleEffect a PNG photo placed on the form (using an object). The ripple center is in the middle of the image. Other properties TRippleEffect are used with their default values \u200b\u200b( Amplitude = 0,1, AspectRatio = 1,5, Frequancy = 70, Phase = 0).

In this tutorial, you will be using a few basic image effects in the FireMonkey app.

Step 1: Apply the effect to the image.

In FireMonkey, applying an image effect to an image is a simple process. Just create a component that can contain an image and then apply one of the image effects.

Create a new FireMonkey app ( File\u003e New\u003e FireMonkey Desktop Application\u003e HD FireMonkey Application).

Place the component on the form.

Select the component in the toolbar.

Position the TImage on the form in the constructor.

You can see that the component doesn't fit in the center of the form designer. As shown in the figure, it is necessary to make the image area as large as possible. To do this, select the component on the designer form and then change the properties Align at alClient in the Object Inspector to make the component the same size as the client size of the form region.

Select the image you want to apply the effect to. The component stores the picture in the property Bitmap... Select property Bitmap in the object inspector, and using Edit ... to select an image.

Now you can choose an effect for the image. On the tool palette, select TRippleEffect.

Now RippleEffect displayed in the window Structure.

To apply an effect, it must be defined as a child of another component. In this case, RippleEffect1 must be defined as a child Image1... To do this, drag RippleEffect1 and place it on Image1 on the structure pane.