#

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

xaml лишь язык разметки..
все элементы доступны в коде...
почти как в winforms..
MSDN в помощь

в любом из вариантов базы, вам просто придется попробовать домашний хостинг, потом внешний (если оно того стоит...

ps есть очень много "встраиваемых" БД, начиная с sqlite, упомянутого выше, и продолжая nonsql лайтовыми базами в количестве.. для C# и объектные, и даже графовые.. как серверные, так и встраиваемые..
если не планируете одну БД на круг пользователей, естественно проще встраиваемую. если проект серьезнее, то его развертывание может быть достаточно творческой задачей..

и в чем трудности? программно заполнять/изменять/читать грид ни кто не запрещал

а может plinq посмотрите?
в любом случае это осмысленно только при большом количестве ядер.. и тяжелой обработке события..
а еще стоит подумать о конкурентных событиях и риске одновременных противоречивых решений..
если событий всего десятки (а не миллионы), а обработка событий не требует тяжелых вычислений, вообще не факт что стоит заморачиватся

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

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

Pixilys,

как хочешь, так и выпиливай.. хоть конечный автомат запили

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

ps но вообще то задания типа сделайте за меня тут не приветствуются

WPF TextBox валидация

ни как. по крайней мере ни как автоматически. в общем случае это полностью переписать.

- если есть логика не связанная интерфейсом (данные и обработки) - надо ее еще более четко изолировать

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

ps что бы прибавить оптимизма:
- о каких объемах кода идет речь? если десятки, даже сотни строк. это все не страшно. ну или страшно только на первый взгляд
- а вот если десятки тысяч строк кода*, имеющего бизнес ценность - нужен рефакторинг. и, в итоге, все тоже, в общем то не очень страшно/сложно
* - просто трудоемко ;))

по моему классический случай, когда не знаю как называется создает большую проблему
- на сколько я помню, задача все еще не перешла в ранг тривиальных, зато точно уже есть решения во множестве
- подход [к снаряду] первый c# визуализация графов
- подход к снаряду второй ща пороюсь в закромах и накидаю ссылок, то есть буду обновлять ответ, постараюсь не много раз (ну тут уж звиняйте гарантий точной пригодности быть не может)
.. или платные не нужны совсем? (тогда github - поиск по правильным словам, и стукните, что бы я не спамил платными решениями поздно ))).. пошли кандидаты:
- https://www.yworks.com/products/yfiles-net
- https://www.nwoods.com/products/godiagram/
- https://www.nevron.com/products-dot-net-vision.aspx
.. продолжение следует пожалуй я преувеличил свои закрома (на самом деле что то найдется почти у всех популярных платных вендоров либ. но я проверил на соотвествие запросу. как его понял)

ps надеюсь донес свою точку зрения, а уж если хоть какой то пункт будет полезен, то вообще супер. удачи! ))

1С монолитная платформа для решения бизнес задач, как следствие:
- там не до свистоперделок
- обычно там предпочтительнее что бы юзерэкпириенс не ломался
- в части нестандартных графиков/отчетов - webview, и js либы вэлкам. и все равно гораздо чаще делают вебсервисы, которые используют 1С как бэк (в тч наверное по тому что webview там все еще на ослике)

ну тогда уж сосвоей стороны докину..

На счет C# очень много противоречия, между старой Form и WPF, какую использовать

ни каких противоречий:
- "набросать на коленке" простенький UI это формы. но они не держат корректно масштабирование экрана. обещают что скоро будут, но пока нет
- полноценный интерфейс это WPF
- а еще есть AvaloniaUI (тоже на XAML, со своими плюшками, но есть и разница в поддержке проекта корпорацией (WPF) и сообществом (AvaloniaUI))
- есть UWP (вин 10 aka метро UI)
- есть Electron.NET (но лично я противник таскать за собой копию целого браузера)
- есть даже GTK# и обертки для QT

противоречий нет. есть достоинства и недостатки, а так же разный порог вхождения (а бывает еще еще полное неведение о положении дел)

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

ps
о кроссплатформенности C# - .Net Core + (AvaloniaUI или Electron.NET) или Xamarin (XAML)
о семействе Electron.* - современный Skype и VS Code написаны на Electron
о винде - кровавый энтерпрайз плотно сидит на WPF
о фрилансе - UWP самый короткий путь выставить в витрину магазина MS свое платное приложение для вин 10 (если конечно у вас есть стоящие идеи)
pps если хочется в Google Play выставляться, и знаете C# а Java смущает - тогда Xamarin (но многие считают что лучше Kotlin ;)))

https://duckduckgo.com/?q=c%23+wpf+splash&t=ffab&ia=web