What are delphi interfaces for? The best IT solutions for business. Hints everywhere, hints always

just for results

strict adherence to deadlines

Transparency

project implementation

technical support as a gift

Programming, improvements, consultations on 1C

How we are working

1. We discuss the problem by phone. If you have remote access - show on your computer screen.

2. We evaluate the work in rubles if the project is large, if not - the approximate number of hours.

3. We get the job done.

4. You accept work in your program, if there are shortcomings, we correct them.

5. We issue an invoice, you pay.

Cost of work

1. All works are divided into 3 categories: consultation, updating a typical configuration, developing or programming a new report, processing, buttons, etc.

3. For work over 10 hours, a technical task is prepared in advance with a description and cost of the work. Work begins after the approval of the TOR with you.

Technical support

1. If you find any errors in previously accepted works, within 3 months, we correct them for free.

2. For regular customers, we fix any shortcomings in our work free of charge within a year.

Programs for managing your business.

Buy 1C:Enterprise

We are the official dealer of 1C, you can purchase from us various software products and licenses. In addition to buying a "box", we will help you set up the program, consult and make basic settings.

• Accounting
• Store automation
• Wholesale
• Help with installation and initial setup is included in the package!
• Fine-tuning configurations to the needs of the customer, development of new modules in the absence of the necessary functions in the standard configuration.

1c accounting	1C: Trade management	1C: Retail	1C: Payroll and Human Resources Management
From 3300 rub.	From 6700 rub.	From 3300 rub.	From 7400 rub.

Providing a server.

Instant setup server + 1C.

No server? It doesn't matter, we will select and quickly set up a server in the "cloud". For a small fee, you get a very reliable solution.

• Availability 24/7
• No need to keep your own system administrator (the savings will cover the cost of your server).
• Quick setup and installation of 1C on the server, in 3 days you will already have a fully working system.
• At any time you can move to local server if the solution is not satisfactory.

SMS from your 1C

Do you want customers to learn about promotions and discounts in time? Clients not returning? Set up SMS sending directly from 1C!

Our company will be able to quickly set up sending SMS to your customers directly from 1C. Examples of events that can be automated:

• Gratitude for the purchase and accrual of bonuses immediately after the next purchase.
• Accrual of bonuses to the card as a gift for a birthday/another important or holiday day.
• Warehouse notification.
• Gift voucher expiration.
• Notification of receipt of prepayment and reservation of goods.
• Address with directions to the store/office, phone numbers.
• Etc.

Setting in 1C can be done by our specialists or our employees. You can get acquainted with the tariffs on the SMS-tariffs page.

• SMS delivery guarantee, money is withdrawn only for delivered SMS.
• Separate billing for each SMS.
• Replenishment of the balance in various ways.
• View the history of all sent SMS at any time.
• The sender's name instead of the numeric number on the recipient's phone.

Object-oriented programming (OOP), in addition to the concept of a class, also provides for the fundamental concept of an interface.

What is an interface and what are the features of working with it in the Delphi programming language?

An interface is a semantic and syntactic construct in program code used to specify the services provided by a class or component (Wikipedia).

In fact, an interface defines a list of properties and methods that should be used when working with a class that implements this interface, as well as their signature (name, data type, accepted parameters (for procedures and functions), etc.). Thus, a class that implements an interface must necessarily implement all of its components. Moreover, in strict accordance with the way they are described in it.

Very often, interfaces are compared with abstract classes, but for all the similarities, this comparison is not entirely correct. In abstract classes, at a minimum, control over the visibility of members is available. At the same time, scopes are not defined for interfaces.

Interfaces allow you to make the architecture more flexible, as they unify access to a particular functionality, and also allow you to avoid a number of problems associated with class inheritance (interfaces can also be inherited from one another).

Delphi uses the interface keyword to declare an interface. This is the same keyword that defines the section of the module that can be accessed from outside (between the interface and implementation keywords). However, when declaring an interface, a different syntax is used, similar to declaring classes.

Delphi/Pascal

IMyNewInterface = interface procedure InterfaceProc; end;

IMyNewInterface =interface procedure InterfaceProc ; end ;

Thus, the interface declaration syntax itself has no fundamental differences from other programming languages ​​(the syntax features based on Pascal do not count). At the same time, the implementation of interfaces has a number of characteristic features.

The fact is that Delphi interfaces were originally introduced to support COM technology. Therefore, the IInterface interface, which in Delphi is the ancestor of all other interfaces (a kind of analogue of TObject), already contains three basic methods for working with this technology: QueryInterface, _AddRef, _Release. As a result, if a class implements any interface, then it must implement those methods as well. Even if this class is not designed to work with COM.

