Мой подход. Ядро - Движок. - страница 86

Новый комментарий
 
Петр, как понял по гифке с эллипсом, форма это один сплошной канвас? А как выпадающие списки работают? Интересует тот случай, когда выпадающий список превышает размер формы.
 
Vasiliy Sokolov:

Скажу так, - мне самому не нравится некоторая корявость моего решения. Нужно создавать МТ-объекты. Но, на деле, это всего лишь предвзятость. Какая разница? Для полной передачи их нужно не более 20 -30 штук.

30*64 символа = 1920 символов. Этого достаточно для передачи данных больших таблиц.

 
Dmitry Fedoseev:
Петр, как понял по гифке с эллипсом, форма это один сплошной канвас? А как выпадающие списки работают? Интересует тот случай, когда выпадающий список превышает размер формы.

Да, форма это один канвас. Конструктор сам записывает имена канвасов и делает функции обертки для работы с ними. 

Выпадающие списки работают и в области за пределами окна. Это реализовано.

Вып. список - это еще один канвас. Он появляется и исчезает при нажатии на кнопку.

 
Vasiliy Sokolov:

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

С удовольствием принял бы это решение, если бы ты предоставил пример. 

 

Поосторожней там с обменом данными через граф.объекты :-)

а то лёгким движением руки можно вбить советник в вид "оптимизации не подлежит"..

 
Реter Konow:

Мое решение - лучший вариант при исходных условиях.

Что такое строка:

  1. Отсутствие фиксированного размера. Как следствие, невозможно организовать массив строк, и доступ к произвольной строке в этом массиве;
  2. Полное отсутствие типизации данных в строке. Подтип приходится определять динамически внутри парсинга строки. Тратится драгоценное время на разбор нужных лексем; А если лексемы содержат ошибки - строка это никак не контролирует. Получил строку и молись что бы она была верно составлена;
  3. Низкая эффективность хранения информации на один байт. Служебная строка вроде "opt=1;cancel=3" в лучшем случае использует 35-40 знаков (байтов) из 256 возможных (17%). Что бы послать 100 байт информации ты должен сформировать строку  размером 588 байт, нагружая канал связи. Если ты будешь сжимать символы - это серьезно усложнит код. Если ты будешь сокращать названия переменных это поможет лишь немного.

И не смотря на все эти очевидные вещи, ты как Робин Гуд продолжаешь вещать какой-ты быстрый и меткий, и как ты здорово угадал со строкой. Нет, не угадал, и все это очень не здорово.

Не пытайся выехать на своей интуиции, там где нужны фундаментальные знания.

 
Vasiliy Sokolov:

Что такое строка:

  1. Отсутствие фиксированного размера. Как следствие, невозможно организовать массив строк, и доступ к произвольной строке в этом массиве;
  2. Полное отсутствие типизации данных в строке. Подтип приходится определять динамически внутри парсинга строки. Тратится драгоценное время на разбор нужных лексем; А если лексемы содержат ошибки - строка это никак не контролирует. Получил строку и молись что бы она была верно составлена;
  3. Низкая эффективность хранения информации на один байт. Служебная строка вроде "opt=1;cancel=3" в лучшем случае использует 35-40 знаков (байтов) из 256 возможных (17%). Что бы послать 100 байт информации ты должен сформировать строку  размером 588 байт, нагружая канал связи. Если ты будешь сжимать символы - это серьезно усложнит код. Если ты будешь сокращать названия переменных это поможет лишь немного.

И не смотря на все эти очевидные вещи, ты как Робин Гуд продолжаешь вещать какой-ты быстрый и меткий, и как ты здорово угадал со строкой. Нет, не угадал, и все это очень не здорово.

Не пытайся выехать на своей интуиции, там где нужны фундаментальные знания.

Василий, а ты не думаешь, что разработчики МТ учли проблемы строк, при сохранении описания МТ-объектов?

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

 
Реter Konow:

Василий, а ты не думаешь, что разработчики МТ учли проблемы строк, при сохранении описания МТ-объектов?

Петр, у каждого алгоритма хранения данных есть свои слабые и сильные стороны. Разработчики конечно учли многое, и они безусловно молодцы, но фундаментально строки всегда останутся строками.

 
Vasiliy Sokolov:

Петр, у каждого алгоритма хранения данных есть свои слабые и сильные стороны. Разработчики конечно учли многое, и они безусловно молодцы, но фундаментально строки всегда останутся строками.

Василий, если практика покажет дефектность моего решения, я откажусь от него. И возьму решение Николая. Если и это будет плохо, вернусь к OnChartEvent() и скажу, что ничего поделать нельзя.

Однако, пока нет причин считать, что реализация моего решения будет хромой. 

Скоро выясним.

 
з.ы. Конкретно по теме хранения строк в объектах MT есть один странный глючок. Если ты начнешь сжимать данные и пользоваться непечатными символами в названии объекта, то в некоторых случаях ты не получишь доступ к этому объекту. Глюк скорее всего есть до сих пор, потому что он очень специфический и мало кто о нем знает, тем не менее ты на него можешь наткнутся.
1...798081828384858687888990919293...184
Новый комментарий