Delphi, FireMonkey, All-Access and other pleasant surprises. firemonkey

TRippleEffect class for creating an effect that superimposes ripples of waves on the texture of visual objects.

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

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

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

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 application ( File > New > FireMonkey Desktop Application > HD FireMonkey Application).

Place the component on the form.

Select the component on the toolbar.

Position the TImage on the form in the constructor.

You can see that the component is not placed in the center of the form designer. As shown in the figure, it is necessary that the size of the image area be as large as possible. To do this, select the component on the designer form and then change the properties Align V alClient in the Object Inspector so that the size of the component becomes the same as the client size of the form region.

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

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

Now Ripple Effect 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 panel.

1. Now you can see that Ripple Effect already working on Form Designer.

1. Change the property Frequency on 20 .

Step 2: Apply an animation effect to the RippleEffect.

Highlight Ripple Effect on the panel structure.

Highlight a property Phase in the Object Inspector and run the command Create New TFloatAnimation from the dropdown menu.

Make sure that FloatAnimation1 defined as a child element RippleEffect1.

Change properties FloatAnimation1 as below:

And finally, let's add an event procedure OnMouseMove To .

FireMonkey is the core technology of the "new Delphi". Please tell us about the goals, capabilities and technical aspects of this fundamentally new library. After a while, looking back, how hard and justified was your refusal to further develop the super 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 radical retraining of developers. Within the framework of the now classic and extremely 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 level in terms of interface and their mapping mechanisms. Functional level- how it behaves as a control, what events it reacts to, what kind of user interaction it provides. Display- calling platform-oriented rendering methods as a kind of image formed by raster objects and vector primitives. FireMonkey initially implemented the principle of strictly dividing the control into two components: "behavioral" and "visual".

Vsevolod Leonov, Embarcadero Technologies

The first one as a whole will 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. The class of a component has little to do with how it is rendered.

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

Here special role plays the manufacturability of the approach. In principle, you can take the VCL library and “stuff” WinAPI with all other possible platform calls. On a very limited subset of components, this can still be done, but the VCL contains several hundred components, so this approach could simply "kill" the VCL. It was decided not to touch the VCL, and to develop new features on the new platform - FireMonkey. This technology even has a certain technical elegance - at the time of assembling the project for a specific platform Delphi environment The IDE connects the required compiler, and the interface components get the platform style.

For the user, this is one click of the mouse and the same source code, for Delphi, it is many years of 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, the right coexistence strategy had to be chosen: Embarcadero didn't want to negatively impact VCL users in any way. Therefore, we have chosen the following plan: VCL remains ideologically and architecturally stable to ensure the greatest possible compatibility, while 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 on the other hand, for a new project, a developer can choose FireMonkey to ensure the multi-platform nature of his resulting application. With the release of XE4 with iOS support, we can already talk about Delphi's strong competitive advantage for mobile development in the corporate environment, which will be increased after the implementation of the planned support for Android.

Therefore, as such, there is no explicit "refusal" from the development of VCL. In new versions, the VCL part of Delphi is also being developed. This includes support for 64-bit, and the introduction of styling for visual components, and the implementation of a mechanism for flexible dynamic links or "binding", and the inclusion of the FireDAC library for working with databases in VCL projects. It's just that against the backdrop of a giant qualitative leap due to FireMonkey, progress in the VCL looks somewhat unmanifested. But be that as it may, VCL is an integral part of Delphi and will remain so for many years to come. Although the evolution of platforms and the current state of affairs in the field of OS for desktop systems and mobile devices 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 of others the latest technologies from the latest RAD Studio XE4, such as Windows 8 and WinRT, 64-bit systems, MacOS and so on. Can you list what else you can offer to a modern programmer spoiled by innovations?

Most likely, the modern programmer is not "spoiled" by innovations. For major 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 a new platform. But it turns out that even very professional teams are not ready for this. Compilable 64-bit code does not mean workable. "Sins of youth" began to emerge, such as using instructions assuming a 4-byte address size. The lack of a culture of conducting tests, coupled with the technological unwillingness to implement this process in a short time.

And here - the larger the project, measured, say, by the number of lines source code, the more carefully and balanced programmers treat various kinds of innovations in the range from appearance"buttons" 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, I am delighted with Windows 8. But for developers who were sent a batch of Windows 8 computers with technical specifications for development under the new OS as a load, this means certain difficulties.

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

