ты бы еще на форуме кройки и шитья поинтересовался как укладывать кафельную плитку.

Да, я знаю, что с атрибутами можно переиначить правила. Можно закрытые члены сделать доступными для сериализации, а открытые - запретить. Там много что атрибутами настраивается. Без атрибутов и по дефолту должно всё доступно-публичным быть.

Нет. В DataContract'е проперти без аттрибутов сериализоваться не будут.

Не знаю. Это очень непростой контрол, как я читал. С нуля написать генератор дат с какого-то по какой-то год,

Ну я же написал только TimePiker :D Без вычисления даты.

А если изначально сделать элементы списка эдитбоксами, но неактивными для редактирования? А когда два раза кликнул - делать актиным?

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

А как вы на Формах это на раз-два решите? Уже готовый контрол с поддержкой такой функциональности?

Ловишь даблклик, создаешь новый эдитбокс, дальше управление в эдитбоксе, при потере фокуса убиваешь эдитбокс.

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

В смысле геморрой с передачей данных?

TextBoxBase.ReadOnly Property (System.Windows.Forms) | Microsoft Docs

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

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

А как вы на Формах это на раз-два решите? Уже готовый контрол с поддержкой такой функциональности?

Ловишь даблклик, создаешь новый эдитбокс, дальше управление в эдитбоксе, при потере фокуса убиваешь эдитбокс.

Создаёшь новый эдит бокс поверх старого лейбла или чего там в списке? Т.е. надо отловить координаты и размеры лейбла, на это место "прилепить" временный текст бокс с этими же размерами, далее вытащить из него введённый текст, убить текст бокс, присвоить текст лейблу?

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

Мною вышеописанный способ в WPF - мейнстрим и вся инфраструктура для этого из коробки есть. В Формах - монстрячим костыли.

Что интересно, что точно так же костылить можно и в WPF. Т.е. можно писать на WPF абсолютно так же, как на Формах. Писать весь код в обработчиках событий, например. МС создала генальный фреймворк, с полной обратной совместимостью по программистским подходам и привычкам и добавлением фантастического функционала для новых подходов. Ни у кого подобного не было и нет. Поэтому в упор не понимаю людей, которые сидят на Формах и не переходят на WPF.

ты бы еще на форуме кройки и шитья поинтересовался как укладывать кафельную плитку.

Я там в контексте сдачи на фюрершайн спрашивал. В смысле, что может кто уже сталкивался и знает, есть ли возможность обойти? Скажем, можно ли просто свежий тест принести. А где тут лучше всего разбираются с этим?

В смысле геморрой с передачей данных?

1) надо сделать так, чтобы при эскейпе данные не обновлялись.

2) надо убедиться, что только открыто для редактирования не больше одной ячейки.

Возможно есть что-то еще.

Попробуй реализовать свою идею.

1) надо сделать так, чтобы при эскейпе данные не обновлялись.
2) надо убедиться, что только открыто для редактирования не больше одной ячейки.
Возможно есть что-то еще.


Попробуй реализовать свою идею.

1. Байндинг можно настроить через UpdateSourceTrigger на любое изменение текста или только на полное редактирование. При полном редактировании (ваш эскейп, или потеря фокуса у меня, или нажатие энтер) идёт обновление байндинга. При эскейпе, как я понял, сохраняется старое значение, поэтому обновление модели не требуется. Так и не обновляйте её. В сеттере вью модели проверяете, изменилось ли значение, или осталось прежним, и соответственно принимаете решение об обновлении модели.

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

2. Так и делайте привязку свойств вью модели к отдельным текст боксам - будет по одной ячейке (свойству) за раз редактироваться.

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

Тебе не 22-23. Тебе под 40-к.

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

В сбертехе был хакатон, фиксили баги в какой-то системе, побеждала та команда, которая больше всего багов зафиксит. С..ка, и нашлись же долбо..бы, аж несколько команд, которые в этом участвовали в субботу и воскресенье:)

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

Я раньше писал, что собесился в одну фирму. В объяве всё по стандарту - скрамы, солиды и прочие "стандарты качества". Спросил одного разработчика, чо-как там с юнит-тестами. Похоже, он по небольшой опытности сознался, что их почти не пишет. Обычно что не спросишь про эти "стандарты" - у нас всё есть, всё чин по чину. Ну не будут же тебе на собесе говорить, что у нас говнокод, текучка и прочие проблемы?

