OpenFileDialog есть в mscorlib.dll PresentationFramework.dll и в System.Windows.Forms.dll. Соответственно, можно написать:


или


Есть ли разница, что использовать в приложении на WFP?



Исправлено 2 раз(а). Последнее : S-type, 06.10.16 00:09

IMHO Microsoft.Win32... лучше использовать только при КРАЙНЕЙ необходимости - когда нет других вариантов.

Igor Korolyov
IMHO Microsoft.Win32... лучше использовать только при КРАЙНЕЙ необходимости - когда нет других вариантов.

Обоснование будет?

Igor Korolyov
IMHO Microsoft.Win32... лучше использовать только при КРАЙНЕЙ необходимости - когда нет других вариантов.

Это я накосячил в вопросе, каюсь Не mscorlib.dll, а PresentationFramework.dll. Судя по всему, из за этого и Вы не поняли вопроса. Речь не о msdn.microsoft.com , а о msdn.microsoft.com , где сказано:

Пространство имен: Microsoft.Win32
Сборка: PresentationFramework (в PresentationFramework.dll)



Исправлено 1 раз(а). Последнее : S-type, 06.10.16 00:04

Возможно и так... Я так понимаю, то что данное WPF приложение окажется жёстко привязанным к виндовой десктопной платформе совсем не беспокоит? (Оно будет привязано в любом из вариантов использования данного диалога) - ну тогда видимо нужен вариант из PresentationFramework.dll

Igor Korolyov
Я так понимаю, то что данное WPF приложение окажется жёстко привязанным к виндовой десктопной платформе совсем не беспокоит?

Тут не стоит беспокоится - WPF кроссплатформенный чуть более, чем никак.

OFFTOP MODE ON
Я так понимаю, что на сегодня WPF это нечто среднее между психиатрическим экспериментом по сведению программистов с ума, и (мёртворождённым) плодом больного воображения идеологов из МС?
Куда его пришить и зачем оно надо - одни вопросы и никаких ответов...
OFFTOP MODE OFF

Интересно, почему openFileDialog есть и в PresentationFramework.dll и в System.Windows.Forms.dll, а ColorDialog только в System.Windows.Forms.dll? Какая религия помешала авторам WPF сделать обёртку над ColorDialog? [риторически]

Лень?

А может оставили ColorDialog для следующей версии, что бы можно было написать "WPF стал лучше"... Кстати, XAML будет развиваться? Есть какой то роадмап? Он вообще как то эволюционирует?

Судя по blogs.msdn.microsoft.com в WPF уже год не было новостей. А Роадмапу вообще скоро два года стукнет blogs.msdn.microsoft.com

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

Igor Korolyov
OFFTOP MODE ON
Я так понимаю, что на сегодня WPF это нечто среднее между психиатрическим экспериментом по сведению программистов с ума, и (мёртворождённым) плодом больного воображения идеологов из МС?
Куда его пришить и зачем оно надо - одни вопросы и никаких ответов...
OFFTOP MODE OFF

Не могу согласиться, идея там изначально довольно здравая - отделить функционал от внешнего вида, соответственно, работу программиста от работы дизайнера.
Второй плюс - практически безграничные возможности по созданию практически любого внешнего вида.
Другой вопрос, что любым инструментом нужно уметь рационально пользоваться. Скажем, если делать на WPF "как на WinForms", то особых прелестей заметить будет довольно проблематично.
А по поводу МС - лично мне сложно понять, почему хороший инструмент не особенно развивают, ведь вполне есть куда. Впрочем, тут как раз удивляться особо и не приходится.

S-type
Судя по blogs.msdn.microsoft.com в WPF уже год не было новостей. А Роадмапу вообще скоро два года стукнет blogs.msdn.microsoft.com
Неужто, всё так печально? Что же тогда изучать, что в будущем может пригодиться? На чём же писать десктопные приложения?

Фокс - не забывать

PaulWist
Фокс - не забывать

Конечно, жалко - что VFP остановился в своём развитии. С другой стороны, поработав на C# могу сказать - некоторые вещи в C# делаются гораздо проще (читай приятнее). Например, почитайте тему "Подпись XML (СМЭВ)" - это, по сути, "как побороть VFP"...

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

Даже это спорно. То что идея интересная - это да, а что она здравая... Ну мы на сегодня имеем сотни тысяч недо-программистов "на пхп" (я в общем имею в виду тех веб-дизайнеров-программистов которые и в дизайне не очень, и как программисты крайне слабы - не в пхп дело, конечно). Зачем делать то же самое в десктопном сегменте - лично я не понимаю. Я вообще сильно против всяких вычурностей в графическом интерфейсе...

SoccerStudio
Второй плюс - практически безграничные возможности по созданию практически любого внешнего вида.

Плюс ли это? Даже в примитивных квадратно-гнездовых дизайнерах UI типа фокса или "обычного" WinForms а ранее Delphi "непризнанные гении" умудрялись сооружать вырвиглазное г*но, а теперь именно ЭТО стало делать "проще и приятнее". Ну точнее был поставлен такой приоритет...

Те же тенденции развития шарпа - не проще/надёжнее/понятнее, а вычурность/сокрытие_смысла/глупое_псевдо_сокращение_буковок_кода... Из простого и понятного языка делают монстра, где досконально разобраться смогут лишь единицы, а профит от этих "улучшений" копеечный (если он вообще есть).

Недавно прочитал на habrahabr.ru

Цитата:

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

От себя могу добавить - если хотите быстрый доступ базе данных, забудьте про EF.

