Делаем краудсорсовый проект по Canvas - страница 4

 
Vasiliy Sokolov:

Мне кажется, что после статей Анатолия снова создавать теже яйца только в профиль, - как минимум странное времяприпровождение. Графика это вообще не актуальная тема для МТ.

  • Пользователям  ненужны графические интерфейсы. Как следствие, монитизировать графический интерфейс невозможно и его разработка никода не окупиться.
  • Если хотите поднять скиллы, то уж лучше сразу куда-нибудь джуниором устроиться. Так хоть какую-то деньгу сразу получать начнете и потехоньку скиллы поднимите.
  • Слишком узкая целевая аудитория. Кому нужны библиотеки? - Абсолютно никому, кроме горстки программистов, да и те уже давным давно все нужные им библиотеки написали. У меня например своих графических библиотек, аж целых две.

Не мне учить здесь присутствующих, но совет дать могу: ребята, понюхайте пороху. Поучитесь работать с пользователями. Выясните их психологию. Научитесь монитизировать свои идеи. Тогда быстро с небес на землю спуститесь и будете рассуждать совсем по-другому. Я тоже когда-то верил в какие-то особенные и красивые идеи, но все это бред, это не работает. То что Вы здесь обсуждаете, никому кроме Вас ненужно. 

+1

Большинству так называемых "трейдеров" не нужна красота им бабло нужно, на крайняк советники с гипер супер технологими обсчета цены в третьей фазе луны, потому что звучит красиво и похвастаться можно и надежда есть в чудо технологии..

А библы которые работают только в демо или реале с красотульками мало кому нужны, точнее нужы кому мало бало нужно )))

 

Vladimir Pastushak:

А библы которые работают только в демо или реале с красотульками мало кому нужны, точнее нужы кому мало бало нужно )))

повторюсь, мы не делаем библы.

мы решаем задачу.

эта ветка не для мерянья, а для решения конкретных задач.

Владимир, вы или наблюдайте без негативных коментов или присоединяйтесь. Но в этой ветке вас не будут обучать ООП или фазам луны.

 
o_O:

повторюсь, мы не делаем библы.

мы решаем задачу.

эта ветка не для мерянья, а для решения конкретных задач.

Владимир, вы или наблюдайте без негативных коментов или присоединяйтесь. Но в этой ветке вас не будут обучать ООП или фазам луны.

Присоединиться не могу так как не владею ООП в полной мере.

Я просто попытался сэкономить Вам Ваше время.

Я перехожу на сторону наблюдателей... 

 
Zorro:
А вот с полем ввода беда - пока нет хорошей идеи, как заюзать то, что нам доступно.

ИМХО сейчас, можно сделать полноценный EDIT, только если рисовать свою GUI клавиатуру, но будет тяжело поддерживать языки, да и неудобно мышкой набирать текст...

а какие нужны доп.возможнеости работы с событиями или чартами, чтоб ничто не мешало вводу?

попросим в СД доработки.

 
Vladimir Pastushak:

Я например такие вещи вообще не понимаю :

a >> 0 << 0;                       //нет сообщения об ошибке
a.operator>>( 0 ).operator<<( 0 ); //error: правомерно 

 Покажите мне в документации или еще где то где я могу научиться и понять где такое применять и как вообще это понимать...

По поводу кода - обратитесь в сервис-деск. Интересно, что скажут. По поводу обучения и понимания, поскольку MQL пишется по примеру С++, посмотрите соответствующие доки - их много. А в принципе, можете открыть другую ветку с такими вопросами, хотя похожие ветки по ООП тоже уже были.
 
Vasiliy Sokolov:

... Графика это вообще не актуальная тема для МТ ...

Так дело не просто в графике. То, что здесь предлагается, даст возможность создавать графические интерфейсы самого высокого качества. Ограничиваясь примитивами стандартных графических объектов, приходишь к тому, что многого не хватает. Кроме этого, приходится оперировать очень большим количеством графических объектов, что может мешать в некоторых случаях.

Некоторые тратят своё время, на какие-то развлечения или игры, а есть люди, для которых развлечение это решение, каких-то интересных и полезных задач. Многие на этом форуме вообще прожигают своё время просто на пустую болтовню.

Я бы с удовольствием принял участие здесь, но у меня сейчас и своих задач пока выше крыши. )

 
Очень интересно понять, уважаемые форумчане, что здесь собственно предлагается сделать, что позволит создавать графические интерфейсы "очень высокого качества". Честно говоря, совершенно не понял.
 
Поправте меня если я ошибаюсь, но суть задачи - реализовать элементы управления используя как можно меньше графических объектов, за счет прорисовки их деталей в картинке? Если да, то как будет работать слайдер например, если его полностью нарисовать? Для него необходимы, как минимум два взаимодействующих объекта...
 
Реter Konow:

используя как можно меньше графических объектов

не просто меньше - а вообще никакие (кроме bitmap_label, на которой все и рисуется)

как будет работать слайдер например, если его полностью нарисовать? Для него необходимы, как минимум два взаимодействующих объекта...

вы про прижатую мышку на ползунке?

----

на данный момент есть пока что одна проблема, про которую писал Zorro - поле ввода.

Чартовые события не дают коды всех клавиш.  К тому же чарт перехватывает пробел и enter.

 
o_O:

не просто меньше - а вообще никакие (кроме bitmap_label, на которой все и рисуется)

вы про прижатую мышку на ползунке?

----

на данный момент есть пока что одна проблема, про которую писал Zorro - поле ввода.

Чартовые события не дают коды всех клавиш.  К тому же чарт перехватывает пробел и enter.

Не совсем про мышку.

Мне в принципе непонятен механизм работы элемента управления "слайдер", который полностью нарисован.

Основная функция слайдера - конвертировать расстояние между двумя точками - А и В, в значение пользовательского параметра используя при этом заданную пропорцию и шаг.

В моей реализации, точки А и В представлены местоположением двух объектов - координатой Х колеи слайдера (ее началом) и координатой Х ползунка слайдера. Функция замеряет расстояние между двумя точками и конвертирует его в значение параметра.

Если оба объекта слить в картинке, то как будет находится точка А и точка В? В этом случае, эти точки будут просто пикселями изображения.

Как пиксели будут возвращать свои координаты, для замера расстояния между точками?

Каким образом будет меняться картинка, при перемещение ползунка?

Как будет возвращаться точное место ухвата ползунка(относительно его х-координаты) и фиксироваться границы его хода?

И как будет осуществлятся коррекция положения ползунка при выходе за границы хода?

Все эти механизмы работают в моей реализации слайдера, и мне не понятна предлагаемая технология, хотя я понимаю, что существенно сократить количество объектов данным способом можно.

Причина обращения: