Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Andy77, Вы писали:

IT>>>Конвертеры в сад. Определяем свойство с нужной логикой во ViewModel и поехали.
A>>А как ты будешь ссылаться на сам объект, который нужно конвертировать? Пример — разрисовываем элементы ListBox'а в разные цвета в зависимости от значения.

IT>От какого значения?

Например, если ты байндишься на List<double> VolumesInMicroLiters и на этой же форме существует комбо бокс единиц измерения (миллилитры-литры-и т.д.) — в этом случае свойства никак не помогут (даже если и не нужно переводить в другие единицы, а, скажем, нужно просто отформатировать число).

Здравствуйте, Andy77, Вы писали:

A>Например, если ты байндишься на List<double> VolumesInMicroLiters и на этой же форме существует комбо бокс единиц измерения (миллилитры-литры-и т.д.) — в этом случае свойства никак не помогут (даже если и не нужно переводить в другие единицы, а, скажем, нужно просто отформатировать число).

Сделай List<MyFormattedDouble>. Делов-то.

Здравствуйте, IT, Вы писали:

IT>Сделай List<MyFormattedDouble>. Делов-то.

На каждый чих создавать по классу — слишком жирно будет.

Здравствуйте, Andy77, Вы писали:

A>Здравствуйте, IT, Вы писали:

IT>>Сделай List<MyFormattedDouble>. Делов-то.

A>На каждый чих создавать по классу — слишком жирно будет.

Ну тогда надо переходить на C.

Здравствуйте, Andy77, Вы писали:

A>Здравствуйте, IT, Вы писали:

IT>>Сделай List<MyFormattedDouble>. Делов-то.

A>На каждый чих создавать по классу — слишком жирно будет.

И тогда лучше вообще не чихать.

Здравствуйте, Andy77, Вы писали:

IT>>Сделай List<MyFormattedDouble>. Делов-то.
A>На каждый чих создавать по классу — слишком жирно будет.

Это как получится. Может по классу на два-три чиха. А конвертер точно будет по классу на чих. И, кстати, как ты собираешься контекст своему double передавать, чтобы конвертер отформатировал его в соответствии с комбобоксом?

Здравствуйте, Gollum, Вы писали:

G>Я тут попробовал описать свои впечатления от WinRT
G>Честно, даже не знаю куда отправить По логике вещей это надо в COM, или C++. Но самое главное уже более-менее понятно. Перед нами новая версия COM.

Нет. Кто вам сказал, что WinRT — новая версия COM? новое компонентное API для Windows 8 — Да

Здравствуйте, <Аноним>, Вы писали:

А>Нет. Кто вам сказал, что WinRT — новая версия COM? новое компонентное API для Windows 8 — Да

Андерс Хайлсберг и Герб Саттер Это новое компонентное API отличается от COM несколькими методами и одним интерфейсом.

Здравствуйте, IT, Вы писали:

IT>Это как получится. Может по классу на два-три чиха. А конвертер точно будет по классу на чих.

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

IT>И, кстати, как ты собираешься контекст своему double передавать, чтобы конвертер отформатировал его в соответствии с комбобоксом?

Через параметры:

<TextBlock  
    Text="{Binding ., 
           Mode=OneWay, 
           ConverterParameter={Binding SelectedItem, ElementName=unitsComboBox}, 
           Converter={StaticResource UnitConverter}}" />

Здравствуйте, Andy77, Вы писали:

A>Здравствуйте, IT, Вы писали:

IT>>Это как получится. Может по классу на два-три чиха. А конвертер точно будет по классу на чих.

A>Пойми меня правильно, мне конвертеры тоже не нравятся, я уже стал байндинги описывать лямбдами в коде, так стало проще и гибче.

IT>>И, кстати, как ты собираешься контекст своему double передавать, чтобы конвертер отформатировал его в соответствии с комбобоксом?

A>Через параметры:

A>

A><TextBlock  
A>    Text="{Binding ., 
A>           Mode=OneWay, 
A>           ConverterParameter={Binding SelectedItem, ElementName=unitsComboBox}, 
A>           Converter={StaticResource UnitConverter}}" />
A>

ConverterParameter в SL (а WinRT это SL), не был DependencyProperty, поэтому Binding на него не повесить.

Ну и вообще, какая разница, на каком языке написан WinRT? Главное, что объектная модель на бинарном уровне совместима с .NET, winmd файлы рефлектором читать можно,
вызовы маршалить не надо, никаких накладных расходов нет, графическое двигло от SL XAML жостко через DirectX рендерится (даже IE10 нервно завидует),
всё ядро уже при установке качественно С++ компилятором за-NGEN-ено, под текущую платформу заточено.

Программы работают на телефонах, х*ящиках, телевизорах, планшетах любых архитектур, десктопах — это ли не светлое будущее?

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, <Аноним>, Вы писали:

А>>Нет. Кто вам сказал, что WinRT — новая версия COM? новое компонентное API для Windows 8 — Да

G>Андерс Хайлсберг и Герб Саттер Это новое компонентное API отличается от COM несколькими методами и одним интерфейсом.

А также совместимыми форматами метаданных (winmd файл можно в рефлекторе паачитать са всеми кааментами),
отсутствием маршалинга (то бишь скорость вызовов как в .NET->.NET), ну и производительностью (ядро не надо JIT-ить)

Здравствуйте, Коваленко Дмитрий, Вы писали:


КД>Не угадал — я переехал с паскаля (в 96. тесноват стал, для моих задумок) на плюсы. Я конечно тогда тоже конкретно попарился, но по-большому счету из за глобального непонимания. И того, что многие базовые вещи (типа подсчета ссылок) пришлось выводить самому. Прорыв (в управлении объектами) произошел летом 2001, когда я сам допер, что у объекта может быть больше одного счетчика. Это было ночью. Утром я напился

