0

У меня часто встречаются такие ситуации, когда мне нужно что-то проверить. К примеру:

var NextDay = DateTime.Now.AddDays(1);
if (DateTime.Now.Day == NextDay.Day)
{
    NextDay = NextDay.AddDays(1);
    //.....
}

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

1 Answers1

0

UPD По факту без цикла на сколько мне известно здесь не обойтись, где-то он всё-равно будет, но могу предложить вынести цикл в другой поток

Если задача выполняется очень редко, то после Invoke() можно добавить ещё System.Threading.Thread.Sleep(); Должно увеличить оптимизацию отключая поток

        public delegate void timeEventVoidDelegate();
        public static event timeEventVoidDelegate myTimeEvent;

        private void Form2_Load(object sender, EventArgs e)
        {
            myTimeEvent += Form2_myTimeEvent;
            Task.Run(() => { while (true) { if ((DateTime.Now.Second == 30) || (DateTime.Now.Second == 0)) myTimeEvent.Invoke(); } });

        }

        private void Form2_myTimeEvent()
        {
            MessageBox.Show("BOM BOM MUTHERF*CKER!");
        }
    }
Tony Sider
  • 76
  • 6
  • Да, если ты не знаком с конструкциями типа () => { } - это лямбда выражения, позволяют создать функцию прямо на месте в () - скобках параметры в фигурных { твой код } – Tony Sider Apr 08 '20 at 12:20
  • А как этот код относится к поставленному вопросу? 1. Человек спросил "Без цикла" - вы же используете while. 2. События уже давно можно создавать простым public event Action SomeEvent;. 3. Если вы используете Task.Run, то это уже вы идете в сторону async/await, где у вас это? И зачем тут Thread.Sleep() - за такое в "таксе" вообще по рукам бить надо... – EvgeniyZ Apr 08 '20 at 12:39
  • Цикл здесь не в основном потоке, сложно точно задать вопрос, когда не знаешь что ищешь. 2. Насколько я помню это исключительно на вкус и цвет, это разве как-то влияет на алгоритм и суть моего кода? 3. А вот здесь можно по подробнее с чем это связанно? таски же в принципе те же потоки, нет? Можно ссылку и пояснения для самообразования?
  • – Tony Sider Apr 08 '20 at 12:54
  • Это конечно будет работать, но это не то, что мне нужно. Я бы хотел что то по типу мьютекса, который создаст поток, который будет стоять(ждать своей очереди) до тех пор, пока не наступит условие. То есть переложить нагрузку на проверку условия на ОС. Я наверное что-то из разряда фантастики прошу, но так бы мне хотелось, ибо так не будет тратится процессорное время. – Влад Бочкарёв Apr 08 '20 at 13:02
  • @TonySider Почитайте про async/await, посмотрите как они используются, что они делают. Нет, это не потоки, это совершенно другая механика. Почитайте например это, там даже лекция целая есть (советую посмотреть). – EvgeniyZ Apr 08 '20 at 13:03
  • @EvgeniyZ Спасибо, обязательно почитаю, я был свято уверен, что если мы просто запускаем задачу не ожидая её завершения и возвращения данных, то разницы мало. – Tony Sider Apr 08 '20 at 13:10
  • @Влад_Бочкарёв А разве операционная система не на процессоре исполняется?) В любом случае где-то будет цикл проверяющий условия и отправляющий сообщения, вся система событий так устроена, её опрашивают каждый цикл, проверяют условия, вызывают события – Tony Sider Apr 08 '20 at 13:10
  • @EvgeniyZ UPD так, а теперь сами сходите и почитайте то, куда вы меня отправили: при использование Task.Run без модификаторов async/await происходит однозначный тупой запуск нового потока, а вот если мы указываем, что данная операция является асинхронной через модификатор await, код компилируется с использованием механизма асинхронного ожидания и вообще может исполнятся многозадачно в одном потоке – Tony Sider Apr 08 '20 at 13:23
  • @TonySider Я вам не говорю про потоки, я вам говорю, что вы используете Task, которая без async/await бессмысленна и написание Thread.Sleep() внутри Task - это бред, почему бред - я вам дал ссылку. Хотите именно поток, тогда используйте Thread, а не Task. – EvgeniyZ Apr 08 '20 at 13:31
  • @EvgeniyZ В таком ключе я с вами наверно согласен если воспринимать таск как атрибут асинхронных операций, хотя в самом MSDM мелкомягкие сами предлагают такое использование тасков тык Там есть только один пример использования его в асинхронном методе... Но наверное да, thread был бы более понятен по смыслу в моём коде – Tony Sider Apr 08 '20 at 13:42