Discussion of article "MQL as a Markup Tool for the Graphical Interface of MQL Programs. Part 1" - page 5
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Is there such a thing, to write an article about a GUI and not take a single screenshot?
When an article is big, it's forced to be split into parts, having to shuffle the material around, and screenshots were left in the sequels. The screenshot of "Spotlight" completely coincides with the previous article about GUI, so I limited myself to the phrase that the appearance hasn't changed.
When an article is large, it's forced to be split into parts, having to shuffle the material, and the screenshots were left in the sequels. The screenshot of "Spots" completely coincides with the previous article about GUI, so I limited myself to the phrase that the appearance hasn't changed.
When pressing the left mouse button, when the cursor goes outside the button and the mouse is released, I get this picture. Also, after dragging the spots, you can drag the price chart through them. Can this be corrected?
When I press the left mouse button, the cursor goes outside the button and the mouse is released, I get this picture. Also, after dragging the spots, you can drag the price chart through them. Can this be corrected?
"Such a picture" - do you mean different colour of the fields? I have not observed such a picture. PS. I managed to reproduce it. I'll see what's wrong, but it's not a markup problem, it's how the standard buttons work.
Regarding dragging the chart, if I understand correctly what you mean, try replacing this file (it's from the next post).
Ok, finally I've got you. You are concentrated mostly on technology rather than usage. Nice done.
The technology has been tested and is ready for use. And your proposal?
I'm sorry for my stupid question, but what kind of GUI you are trying to build which cannot be done (or pretty hard to do it) within standard MQL libs?
Moreover, I see the realisation is pretty complicated from the beginning. Maybe it could be better to look into jQuery style of UI implementation?
For example simple button creation could looks like:
Of course it needs to have own "objects generator" and so on, and it's also possible to make it extendable and support "user-defined" objects, like with shadow effects, gradients, etc.
So, it could be more easy for developer to build GUI in such way.
Also it is possible to build an application like MT GUI Builder for visual creation of GUI and exporting JSON file for fast implementation on MQL side...
It's just my thoughts after reading article and my opinion.
Of course you are on your own way.
Best regards,
Eugene
Eugene, you are a Russian speaker, and you speak Russian perfectly well. Why such disrespect in the Russian part of the forum?
You're a Russian speaker. Write in Russian. Or at least use the inbuilt translator in the message editor.
"This pattern" - do you mean the different colour of the fields? I have not observed such a pattern. PS. I managed to reproduce it. I'll see what's wrong, but it's not a markup problem, it's how the standard buttons work.
Regarding dragging the chart, if I understand correctly what you mean, try replacing this file (it's from the next post).
With the new file, dragging through the window is fixed.
What's left is this :)
Left mouse click in a square with a number, drag away from that square and release. The shading does not disappear.
With the new file, dragging through the window has been fixed.
This remains :)
Left mouse click in a square with a number, move away from that square and release. The shading does not disappear.
Yeah, I get it. But that's how the buttons in the standard library work from the beginning. There was no purpose to edit it in all directions, especially since the problem is very specific - I never had a desire to press the button on purpose and drag without pressing it. It's not a very obvious use case after all.
Yeah, I get it. But that's how the buttons in the standard library work from the beginning. I didn't want to modify it in all directions, especially since the problem is very specific - I've never had a desire to press a button on purpose and drag it without pressing it. It's not a very obvious use case after all.
Doesn't the right mouse click event come up in this situation?
That depends. Events come to the object based on coordinates. When the cursor is outside the button or window, they get nothing. Even drag'n'drop works on this principle - a constantly moving object is created under the cursor. A slightly different edit is needed there.