Discussion of article "Graphical Interfaces VI: the Slider and the Dual Slider Controls (Chapter 2)"
I am interested in your comments and suggestions.
I need clarification.
- How do you separate the concept of main window and settings window ?
- What features do you suggest to add to the current implementation of the window so that it can be called "main" ?
As for the examples presented in the articles, my goal was to show how the elements work in different combinations. It's just a way to demonstrate the non-conflicting nature of different types of elements. This is especially true for dropdown elements and elements that use scrollbars.
...
If you make the main application window composite, you will give all developers the opportunity to choose the "main" content for it. In my opinion - the "composability " is the distinctive feature of the "main" application window.
In any case, I think you should look into developing the capabilities of your windows.
Thought. The current library structure allows to implement such functionality. But before we start implementing it, we need to solve a number of other issues to make it quite beautiful. I see several options. I don't know which one I will use yet, as I need to conduct a number of experiments and tests to choose the least resource-intensive one.
I'll do it after the planned articles of the current series are published. The most complex and interesting from the point of view of development controls are left.
In general, I don't promise to do it quickly, because besides that I also planned to optimise the code in the current version and make some additions and fixes, which should significantly reduce resource consumption. And there is also such a point that when talking about optimisation and attempts to reduce resource consumption, it is still unknown whether you will be able to get any gain in the end. It happens that you can spend a lot of time, and when you come to the finish line you will see that it is no use at all. But it does not scare me. If you don't try, you won't know. ;)
However, a very interesting way of putting the question.... Personally, it never occurred to me that optimisation and reduction of resource consumption can be unnecessary and even harmful, and at the "finish line" not be useful. You have me stumped.... One can certainly have a discussion or argument on this topic, but I'm unlikely to find enough arguments, as I've never looked at the issue from this side.
...
It is not my words that "optimising and reducing resource consumption may be unnecessary and even harmful". In my case, optimisation has to be done and there will definitely be a gain. I will just do it and if there is a result, I will write an article about it. Right now there is just not enough time to elaborate on it.
Is the whole OOP syntax really necessary? For example: why pass variables into functions when you can make them visible at the global level? Why connect classes when you can connect function files? Files do not require a complex system of interconnection of functions,creation of classobjects to access functions and variables. Why a colossal clutter of rules and various syntax, which distracts from the essence of the problem to be solved and confuses.
Try to do the same thing, but without OOP. So that everything works exactly like this. I tried it first and came to the conclusion that without OOP it is very difficult to do such a project, even if you do it only for yourself. I can navigate in this structure very easily now. Everything is organised and in its place. There is access to all objects and elements of the library. They don't overlap with each other and are only accessed where they can, each has its own type and name. I can see where I can refactor, optimise code and some algorithms, reduce resource consumption.
Everyone can contribute not only suggestions, but also methods of solving some problems, if they see and know how. I have already received a lot of suggestions in private from different users about what and where to fix. On the English forum, too, some design errors regarding this library have been pointed out. I already know at least four factors that increase resource consumption. Some obviously consume unnecessarily and eliminating them will most likely yield results. But all this is only in theory for now. In any case, we need to do, run tests and only after that we can say whether there is any gain or not.
In any case, I consider arguments about which programming methods are better and which are worse pointless. Your experience may tell you one thing, and someone else may say exactly the opposite. Life is infinitely diverse in its variety. ;)
But the order as such is not tied to a particular method of its implementation. If you create an order in a programme by dividing functionality by classes, you should know that the same order can be repeated by dividing functionality by files.
Order - yes, but access and operation of many objects of different types - no. In my opinion, it is much easier in OOP.
If you create a enumeration or structure AS THESE, then THEY don't have to be done according to OOP rules, and with OOP syntax. You can just comment out the line and write "Structure A. List of elements:" and access to variables will be simplified. OOP does not help to order anything, but only offers a unified standard for writing a ready-made ordering scheme.
Why? Because you can create a full-fledged structure at once and then juggle with all this by declaring its instances, arrays and even arrays of arrays of instances. You can do it without OOP, but in my opinion, OOP is more convenient.
And how will access to variables be simplified when they are outside a structure or class? On the contrary, it is the well-thought-out scheme of order in OOP that helps to organise everything and simplify access to those variables that can be accessed and those that cannot be accessed - to close them altogether.
I can't argue with you here. Because OOP is generally accepted, the development of your library can be easily picked up by other programmers. I wish you that this will happen. :)
That's what this whole thing was started for. One head is good, but not enough. ;)
What's it to you, if it's no secret?
Ask the universe. We're just tools in its hands. ;)
Vanity?
No. Satisfaction. But not from vanity. I don't know why. Perhaps from partially thinning out the swarm of unrealised ideas and tasks in my head. And also writing articles disciplines me, as the responsibility is higher. I have significantly improved the code of this library, which I originally wrote for myself. And this is far from the limit.
Also, paying for articles is at least a small compensation for time spent.
Heads are lazy in the majority, and value finished products far more than toolkits with instructions or building materials from which to make those products. Being forced, they will use your library, but given the opportunity to reduce effort and create an interface without writing code, unfortunately they will quickly forget your beautiful library. This will be the very betrayal that society always subjects to honest and noble people who unselfishly give their efforts and soul to it.
Maybe most of them do, but not all. It is with them that I share. Just as they share with others.
By the way, I'm thinking of making a visual studio for creating graphical interfaces too. It will be created with the help of this library. I want to do something like it is done in Microsoft Visual Studio. And maybe even better. Time will tell. As usual, everything starts with small experiments. Even I don't know what I will get in the end. )
It seems to me that the community is ripe for a revolution in the practice of creating trading programs, and you want to provide another "upgrade". However, with all this, I wish you good luck. :)
Of course it is! That's why I decided to publish all this. To fix and move in this direction further. ;)
What ambition and what optimism!!! Just like mine...))))))
Could you please clarify to whom you are addressing your appeal - only me, or both Anatoly and I?
If to me, I have recently demonstrated the basic capabilities of my windows, scroll bars, table, and special effects.
To you, of course. Do you want to compete with Anatoly's well commented sources with your videos? In what category? )
To evaluate the programme, you need at least a demo version. It's an interface, you need to feel it.
That's why I urge you to stop talking about the "scary competitor" and move on to its demo ;)
... Ask Anatoly if he considers me a competitor. Let him tell you himself. :)
No, I don't consider you a competitor. I work in a different format and we do not overlap in any way. And I don't want to play the race either. I will work at my usual pace.
I publish material from my side only after I achieve more or less, in my opinion, acceptable quality.
By the way, the next article to be published is: Graphical Interfaces VII: Elements of "Tables" (Chapter 1). It will introduce as many as three classes of tables. ;)
I was hoping for a little competition! :) What a shame. Oh well. I've noticed that the community has a weak competitive spirit. When I asked about the competition in the market - they said that there is none, when I tried to support the initiative of another person to hold the championship - so participants are almost not found.... Boring as it is...;) Well and all right.
I will definitely look at future articles. Good luck. :)
Let's compete in quality and functionality.
Besides, I've already published 18 articles. That's 18 moves. No, 18 goals you've scored. And you haven't made a single one yet. I promise you at least 7 more. It's not very interesting when it's a one-goal game. ;)
- 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 VI: the Slider and the Dual Slider Controls (Chapter 2) has been published:
In the previous article, we have enriched our library with four controls frequently used in graphical interfaces: checkbox, edit, edit with checkbox and check combobox. The second chapter of the sixth part will be dedicated to the slider and the dual slider controls.
Author: Anatoli Kazharski