Due to this feature of the IInterface interface, in Delphi the use of interfaces, in most cases, leads to the addition of obviously unused features to the class.

There is a library class TInterfaceObject, which already contains the implementation of these methods and, when inheriting from it, there is no need to implement them yourself. But since Delphi does not support multiple class inheritance, its use often only causes additional complexity in the design and implementation of already required functionality.

All this led to the fact that, despite all the possibilities provided by interfaces, their practical use in Delphi almost did not go beyond working with COM.

Being optimized to work mainly with this technology, the interfaces, or rather the functionality and architectural restrictions that they add without fail, do not justify themselves when solving other problems.

Therefore, many Delphi programmers are still, in fact, deprived of a powerful and flexible tool for developing application architecture.

Creation interface the user is reduced to choosing from the palette of components the Delphi components necessary for the program to work, serving interface management, as well as interface displaying information, and transferring them to the Form with subsequent layout.

The user interface you create should use standard, user-familiar elements and provide maximum convenience. All this is ultimately determined by such a criterion as the effectiveness of the interface - the maximum result with minimal effort.
The principles of creating a user-friendly interface are known. As the most general principles for creating user interfaces three main points can be considered:

1. The program should help accomplish the task, not become the task.
2. When working with the program, the user should not feel like a fool.
3. The program should work in such a way that the user does not consider the computer a fool.

First principle- this is the so-called "transparency" of the interface. The user interface should be intuitive, easy to learn, and not create problems for the user that he will have to overcome in the process. Use standard, unadorned components, use the usual controls used by similar programs, and you will achieve the performance criteria first principle.

Second principle lies in the neglect of the intellectual abilities of users. From my own experience, I know that often users not only do not know how to work at a computer, but are simply afraid to do anything on their own. Therefore, the user interface should be as friendly as possible.
Moreover, the fears of users are often justified, because the cost of the program, and the computer itself, cannot be compared with the cost, for example, of a database created by many years of effort. That is why the programmer, when creating a user interface, must always build in the program "fool protection" - from wrong actions and user input of incorrect data. But some programmers get too carried away with such protection, make it too intrusive, and as a result, the program's operation resembles the famous "step left, step right is considered an escape"! And what a programmer creates as a solution to a problem, itself begins to create problems.
To comply second principle there is no need to allow the program to "correct" the user's actions and indicate what exactly to act for him, driving him into a narrow framework. Also, one should not get too carried away with the display of informational hint messages, especially dialog ones, as this distracts the user from work. And it is better to provide for the possibility of disabling prompts altogether.

Third principle is to create a program with the greatest possible "mental" abilities. Despite the rapid development computer technology, even widespread programs can only very conditionally be called having artificial intelligence. They interfere with the user experience by displaying dialog boxes with stupid questions that cause bewilderment even in the simplest situations. As a result, users in their hearts exclaim: "Well, this car is stupid!"
Personally, I am annoyed by the constant questions of almost everyone. text editors about whether to save the changed text, although the original and current text do not differ by a single character. Yes, I typed something, but then I returned everything back, is it really impossible to figure it out! I have to check to see if I messed something up.

Try to adhere to the following rules:

Standard interface elements

Use standard components for this interface element. Having met your program, the user will not waste time getting to know each other, but will immediately start working - this is one of the signs of a professionally made program.

Small palette of tools

Try not to use too many different components. And of course, using one standard component somewhere in one place, in a similar case also use it.

Equal spacing between controls

Arrange interface elements at the same distance from each other. The randomly scattered components create the feeling of an unprofessional product. And vice versa, carefully calibrated placement on the Form of buttons, switches, checkboxes and other components that make up the interface is a sign of quality work.

tab order. "correct" order

TabOrder is the order in which the screen cursor moves over the controls when a key is pressed Tab. In a correctly written program, the cursor moves, following the logic of the user's work with the program. When creating a program, the programmer often changes components, removes some, and adds others as needed. As a result, in the finished program, the cursor randomly jumps over the Form. After completing the program, do not forget to set TabOrder.

Font selection

Just leave fonts alone. Delphi's own default fonts will work for any system your program might run on. Use bold font only to highlight important elements. Application cursive and especially underlining, which the user may mistake for a hyperlink - bad form.

Choice of colors

As for the colors of the interface elements, just as in the case of fonts, it is better to leave them standard, by default. Delphi uses the Windows system palette, and by changing it, the user can easily customize the colors for themselves.

Alternative management