С одной стороны да, но с другой...
- Забудьте про C# и дотнет - только Си (а лучше ассемблер), плюс "ручная" оптимизация под конкретную аппаратно-програмную платформу.
- Забудьте про стандартные методы доступа типа ODBC/OLEDB/ADO.NET Provider - только писаные на том самом си/асме коннекторы к конкретному сетевому протоколу конкретной СУБД, ну на самый худой конец голое АПИ клиентского модуля поставщика СУБД, если оно имеется в наличии (типа оракловой oci.dll).
- Забудьте про стандартные СУБД - только свои собственные, писанные на си/асме программы наиболее эффективной обработки конкретных структур данных (да, распределённые/кластерные, с балансировкой нагрузки, своими особыми структурами хранения)...
- Забудьте про стандартные ОС - только свои, писанные с нуля и не занимающиеся не связанной с решаемой задачей "ерундой"...
- Забудьте про стандартное компьютерное "железо" - только специально спроектированные под конкретную задачу машины/сети...

Ну как-то так получится, если довести до логического конца Накидывая на каждый подобный "оптимизационный шаг" X*(2^N) человеко-часов от времени потребного на рисование исходного "медленного и простого" приложения

Igor Korolyov
- Забудьте про C# и дотнет - только Си (а лучше ассемблер), плюс "ручная" оптимизация под конкретную аппаратно-програмную платформу.

Зачем? Разве C#существенно медленней, чем C?

Igor Korolyov
- Забудьте про стандартные СУБД - только свои собственные, писанные на си/асме программы наиболее эффективной обработки конкретных структур данных (да, распределённые/кластерные, с балансировкой нагрузки, своими особыми структурами хранения)...

Мне кажется, это несколько несопоставимый совет с "вместо LinQ использовать for".

Igor Korolyov

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

Даже это спорно. То что идея интересная - это да, а что она здравая... Ну мы на сегодня имеем сотни тысяч недо-программистов "на пхп" (я в общем имею в виду тех веб-дизайнеров-программистов которые и в дизайне не очень, и как программисты крайне слабы - не в пхп дело, конечно). Зачем делать то же самое в десктопном сегменте - лично я не понимаю. Я вообще сильно против всяких вычурностей в графическом интерфейсе...

Не надо путать вычурности и просто удобные вещи, которые WinForms не предоставляет, или предоставляет в каком-нибудь крайне убогом виде, а сделать на WPF элементарно.
Ну а про горе-программистов на пхп - вообще не понял, что имеется ввиду здесь. Типа, не нужно делать хороших вещей, так как все равно ничего хорошего на них не сделают? Ну так на эту тему есть на Руси известная пословица - "Дай дураку стеклянный х.., так он и х.. разобьет, и руки порежет".

Igor Korolyov

SoccerStudio
Второй плюс - практически безграничные возможности по созданию практически любого внешнего вида.

Плюс ли это? Даже в примитивных квадратно-гнездовых дизайнерах UI типа фокса или "обычного" WinForms а ранее Delphi "непризнанные гении" умудрялись сооружать вырвиглазное г*но, а теперь именно ЭТО стало делать "проще и приятнее". Ну точнее был поставлен такой приоритет...

Насчет приоритета - не совсем так. Даже совсем не так. Идея-то была в том, чтобы дизайном занимались профессиональные дизайнеры. А не "непризнанные гении". Ну, а то, что и дизайнеры могут сделать "г*но" - это и так понятно. Правда, как мне как-то объяснили, задача дизайнера может быть не сделать дружеский интерфейс, а как раз наоборот - сделать "вырвиглазное г*но", но такое, чтобы продукт продавался, т.е. как бы маркетинговая задача такая.
Иными словами, возможность сделать легче сделать "г*но" сама по себе мало чего значит, а вот востребованность "г*на" уже может что-то определять.

Да и приложения тоже бывают разные. Например, есть такая область, как всякие презентационные приложения - ну, которые обычно демонстрируются на больших экранах и которые любят разглядывать всякие высокопоставленные дяди. Там без WPF было бы довольно тоскливо. Имелся у меня такой опыт, в конце нулевых работал в одной фирме, и делали мы некий софт для так называемых touch-table. Это примерно как планшет, только размерами покрупнее на несколько порядков. Одна разработка была для МинОбороны, другая - для Московского департамента земельных ресурсов. В обоих случаях - некая интерактивная карта. Так вот во-первых, делать требуемый софт на WPF было гораздо удобнее, на WinForms - очень проблематично. А во-вторых там я с удивлением обнаружил, что обычные серые кнопочки, что называются, "не канают", а какие-нибудь круглые кнопочки, анимационно меняющие цвет при наведении пальца приводят "шишек" чуть ли не в оргазм.
А уж отображение летающей над картой Москвы в реальном времени модели вертолета (в скобках - с крутящимся пропеллером) - это вообще казалось тогда чем-то из параллельного мира.





Исправлено 1 раз(а). Последнее : SoccerStudio, 06.10.16 21:00

Естественно C# во многих задачах (да, не во всех, но таки во многих) сильно медленнее голого си. В плане отрисовки интерфейса очень даже, например...

S-type
Мне кажется, это несколько несопоставимый совет с "вместо LinQ использовать for".

Во-первых речь шла про EF а не LINQ. EF для "оптимизации" заменяется на голые DataReader и обращения к его методам получения значений полей.
Во-вторых абсолютно сопоставимо. Вместо одного LINQ запроса нарисовать десяток вложенных циклов с условиями - это как раз экспоненциальное увеличение сложности/объёма. Далее каждый шаг подобной "оптимизации" и будет увеличивать сложность такими же темпами - хотя реально способен "ускорить" работу тоже "в разы".