По календарному плану

Докладываю.
Дата что на компьютере локальном, что на сервере стоит актуальная.
Обновления все установлены (правда мирюсь с глюком, который мы обсуждали, он все еще проявляется, может и здесь из-за него?).
Планируемая дата для этих производственных заказов прописана, здесь тоже все ок.
Насчет связей - понял.
Теперь насчет графика. Можно ведь рисовать расчетное время для начала. Вот представьте, у меня сложное изделие, которое состоит из 300 деталей. У каждого свое время изготовления, свои посты. У вас вся эта информация имеется. Почему бы не помочь планировщику разместить диаграму Ганта хотя бы с примерными сроками(расчетными)? Там уже он потом сможет детально вывести требуемые реальные сроки, но частенько требуется навскидку сказать раньше какого срока мы "хоть убейте" не произведем заказ.
Тем более вся информация у вас уже есть, просто просуммируйте все значения техпроцессов и нарисуйте соответствующий чарт. Причем, желательно, чтобы чарты рисовались поочередно, то есть, чтобы сборка верхнего уровня не была ниже узлов нижнего уровня. Потом этим всем уже можно поиграть, но каждый раз выставлять 300 деталей для нового заказа приходится одинаково... Как-то не очень. Может, стоит добавить параметр планируемое время изготовления детали и использовать его для калькуляции?
Доклад окончил

Это о чём речь?

Прочитайте, пожалуйста, внимательно предыдущее сообщение (#2).
Если интересно, приезжайте на день в гости, я вам порассказываю о календарном планировании производства. Чем сроки на самом деле определяются, что и в какой степени на них влияет и т.д.
Не бесплатно.

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

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

Разобрались с ошибкой про дату (с которой эта тема началась).
Так получается, если включить тип интерфейса из кучи "плавающих" окон.
Если включить классический для VOGBIT "закладочный" интерфейс, то всё работает нормально.
Поразбираемся...
Пока предлагаю просто использовать традиционный вариант интерфейса. Обычный.

Это как? Что это означает? Что такое "наследование окон"?

Что-то, мне кажется, не то у вас с компьютером.

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

А в стандартном (закладочном) интерфейсе все работают. Многие уже годами, ежедневно. И ни у кого не наблюдается ничего похожего на то, что вы описываете.

Может быть, проблема с framework'ом.
Может быть, это последствия того, что на этом компьютере когда-то были установлены приложения, которые используют те же компоненты devEx, но делают это некорректно.
Сложно сказать.

То, что в интерфейсе со всеми "плавающими" окнами есть проблемы - признаём. Есть.
Не заметили, потому что никто им (этим много-оконно-плавающим интерфейсом) не пользуется. Все пользуются стандартным "закладочным" вариантом.
Стабильные проблемы (как вы говорите 20+ ошибок при каждом запуске) со стандартным интерфейсом? Тут дело очень вряд ли в программе. У всех остальных то работает нормально. А это тысячи, если не больше, инсталляций на всевозможных операционных системах.

Framework'и мы сами не пишем (естественно). Если проблема во Framework'ах, то и лечить надо, мне кажется, перестановкой, как минимум, Framework'а, как максимум - Windows целиком.