Обсуждение статьи "Язык MQL как средство разметки графического интерфейса MQL-программ (Часть 1)" - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Всё есть в документации, изучайте, пользуйтесь.
Как получить и передать ссылку на класс в документации есть, но вот на функции не встречал. Если не сложно можно ссылку?
Я вам дал ссылку на справку. Там описано как создать указатель на функцию.
Я вам дал ссылку на справку. Там описано как создать указатель на функцию.
Дмитрий Федосеев, хоть и обидно, но очень смешная вставка видео. Долго смеялся. Когда почитал выделенное вами, понял, что выглядит действительно глупо. Точнее было сказать не переписал, а улучшил и дополнил. Прочитал очень много ваших статей, за пятилетнее присутствие на этом сайте, и не сомневаюсь в том ваш багаж знаний намного больше моего, но в том что в экспретописательстве не возникает надобности в ООП, с вами не согласен. Так как в сложных программах, с использованием графических интерфейсов, объединении нескольких ТС в один советник, ведение статистики и тд, ООП очень помогает, лучше структуировать код программы, а шаблоны проектирования (хотя я еще в самом начале пути их изучения) увеличивают силу ООП в разы. Конечно это не значит, что толкать нужно в небольшой советник, где можно обойтись обычными процедурами, и скорость его написания будет в разы больше. Если будет интересно я опишу пример, где я применил ООП и один шаблон, и как это мне упростило жизнь. И если не сложно Дмитрий, не могли бы вы на примере показать свои слова "и уж тем более в создании аналога делегата с использованием ООП в то время, когда есть указатели на функции". Или в какой статье можно почерпнуть информацию об указателях на функции. Заранее спасибо.
Указатели на функции - в справке ищите "typedef". В с# есть делегаты, а не указатели на функции, только потому что весь язык объектно-ориентированный, там все что нужно и не нужно через объекты делается.
Совсем ООП я не отвергал, наоборот, оно очень полезно и удобно, если только применение ООП не становится самоцелью и не превращается в обязательное следование каким-то канонам.
А кого конкретно вы имеете ввиду? Тем более, что во множественном числе, а нас тут не так много. Было бы в единственном числе, я бы подумал, что это про Петра... но во множественном. Возникают вопросы.
Слабо прямо по имени обратиться? Что бы лишних вопросов не возникало лишних вопросов. Или можете только воздух пространно пинать?
Прямо по имени намеренно не буду никого называть, не люблю базаров. Множественное число для обобщения. Любой любитель разглагольствовать с позиции знатока, основываясь на доморощенных смехотворных решениях, пусть проходит мимо, в свои ветки.
Прямо по имени намеренно не буду никого называть, не люблю базаров. Множественное число для обобщения. Любой любитель разглагольствовать с позиции знатока, основываясь на доморощенных смехотворных решениях, пусть проходит мимо, в свои ветки.
А каковы критерии "смехотворности" в вашем понимании? Разве не претендуете на создание "доморощенного" языка разметки? Разве не с позиции "знатока" вы судите о технологии, о которой в статье не смогли сказать ничего вразумительного? Добро пожаловать в клуб дилетантов.)) Просто, у некоторых присутствующих, в этой области (в отличии от вас) есть гораздо больше понимания. Так что, не нужно "задирать нос".
Если считаете, что можно "в тихую" списать чужой язык и не раскрывая концепции преподнести как готовое решение - наивно.
Мне, например, интересны альтернативные решения создания языка разметки. Моя технология мне известна и хочется узнать, как это делают другие. Взгляды на проблематику со стороны. Вполне законно. Поэтому, ищу четкую, понятную и целостную концепцию. А вы чего хотели от читателей? - безропотного согласия?)))
Поэтому, просьба быть адекватным и обсуждать решения и принимать критику спокойно.)))
Прямо по имени намеренно не буду никого называть, не люблю базаров. Множественное число для обобщения. Любой любитель разглагольствовать с позиции знатока, основываясь на доморощенных смехотворных решениях, пусть проходит мимо, в свои ветки.
Замечательно, тогда вы возглавляете этот обобщенный список.
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 realization 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.
Да, подходы могут быть разные. Про ваши варианты я упомянул, они потребовали бы парсинга сторонних форматов, а внутри их работа ничем не отличалась бы от того, что сделано сейчас. Предложенная концепция - встроить всё в MQL и не иметь зависимостей.