A professionally made program should be able to be controlled not only with the mouse, but also with the keyboard. There should be no functions available for execution only with the mouse (drawing in graphic editors doesn't count!). For the most used functions, "hot keys" should be provided for their quick access.

Interface building blocks

With regard to specific elements of the user interface, the quality of user interaction with the program depends on:

• compliance of the control element with its task;
• the rules by which the control operates.
  This page discusses the rules for creating some interface elements.

And now I want to show what tools Delphi offers for managing components on the Form, their relative position and cursor behavior when a key is pressed. Tab.

In order to arrange the components relative to each other in the correct order, first need to highlight them. You can simply drag the mouse over the area on the Form that contains the selected components. Or by holding Shift", specify with the same mouse each component to be selected. Repeated mouse click on the selected component (while pressing " Shift") deselects it.

Selected components can be controlled as a whole - moved around the Form, assigned values ​​to the same properties, copied (for installation, for example, on another Form), even deleted.

Now right-click on one of the components, and from the "pop-up" menu select Position -> Align... A dialog box will appear allowing you to adjust the position of the components in the group horizontally and vertically. For example, we need to align our four buttons to the left and make sure that they have the same vertical distance between them. To do this, select the radio buttons Horizontal: left sides And Vertical: Space equally.

Selecting an item Center, we will arrange the components so that their centers will be located on the same line horizontally or vertically, and the point Center in window moves components to the center of the window, either horizontally or vertically.

In the same menu, the line Tab O order... causes the appearance of a dialog box that controls the movement of the cursor through the interface elements when a key is pressed Tab. When the Form appears on the screen, the cursor will naturally be on the component located on the first line of the dialog box. And then it will move down the list. On the dialog box, two blue arrows "up" and "down" control the position of the selected component. Select the desired component, use the arrows to move to the desired line in the list, and so on.

When selecting a menu item Control -> A submenu appears with two items:

• Bring to Front
• send to back

These are component methods that are also available programmatically. Button1.SendToBack moves the button to the "background", and Button1.BringToFront- bring to Front". That is, if one component is placed above another, these methods swap them. The cases in which this can apply are fairly obvious.

I have a problem using Delphi class from C++ code. delphi dll demo which exports a function that returns an object.
my Delphi Dll code looks like this:

Library DelphiTest; // uses part.... type IMyObject = interface procedure DoThis(n: Integer); function DoThat: PWideChar; end; TMyObject = class(TInterfacedObject,IMyObject) procedure DoThis(n: Integer); function DoThat: PChar; end; // TMyObject implementation go here ... procedure TMyObject.DoThis(n: Integer); begin showmessage("you are calling the DoThis methode with "+intToStr(n) +"parameter"); end; function TMyObject.DoThat: PChar; begin showmessage("you are calling the DoThat function"); Result:= Pchar("Hello im Dothat"); end;

// export DLL function:

Function CreateMyObject: IMyObject; stdcall;export; var txt: TextFile; begin AssignFile(txt,"C:\log.log"); reset(txt); Writeln(txt,"hello"); Result:= TMyObject.Create; end; exports CreateMyObject;

in my C++ project I have declared the interface IMyObject like this:

Class IMyObject ( public: IMyObject(); virtual ~IMyObject(); virtual void DoThis(int n) = 0; virtual char* DoThat() = 0; );

and my main function is as follows:

Typedef IMyObject* (__stdcall *CreateFn)(); int main() ( HMODULE hLib; hLib = LoadLibrary(L"DelphiTest.dll"); assert(hLib != NULL); // pass !! CreateFn pfnCreate; pfnCreate = (CreateFn)GetProcAddress((HINSTANCE)hLib, "CreateMyObject "); if (pfnCreate == NULL) ( DWORD errc = GetLastError(); printf("%u\n", errc); // it gets error 127 ) else( printf("success load\n"); ) IMyObject* objptr = pfnCreate(); objptr->DoThis(5); FreeLibrary(hLib); int in; scanf_s("%i", &in); return 0; )

in this example i got a runtime error when i try to access the exported function. line errors:
IMyObject* objptr = pfnCreate();

Can you tell me what is wrong with my example.
and if possible any working example for accessing a Delphi class (in a DLL) from C++ code.

Solution

The first problem is calling the method convention. Delphi Interface uses register which is a Delphi specific calling convention. using stdcall For example, for interface methods.

The next problem is in C++. Your C++ interface must derive from IUnknown . Also, it must not declare a constructor or destructor.

Other than that, your Delphi code exports PWideChar which doesn't map to char* . It maps to wchar_t* .

Looking further, returning a PChar works great here because your implementation returns a literal. But more serious code will probably want to use a dynamically allocated string, at which point your design is flawed.

Note that you must be an elevated administrator to create a file in the root of the system drive. So this is another potential point of failure.

I expect there are other bugs, but that's all I've found so far.

The article was written based on the results of analyzes of programs written by young developers of our group.

Correctly arrange the switching sequence of components

Many users, especially those who have previously worked in DOS, have a habit of switching between input fields not with the mouse, but using the keyboard with the Tab key. In addition, it is much faster than selecting each field with the mouse. Therefore, the switching order of the components must be set correctly. This applies both to components inside all container components (panels, GroupBoxes, and the like), and to the container components themselves, if there are several of them on the form.

The switching order of components inside the container is set by the TabOrder property. The first component to become active is the one with TabOrder equal to 0, the second one with 1, and so on, until all components have been iterated over. In addition, the component has a TabStop property, which indicates whether the component will receive focus when switching with the Tab key. If you need to disable switching to any component, set TabStop = false for it. In this case, it will be possible to switch to this component only with the help of the mouse.

There are times when users who are used to switching a certain key in one program, out of habit, continue to use it in others. This often happens with 1C users, where the Enter key can be used to navigate through the input fields. Well, let's give them that opportunity in our programs if they ask for it. Set the form's KeyPreview property to true and write the OnKeyPress event handler:

Procedure TForm1.FormKeyPress(Sender: TObject; var Key: Char);
begin
if ord(key)=vk_Return then
Form1.SelectNext(PriemForm.ActiveControl, true, true);
end;

Such a handler provides a transition through the form elements when the Enter key is pressed. It should be noted that this method will not work with buttons, because pressing Enter on a button causes it to be pressed, while pressing Tab transfers input focus to the next component in the switching sequence.

Default buttons

All the same users quickly get used to the fact that in application dialog boxes, as a rule, you can confirm your choice with the Enter key, and cancel with the Esc key. Let's not disappoint them in our programs, especially since it's very easy to do. For the Enter button, set the Default property to true. For a button that responds to Esc, set the Cancel property to true. And that's it.

Yes or no

All dialog boxes requesting user actions must have at least two buttons: confirmation of an action and refusal of an action (Yes/No, Save/Cancel, etc.). The action can be canceled by closing the window with the [X] button in the window title. It is invalid if there is only one button for confirming the action, and for refusal it is supposed to close the window with the button [X] in the title, or there is no possibility of refusal at all. This confuses the user, causing a logical question: how to refuse?

Also, do not forget about what was said above in the paragraph "Default buttons".

All dialog boxes should open in the center of the screen

Centered instead of where they were created in design mode. Firstly, it is more visual, and secondly, it automatically eliminates the problem of different screen resolutions for different users.

An exception is made if the dialog box is not modal, and as a result of the user's work in this window, changes immediately occur in the main window (for example, filtering a data set, redrawing graphs, etc.).

Window sizes should not exceed screen sizes.

In no case. It's a disgrace when part of the window crawls out of the screen. This requirement does not depend on the user's screen resolution, i.e. excuses like "Let them put a higher resolution" do not work.

Correct resizing of window elements

Window elements should correctly resize or move when the window is resized, when the window is maximized, and when the window is restored after being maximized.

Everything is always visible

Reducing the size of the window should not lead to the disappearance of window elements and preferably should not lead to the appearance of scrollbars (scrollers) of the window itself. You can limit the minimum size of the window so that all elements are visible and accessible. If it is not possible to place components in such a way that everyone is visible in the window, you can use tabs (of type PageControl) to divide components into groups. Excuses about screen resolution are also not missed.

Hints everywhere, hints always

For buttons, especially on toolbars (such as ToolBar), hints should be given so that it is always clear why this or that button is needed.

Color spectrum

It is not necessary to paint the components on the form in all the colors of the rainbow. This tires the eyes and scatters the user's attention. It doesn't look "cool". Highlighting is used when it is necessary to draw the user's attention to a particular element or a particular part of the window. For example, you can color the entries with errors in light red color or, on the contrary, light green color of the entries, the verification of which was successful.

Conclusion

There is a very good method that allows you to find the shortcomings of the program in general and the interface in particular. It is simple: imagine yourself in the place of the user and for half an hour try to work the way he works. It's even better if your user is within reach (e.g. works in the same organization). In this case, sit next to him, or rather instead of him, and try to do his job. Enter data, change them, display reports, etc. If you don't know how to do it right, ask your user. Do not one or two operations of the same type, as in debug mode, but 20-30 or even more different operations, in a different order. Forget to enter something or enter it incorrectly and see how the program reacts to it. You will quickly see the weak points of your program.

The author of the article automated the work of the admission committee at the university, and in the first year of the program implementation, he spent 3-4 hours a day at the admission committee, registering applicants, filling in their personal data and giving them exam reports. And in the remaining working time, corrected errors and shortcomings. Believe me, the next year there are practically no problems left. It was the same with the introduction of the personnel module.

Thus, keep the user experience in mind. Let it be easy and pleasant for them to work with your programs.