The strategic goal of Embarcadero is, of course, multi-platform. The release of RAD Studio XE4 was a key one, primarily because of 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 it's 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, data access libraries, including the new FireDAC, and LiveBindings technology for flexible and dynamic binding to corporate data. All these innovations are coming simultaneously - for Windows, and for Mac OS, and for iOS. operating room Mac system The OS 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".

That. the same application can have the same quality "native" interface on any desktop computer from Apple.

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 will simply not have time to create new systems and 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 confess the rejection of everything new. We just want to ensure the continuity of everything - the code, the interface, the project, even professional skills as new platforms and devices appear. We can say that we are fighting an unhealthy conservatism in relation to new platforms at the expense of a 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, classical languages, "native" code, and let the target platforms for your applications created in the same proven classical way be new.

03/06/2013 12:46 pm

I suffered a lot due to the lack of a browser component in FireMonkey. The famous Delphi Chromium Embedded project did include FMX support in the latest build. But despite the fact that quite a lot of time has passed, the author is in no hurry to add FMX2 support. In the end, I had to take matters into my own hands.

The TChromiumFMX component from the official assembly works quite well in FireMonkey (in XE2), but it doesn't even compile in FMX2. I had to figure out a little how it works and fix it. Fortunately, no major changes were required.

In FMX2, two things that the component needs have changed.

First, TBitmap no longer has ScanLine and StartLine properties. Direct access to TBitmap content has been redesigned (I wonder why?) and is now available through the TBitmapData class, which returns the TBitmap.Map method.

Well, the second, more well-known - Platform .* is no more, now you need to get the desired interface through TPlatformServices.GetPlatformService . Everything is pretty straightforward here and there are no problems.

I didn’t test it with particular ingenuity, but the component is quite suitable for my purposes - you can view sites through it. Download it. Still, perhaps, I will send my edits to the author, maybe he will consider it necessary to add them to the official version.

07/30/2012 2:43 am

Jason Southwell proposes to develop a set of FireMonkey wrappers for native Windows/OSX controls and raises money for this. He plans to raise $20,000 to begin with.

The idea is clear. Existing FireMonkey components are drawn using Delphi tools almost from scratch, which, on the one hand, largely ensures their cross-platform, but on the other hand, as a result, we get components that do not look quite natural in both currently supported operating systems. And this is not so bad - in addition to the appearance, you have to independently develop the logic of these components. For example, RichEdit is quite complicated, and repeating its logic within FireMonkey is not a trivial task. Both VCL and CLX did not invent bicycles, but used ready-made ones.

And now the bad news. Everything works at runtime, but I didn't find any way to add my new tab type to the Items Designer. And it seems that all list controls have the same problem: TListBox, TGrid, etc. At first, I really liked the approach to their implementation, but now I even somehow doubt it. An internet search revealed that I am not alone with this problem.

Help is silent, I also did not find anything in the code. Really no way? This would be extremely annoying.

What is Fire Monkey?

FireMonkey (FMX) is a framework for cross-platform development for both desktop systems (Windows, Mac OS + support for the server side on Linux in the near future) and mobile (iOS and Android) using the Delphi/C++ language.

Peculiarities:

• single code base for all platforms;

• any control (visual component) can be a container (parent) for other components;

• the presence of a very advanced relative arrangement (20 types) of components on the form;

• LiveBinding allows you to connect any type of data or information to any user interface or graphical objects;

• presence of form/component styles;

• Multi-Device Preview allows you to customize the visual presentation for each of the platforms;

• FireUI Live Preview - Displays the app view on real devices in real time.

Possibilities:

• use of the native API of each of the platforms, as well as the ability to call third-party native libraries;

• interaction with all sensors (GPS, Accelerometer, Compass, Bluetooth (including LE) and others);

• support for push notifications, IoT;

• support for asynchronous HTTP requests;

• support for most databases (MsSQL, MySql, Oracle, PostgreSQL, MongoDB, etc.);

• work with Cloud Service (Amazon, Azure);

• android service support.

Cons (currently):

• lack of support for customization of native classes;

• the implementation of specific things is either impossible (widgets, extensions (iOS), etc.) or a dance with a tambourine is necessary (background service, broadcast message, etc.);

• customization Splash screen (initial screen) to put it mildly, no;

• FMX controls use their own rendering (visualization, drawing), which is purely visually similar to native;

• the use of native controls is associated with large body movements;

• with a large nesting of components, incredible things happen: the application crashes in various places, focus is lost, freezes, etc.;

• the information content of debugging an application on mobile platforms is zero;

• descriptions of errors on mobile platforms are reduced to useless “Error 0x00000X”;

• compilation time wishes to be the best for medium and large projects;

