It might be helpful to use the Inspect or Sample button in AM next time this happens to capture a stack trace of where the program is spending its time, then send it to Omni via Help->Send Feedback in OmniPlan (which will offer to include a desensitized version of your project, also helpful for analysis).
Experimenting with this a bit, I can reproduce it without difficulty. The Omni folks have mentioned in the past that adding dates far from the present (such as you've done here) can cause poor performance, and judging from the stack trace, that would seem to be what is going on. The good news is as soon as you get rid of the erroneous year, the program should start behaving again. To avoid accidents like this in the future, I suggest double-clicking on the hour, then shift-clicking at the end of the minutes as a safe practice unlikely to inadvertently select the space between date and time.
Experimenting with this a bit, I can reproduce it without difficulty. The Omni folks have mentioned in the past that adding dates far from the present (such as you've done here) can cause poor performance, and judging from the stack trace, that would seem to be what is going on. The good news is as soon as you get rid of the erroneous year, the program should start behaving again. To avoid accidents like this in the future, I suggest double-clicking on the hour, then shift-clicking at the end of the minutes as a safe practice unlikely to inadvertently select the space between date and time.
Linear Mode
