В Классы для создания панелей и диалогов нужно добавить класс для создания меню? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Создавать и тестировать меню думаю на основе панели диалога из папки: \Experts\Examples\Controls.
Файл Dialog.mqh переименовывается в DialogMenu.mqh и в этом файле класс CDialog переименовывается в CDialogMenu, а класс CAppDialog переименовывается в CAppDialogMenu.
Так как в проекте может быть несколько меню (например Настройки, Справка), а в самом меню может быть несколько пунктов, то будет два метода: метод добавления меню
Параметры
caption
[in] Надпись.
name
[in] Имя меню.
Возвращаемое значение
true в случае успеха, либо false в случае ошибки.
и метод добавления пункта меню
Параметры
caption
[in] Надпись.
parent_name
[in] Имя родительского меню.
Возвращаемое значение
true в случае успеха, либо false в случае ошибки.
Отметил первые 2 пункта.
Кому-то класс нужен, кому-то не нужен. Часть из тех, кому он нужен, нуждается не в таком классе, который создадите Вы.
Да и вообще, смысл опроса не понятен.
Вам нужен класс, так пишите! Хотите сделать его общедоступным - делайте. В чем проблема?
Отметил первые 2 пункта.
Кому-то класс нужен, кому-то не нужен. Часть из тех, кому он нужен, нуждается не в таком классе, который создадите Вы.
Знаете лично "... тех, кому он нужен, нуждается не в таком классе..." этих людей? И даже обсуждали программную реализацию? Или это просто содрогание воздуха?
Это опыт.
А с Вашей стороны это - эго. Класс нужен программисту, а программисту обычно нужен класс "под себя".
Знаете лично "... тех, кому он нужен, нуждается не в таком классе..." этих людей? И даже обсуждали программную реализацию? Или это просто содрогание воздуха?
Это опыт.
...
Если есть предложение по реализации, пожалуйста предлагайте, а если не знаете "... тех, кому он нужен, нуждается не в таком классе...", то говорите только от своего имени.
Еще раз повторю, коль не понятно.
Говорю из своего опыта и таков он у большинства профессиональных программистов. Нужен класс "под себя", если работает команда, то нужен класс под команду.
Если у Вас есть некоторое видение того, каким должен быть класс, то реализуйте его, а путь выспрашивания "что именно нужно в этом классе?" - тупиковый.
Если есть предложение по реализации, пожалуйста предлагайте, а если не знаете "... тех, кому он нужен, нуждается не в таком классе...", то говорите только от своего имени.
Доля правды в словах Contender'а есть. Мне например нужна большая гибкость и в будущем понадобиться размещать сложные интерактивные объекты прямо в меню. Одного текста явно недостаточно. Поэтому если и браться за проектирование меню, то с тем прицелом, что бы оно было более гибким и способным размещать в себе больше чем просто текст.
Вообще проблема стандартной библиотеки именно в том, что она стандартная. Она хороша и подходит для подавляющего большинства задач, но когда нужно сделать что-то особенное приходится изобретать свой велосипед. Например у меня уже один такой велосипед есть:
Поэтому в моем лице эти новшества все равно не будут востребованы.
Собственно вопрос - как в меню организуется визуализация иконка нажата и иконка отжата?
Это делается:
- Изначально картинка с прозрачным фоном и "иконка нажата" реализуется рисованием рамки и более темного заднего фона иконки. За счет прозрачности иконки будет виден более темный задний фон.
- Изначально существует две картинки - одна для "иконка нажата" и вторая для "иконка отжата".
Кто подскажет?1
пройдитесь парсером ресурсов по терминалу и сразу станет ясно
вопрос в вашей реализации, так как ГУИ придется делать самому