Изобрел агрегацию? Возможность удерживать целое, держась лишь за его часть?

Здравствуйте, aloch, Вы писали:

A>А может быть и заведут свой отдельный счетчик чтобы IUnknown лишний раз не дергать (как это сделано в .Net).

Да, возможно. Виртуальные вызовы AddRef/Release дорогие, в сравнении с interlocked increment счетчика по простому указателю... В некоторых сценариях эффективнее будет аналог shared_ptr, который будет иметь свой счетчик, по достижении 0-ля которым произойдет один виртуальный вызов Release() целевого объекта.

Есть еще мнение. Отдать на откуп компилятора это имело смысл еще и затем, чтобы компилятор мог нивелировать избыточные парные вызовы increment/decrement в локальной области видимости в ходе оптимизации, как это делает компилятор нейтивного VB6. Для сравнения, компилируя "честный" С++ код, компилятор никак не может выкинуть избыточные парные вызовы методов AddRef/Release, потому как не имеет права делать предположения о семантике никаких виртуальных ф-ий, или взять инкременты/декременты счетчика, который не на стеке, но в куче (подход shared_ptr) — полностью аналогично, никаких допущений касаемо семантики. Поэтому и выходило в свое время, что для COM надо писать все на голых указателях и прыгать вокруг __finally, как это делает MS в своем коде, либо писать на VB, — оба подхода были всяко эффективнее, чем повальное использование CComPtr или _com_ptr_t в С++. Тут кстати ругали неоднократно MS за внутренний код на голых указателях, не понимая откуда ноги растут у такого подхода — это борьба за тики, за эффективную платформу системного уровня. Теперь MS "забила" себе на сейчас и будущее возможность точно знать семантику происходящего, что позволит развивать оптимизации в этом направлении. Например — даже юзать разные типы смарт-поинтеров, или не юзать их вообще в локальном коде, а только совершать итоговые инкременты/декременты по результатам всех локальных операций.

Здравствуйте, Hacker_Delphi, Вы писали:

H_D>одно маленькое замечание, COM как таковой изобретен вовсе не компанией MS. по-моему — это детище DEC. точно уже не помню.
H_D>и изначально там как раз были AddRef, Release, QueryInterface. только называлось это IInterface вроде как (хотя как раз тут могу путать).

QueryInterface был другой, а AddRef/Release (или аналогичное) использовали задолго до и не только в DEC. На самом деле COM, как самостоятельная технология — ничего интересного. Цель была в технологии для OLE, в маршаллинге, в динамических создаваемых по метаинформации из библиотеки типов бинарных проксях и стабах, в диспетчеризации м/у разными типами аппартаментов. Вот это уже целая навороченная платформа... А голый COM на фоне этого — ничто. Даже DCOM и COM+, по-сути, развитие именно OLE. Т.е. ввод буквально одной службы и пару интерфейсов в существующую OLE-инфраструктуру. Просто сама OLE очень обширна, примерно половину платформы занимают интерфейсы, обслуживающие визуальные компоненты, а они не нужны для DCOM/COM+.

Здравствуйте, hardcase, Вы писали:

H>Я, к слову, тоже не понял о чем речь. Поясните плз. эти два предложения внятными примерами.

Наверно речь о том, что контролы перестали ими быть в классическом понимании (как бы), но тем не менее всё еще могут продолжать ими быть через кастомный рендеринг. Т.е. их бы назвать следовало Сontroller, хотя бы чтобы не путать с классически устоявшимся взглядом на то, что есть Control в GUI.

Здравствуйте, Hacker_Delphi, Вы писали:

H_D>и ведь нельзя сказать, что у меня какой-то CRAY — обычный ноут с мобильной видюхой. правда видюха — nVidia. может в этом все и дело?
H_D>либо же нелицензионнная ось у тебя — как-то так.

Возможно дело в видюхе или дровах к ней, стоит 8600 невидия дискретная поверх интегрированой.
ПО поводу неолицензионной.... — MSDN Subscriber негодует , у мну вообще все операционки лицензионные, от MS-DOS до разных редакций W2008R2, ну и там еще куча софта впридачу.

Однако, кстати, МС-Офисом не пользуюсь, пользую Open Office. Есть фишка приятно потролить людей.
Сейчас объясню.

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

Так вот, если из МС-Офиса вордовский файл с заливкой пришел, то все редактируется в Опен-офисе. ОК.
Но! Все изменения по заливке фона текста что были сделаны Опен-офисе и сохранены в вордовский файл, при открытии в МС-офисе уже никак не изменить без лома. Т.е. манагер выделяет залитый желтым текст, хочет сменить или убрать цвет заливки в Ворде, кликает, но ничего не происходит! Полный игнор.
+1 к троллингу манагеров.
.

Здравствуйте, inviz, Вы писали:

I>Отменить затемнение экрана в настройках UAC религия не позволяет?

Я вам как программист программисту советую..

НЕ надо ничего тюнить в своей операционке, и никаких твикингов! НЕ надо ничего тюнить в таймингах памяти, проца и вольтажа на своей материнке. Комп у программиста должен быть средненьким на текущий момент по поколению и производительности — как офисная серая мышка.

Тогда и ПО у вас будет писаться быстрое и производительное, и работать оно будет предсказуемо у юзеров.
.

Здравствуйте, enCobalt, Вы писали:

C>Тогда и ПО у вас будет писаться быстрое и производительное, и работать оно будет предсказуемо у юзеров.

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