Или ещё так бывает. Вот эту таску надо выполнить за день. С юнит-тестами получится два дня. А дальше известная волына: у нас разработчики сами решают, писать юнит-тесты или не писать, под свою ответственность.

)))

А как делать такое красивое выравнивание, когда пачку одних и тех же методов с параметрами вызываешь? Только чтобы было всё же выравнено по правому символу, а не по левому. Да хоть и по левому - пофиг. Ну и чтобы автоматом, а не в ручную. Что-то в Студии, похоже, таких правил выравнивания нет. Самому как-то расширение писать?

А как делать такое красивое выравнивание, когда пачку одних и тех же методов с параметрами вызываешь?

Предпологаю наверное такое есть только в Sublime см. https://i.stack.imgur.com/mzS7d.gif см. так-же https://telegra.ph/sublime-01-30

Вобщем, такое выравнивание, как на картинке (но не как мне надо) получается банальной табуляцией. Только при следующем автоформатировании кода (по дефолтным правилам Студии, например) (Ctrl+K, D) всё слетает.

Вобщем, такое выравнивание, как на картинке (но не как мне надо) получается банальной табуляцией. Только при следующем автоформатировании кода (по дефолтным правилам Студии, например) (Ctrl+K, D) всё слетает.

Напишите сами программу которая выравнивает.

Проще забить ))

Думал, есть простая настройка, чтобы так сделать. Если нет - проще забить.

Я щас вообще свежую Студию не настраиваю почти - так, две-три вещи только. Как и винду и прочее. Надоело и лень. ))

В Формах - монстрячим костыли.

-------

Костыли мострячим везде где они нужны.

МоГем мастрячить в Формах - имеем работу по мастряченью костылей в Формах.

Не моГем мастрячить в Формах - ругаемся на форумах как все плохо и только ВПФ есть панацея от всего...

Обычно это поведение как-то самостоятельно изменяется годкам к 25-27... ну после 2-5 лет работы...

Если есть работа даже на старых Формах, да ещё на VB 6, значит должна быть и на WPF. Причём формы на работе, а не просто упомянутые в вакансии, я уже раза 3-4 встречал. WPF впрочем ещё больше, но туда меня пока не взяли. Опять же, все самые распиаренные и рекомендованные мне фирмы с WPF я "просрал" в самом начале, когда и резюме было отстойным, и плохо говорил, и не знал, о чём молчать на интервью. Сейчас, после полутора десятков видеоинтерьвю и полсотни звонков уже гораздо лучше себя веду. Поэтому буду продолжать искать WPF и в качестве исключения "готов делать ASP.NET MVC и даже выучить какой-нибудь Ангуляр или Vue для фронтэнд части".

МоГем мастрячить в Формах - имеем работу по мастряченью костылей в Формах.

Не моГем мастрячить в Формах - ругаемся на форумах как все плохо и только ВПФ есть панацея от всего...

Обычно это поведение как-то самостоятельно изменяется годкам к 25-27... ну после 2-5 лет работы...

Я тут логики не вижу. Есть фреймворк и язык, которые вы более-менее знаете, и есть всё остальное, которое считай не знаете. Вы говорите - иди туда, где всё остальное, не зацикливайся на том, что знаешь. Ты идёшь туда, тебе задают элементарные вещи, ты очевидно сливаешься. Нафига идти туда, где ты не знаешь, если там, где ты знаешь, шансов больше?

Этот вопрос мы уже обсуждали раз десять, наверное.

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

В Формах - монстрячим костыли.
-------
Костыли мострячим везде где они нужны.

В Формах вы их монстрячите постоянно. В WPF - иногда. Там, где в WPF "по науке", в Формах - костыли. Вроде, и там и там есть костыли, но дело всё в их количестве и качестве.

Не буду приводить пошлый анекдот про нюанс. Вот непошлый.

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


Но есть нюанс...

Вы говорите - иди туда

-----

Не-не - сиди на месте - туда пойдет тот кто моГет...

Нафига идти туда, где ты не знаешь, если там, где ты знаешь, шансов больше?

-----

Что ценнее - грамм или килограмм?

То, что ты не умеешь что-то делать - не проблема.

Проблема - ты не учишься делать что-то новое...

В данном случае у тебя, по заявляемым навыкам, доступно 10 позиций.

Взять отдельно Формы - будет доступно 100 позиций.

Имея Формы и ВПФ - 2-3.000...

Добавишь ЦСС+жабийскрипт - 50-100.000 вариантов.

Но - нет - надо упереться в минимум и валять дурня...

Фигня все это - жуем попкорн и ждем начала второй сотни отказов...