Про объём сделки

Встречный вопрос, под объемом сделки вы понимаете фактически: кол-во контрактов*цену?

Я думаю, что тот, кто сможет ответить на вопрос, сделает это без уточнения =)

Количество контрактов это цифра ни о чём -- цена указывается за 1 бумагу, а в контракте бумаг может быть 100. У эффективных менеджеров ВТБ размер контракта вообще 1000 бумаг.

Я может лезу не разобравшись, но во первых, Trade содержит поле Volume и это поле содержит количество приобретенных или проданных лотов. Сколько контрактов в одном лоте - это информация из Security. Смотрите исходные таблицы в Quik (инструменты, все сделки)

В общем! Поле таблицы Квика "Объем" прям в Trade никуда не выгружается, за то есть Ext. info расширенная информация по сделке. В событии получения неопределенных DDE данных можно отлавливать эту колонку "Объем" и запихивать ее в Ext. info расширенная информация по сделке.

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

Как я его понял (возможно ошибочно), - есть например агрессивная покупка (по аску) в 10 контрактов и она прошла в 3 сделки - 5+3+2 например, то по таблице всех сделок мы увидим 3 сделки но размер (Volume?) начальной заявки нет, но, судя по ltrim, он возможно выгружается в каком то другом месте/поле.
Вычислить его ессно нельзя.

С уважением!

Полностью не уверен, но такое даже биржей не транслируется, чтобы по тиковой сделке можно было бы узнать объем первоначальной заявки.

Foxbow: Только в том случае, если у вас есть инструмент =) А когда инструмента нет, узнать размер лота не получится.

ltrim: это-то понятно, интересно было, зачем у сделки нет стоимости.

ustas: У меня всё спокойно, без агрессии ;) Просто смотрю на весь рынок бумаг.

Mikhail Sukhov: Это поле не вычисляется без инструмента, которого может не быть по триллиарду причин -- не успел загрузиться, нет в таблице инструментов, что-нибудь ещё.

Я понял о чем речь. Но нестандартные задачи требуют нестандартных решений. То, что это нестандартное решение говорит хотя бы то, что Вы первый, кто это запросил[smile]. В данном случае - ExtensionInfo.

Как фича, которую сделал для следующего релиза - возможность оперировать своими типами данных, производными от стандартных. Это мне понадобилось как раз при работе с ExtensionInfo. Например, текущая работа с опционами:



А вот как будет можно:



Благодаря небольшой магии ввиде:

Так эта магия и сейчас должна работать =)
Только с нюансом -- надо определять оператор преобразования типа. Но этот нюанс и в вашем случае надо реализовывать. По мне экстеншен был бы здесь в самый раз, классы нужны для инкапсуляции состояния в основном.

Кстати, использование "base." разумно только в виртуальном методе для вызова самого себя вверх по цепочке наследования. Полагаю, что в вашем коде это последствия любви к "this.", но разница между ними в том, что использование "base." где попало приведёт рано или поздно к необъяснимым логическим ошибкам.

И совсем не в тему =) В прошлом году в MSDN Magazine Тэд Ньюард начал писать серию статей "Мультипарадигматическая .NET". Советую обратить на неё внимание, там очень хорошо описываются базовые принципы построения ПО, которые не знает подавляющее большинство разработчиков. Вот, например, вторая статья: http://msdn.microsoft.co...u/magazine/gg232770.aspx