• the need to use a file to refine mobile applications for each platform;

• no support for Intel Atom architecture;

• inadequate price compared to competitors.

Pros:

• very active recent development of both the product and the community, support for more and more new technologies;

• the presence of a huge number of free and commercial components;

• the speed of the application is very close to native;

• a very advanced visual editor and environment in general, the presence of styles;

• the ability to test the application on Win, and only then deploy it to devices, which greatly speeds up development;

• change mode/platform with a flick of the wrist;

• PAServer provides easy interaction with MacOs when developing for Apple OS;

• support for 3D graphics out of the box.

In conclusion, I want to say that over the past couple of years, FireMonkey has grown into a professional tool for cross-platform development of business applications and not only. Many shortcomings are gradually being solved and with each release the product becomes more modern and self-sufficient, the existing skepticism towards the Delphi language itself, associated with many years of stagnation, also disappears. Writing new projects on FireMonkey is "safe" and promising.

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

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

To explain why this turned out to be a problem for me, it will take some (one wants to write, lyrical) digression. An excursion into my past as a developer. Explain some of my views on programming using 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 studying VCL. Studied in the original, so to speak. Watched, addressed, traced source codes. 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 kind of quality control before being included. Some of these components continue to be supplied to this day. 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: not a single set has been so deeply thought out and implemented as well as a huge and diverse VCL. No, I do not pretend to be the ultimate truth, and, of course, there are many errors in the VCL itself, decisions that cause misunderstanding, cause rejection and with which you want to disagree. But I always got the impression of a certain single style. There is in VCL, in my opinion, a beautiful and strong core that supports the entire Delphi design, and around which both the software infrastructure and the developer community itself are built. Thanks in large part to the VCL, again, in my opinion, the rumors about the death of Delphi are still rumors. And when third-party components were included in the delivery of the VCL, it was immediately noticeable, they were different.

But then the moment comes and I hear that VCL is a technology that is outdated. A technology that should 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 different sources. And quite persistently. No, nobody kills VCL. he stays with us. But he is no longer number one. He should be a stand-in. 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 has been taken for multi-platform, and, more importantly, for cross-platform. After all, what is VCL? Visual Component Library. Library of visual components. You may not agree 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, an extension of the VCL. Well, I can't consider the TDataset's heirs as not 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 you take this point of view, FireMonkey is intended to replace the visual part of the VCL (how should I still call the complete class and component library, 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 handles, fonts, windows themselves, input elements, messages, device contexts and much more - these are not the concepts of the library that comes with Delphi, but the concepts operating system. Yes, that's right, Windows. And if you want to build a cross-platform library, then it is logical to refuse the infrastructure offered by the operating system that executes the 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 by various operating systems that can replace the service that the operating systems themselves offer.

Many remember trying to makecross-platform not only the library, but Delphi itself. Parallel to 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 does not have many of the basic GUI windowing concepts that Windows does. The window interface for Linux is generally not a native phenomenon. This is an optional application. 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, not of disappointment, rather of annoying inconvenience, that I experienced when I tried to use the analogues of visual components from CLX. I started missing a lot. What I used to do without thinking when developing with the VCL turned out to be difficult, very different, or simply impossible to do using the CLX.

I felt about the same when switching from BDE to DBExpress. Old, familiar from Field Test-a BDE (Borland then already used it in Quattro Pro for Windows and in 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 in new projects to a new library. I was always 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 decisions that led to their appearance. It's about only about my impressions, sometimes first impressions.

Now, perhaps, it 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 projects, projects and projects, a certain stereotype has been formed, a certain template of what and how to do. And in my case, I had to face the fact that the template needs to be changed. Because you can't transfer everything you're used to using VCL to a project built on FireMonkey.

At the start of the project, I experienced a certain sense of deja vu. Namely, a feeling of discomfort. For example, the usual input elements do not have many properties. Tricks that have become firmly established in practice, based on tricks related to the knowledge of some features of the operating system, do not work in a new context. Not to mention that some components have changed radically.

Well, another important nuance. What kind of projects usually have to be done at work, if it (work) is not related to writing compilers, modeling systems, or anything else highly scientific? I think for most it's about developing something that involves 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 that FireMonkey does not contain elements focused on working with data stored in the database, you are not quite ready for this (to put it mildly). Although I have already read about this many times and you know (theoretically) what you should use. It's about Live Bindings.

I don't want to get into an argument about whether real cool programmers should use db-aware components or shouldn't. display, edit and ultimately save. Which, again, is neither bad nor good. It just happened that way for me.

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