Discussion of article "Graphical Interfaces X: Text selection in the Multiline Text box (build 13)"
Cool! What's the status of pasting from the buffer?
I haven't contacted the developers at servicedesk with such a request yet.
Probably, it is necessary not only to insert from the buffer, but also to send to the buffer, so that you can transfer text between your input fields, if such a need arises.
Most likely we need the ability to handle system events caused by pressing Ctrl + X (cut), Ctrl + C (copy) and Ctrl + V (paste).
This is going to be curious:)
Will you show the new drawn elements in the next article? That would be very curious:)
1. Yes. All elements will eventually be drawn elements. As part of the second stage of development: 1 element=1 object (canvas for drawing).
2. Yes. Just like all elements that are already drawn used this CCanvas class. It already has ready methods for drawing simple graphical shapes. It's a good class, which if it didn't exist, you would have to implement it yourself. In those elements of the library, which are already drawn, methods for pixel-by-pixel drawing and lines, text output, as well as shapes such as rectangle, rectangle with fill are used.
...
The OOP approach is much simpler than you described. The changes in the library scheme already described before are minimal. In the end, everything will be even more convenient and much better than it is now.
This very recipe of system development without its internal rebirth is completely unknown to me. It's just like a grail - I want to believe that there is one, but it's unlikely....
Of course, it's not very difficult to draw an element. Almost everything can be drawn from rectangles (except gradient), but another event model must be created. The OnChartEvent() function will no longer provide fixation of click events on the drawn element pattern. Nor will Zorder for prioritisation help. A long time ago I told you about creating an object map, and listed its advantages, but then you refused this solution, and now, you can't go anywhere without it.
There is no doubt that drawn elements have more properties, and interaction with them is much more complex. In this technology, the system should be more holistic and the mechanisms more universal. For example, there should be a common memory for all interface elements, containing the values of all their properties. This is a more efficient solution than creating many separate arrays and variables in different structures and classes. All OOP conventions (reference objects to access variables of other classes from which you need to get the value of some property of some object, for example) will only slow down and complicate the work, not simplify it. OOP has one more disadvantage, because of which I do not regret that I do not have the advantage of using other people's classes as you do. A developer who uses in his development blocks created by other people, knows his development worse than the one who created everything himself, and in addition he is more limited in the possibility of improvement in his development not only because he knows it worse, but also because he will not redesign other people's blocks, as it is not provided by the "professional style" of development.
All of the above is just my opinion and I have finished it.
I will look with interest at further development of the library.
Of course, drawing an element is not very difficult. Almost everything can be drawn from rectangles (except gradient), but another event model must be created. The OnChartEvent() function will no longer provide fixing of click events on the drawn element detail. Nor will Zorder for prioritisation help. A long time ago I told you about creating an object map, and listed its advantages, but then you refused this solution, and now, you are nowhere without it.
You are wrong, as always. Here are examples, where even in the current model I don't have the problems you described (see GIF-animations below). The table is drawn and interaction with it is one of the most complicated of all existing elements, if not to say the most complicated. Also, this is not the final version yet. Perhaps already in the next article there will be a final code for this table.
//---
Please show me how you have implemented the same thing.
//---
... There is no doubt that drawn elements have more properties, and interaction with them is much more complex. In this technology, the system should be more holistic and the mechanisms more universal. For example, there should be a common memory for all interface elements, containing the values of all their properties. This is more efficient than creating many separate arrays and variables in different structures and classes.
I find it much easier to interact with drawn elements. Gradually everything will become as universal as possible. Actually from article to article in this series this process should be noticeable, if of course you read carefully and not just look at pictures. You can make a shared memory, or you can just provide easy access from one class to the properties of each element, as I did. You can't categorically state that it should be this way and not the other way round. No one owes anyone anything. In your developments you can do as it is convenient for you. I prefer to have my own opinion on this or that account. As my personal practice and life experience shows me, much of what others say is wrong. At the same time, I do not exclude myself from this number. But I am not afraid to be wrong and if I am wrong, I just look for a way to correct the mistake.
... All OOP conventions (reference objects for accessing variables of other classes from which you need to get the value of some property of some object, for example) will only slow down and complicate the work, not simplify it.
In your case - yes, in mine - no. )
Retag Konow:
OOP has one more disadvantage, for which I do not regret that I do not have the advantage of using other people's classes as you do. A developer who uses blocks created by other people in his development knows his development worse than the one who created everything himself, and in addition he is more limited in the possibility of improving his development not only because he knows it worse, but also because he will not redesign other people's blocks, as it is not provided by the "professional style" of development.
In this case, start from scratch and on your own. Write your own OS, then write a trading terminal with the MQL language, and then start developing your own library for creating graphical interfaces. After you have done all this, you can proudly knock your heel in your chest. )))
//---
P.S. And for me the task was:
- To practice programming.
- Write for myself a library for creating graphical interfaces with a quality that would satisfy me.
- To share this development with MQL-community.
- At least partially offset the labour costs of development. Thanks to MQ for supporting the project.
I think it turned out very well. At least I'm not the only one who likes the result. :)
Anatoly, I have stated my opinion, and I have no desire to get into another bitter argument with you.
My tables are not finished, but the example you have demonstrated works the same way. The table is interactive, there are pictures in cells, checkboxes, and even the columns also change width. Of course, not everything works perfectly yet.... The appearance is a bit different. Adding columns and columns is not implemented yet. I won't show it here, or I'll get banned for PR again.
All I'm talking about is the experience that I gained in the process of hard work, and the fact that I share it, should not be perceived as hostile. After all, who else here with you will be able to discuss all these issues on an equal footing?
Good luck.
Anatoly, I have stated my opinion, and I have no desire to get into another bitter argument with you.
Alright, I will not distract you. )
My tables are not finished, but the example you have demonstrated works the same way. The table is interactive, there are pictures in cells, checkboxes, and even the columns also change width. Of course, not everything works perfectly yet.... The appearance is a bit different. Adding columns and columns is not implemented yet. I won't show it here, or I'll be banned for PR again.
You have a great opportunity to read articles on this topic and even use the solutions posted in the source code easily and simply adapting them to your scheme.
You can publish the results on your blog. I am following your publications. ;)
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article Graphical Interfaces X: Text selection in the Multiline Text box (build 13) has been published:
This article will implement the ability to select text using various key combinations and deletion of the selected text, similar to the way it is done in any other text editor. In addition, we will continue to optimize the code and prepare the classes to move on to the final process of the second stage of the library's evolution, where all controls will be rendered as separate images (canvases).
The CTextBox::DeleteSelectedText() method is called not only when pressing the Backspace key, but also: (1) when entering a new character and (2) when pressing the Enter key. In these cases, the text is deleted first, and then the action corresponding to the pressed key is performed.
This is how it looks in the finished application:
Fig. 7. Demonstration of deleting the selected text.
Author: Anatoli Kazharski