Уже совсем скоро для дизайнера форм Delphi появится такой замечательный инструмент, как история изменений.
Данный инструмент будет реализован в эксперте для IDE (если кому интересно, реализация отталкивается от IDesignNotification и сериализации).
Первоначально я рассчитывал закончить работу в течении недели, но дьявол, как известно, кроется в деталях и процесс растянулся уже на два месяца... ну а чтобы он не растягивался на год - для собственной стимуляции публикую пока данный пост.
На текущий момент реализовано: отслеживание создания/удаления/изменения компонентов, ведение истории состояний компонентов и операции Undo/Redo по истории состояний компонентов.
Из не реализованного: некоторые возможности, нюансы и ситуации.
В общем ожидайте :-)
P.S. бесплатно и с открытым исходным кодом.
А в С++ Builder будет работать? Спасибо.
ОтветитьУдалитьКлассная штука и почему в embercadero этим не озаботились...
ОтветитьУдалить>>>А в С++ Builder будет работать? Спасибо.
ОтветитьУдалитьНе проверял, но теоретически должно работать (вроде как главное требование от VCL-класса в С++ Builder - он должен являться совместимым с объектной моделью Delphi).
>>>Классная штука и почему в embercadero этим не озаботились...
Могу сказать, что не всё так просто и есть определённые сложности, к примеру одна из них - каскадные изменения состояний компонентов, т.е. изменение состояния одного компонента влечет за собой изменение состояния другого компонента, ну и сложность заключается в том, чтобы все такие каскадные изменения определить, из одного общего "потока", и заключить в одну "транзакцию", плюс ещё имеют место ситуации, когда IDE может сама (или возможно посредством установленного стороннего эксперта) проводить такие каскадные изменения, на которые нужно по особому реагировать (пример: когда удаляем один компонент с формы, то у всех остальных компонентов автоматически пересчитывается TabOrder, а следовательно изменяются их состояния, но эти изменения не нужно учитывать). Существуют также и другие нюансы...
Весьма полезная штука.
ОтветитьУдалитьБуду ждать!
Классная идея! Жду с нетерпением.
ОтветитьУдалить>Могу сказать, что не всё так просто и есть определённые сложности, к примеру одна из них - каскадные изменения состояний компонентов
Имхо, даже простейшей Undo, позволяющий вернуть назад измененное свойство - это уже очень и очень здорово и вполне этого хватит на первое время.
А что с конфликтами имен? Допустим была кнопка Button1 и Button13, переименовал Button13 в Button14. При отмене будет конфликт из-за двух кнопок Button1, так как по одному символу отмена идет.
ОтветитьУдалить>>>При отмене будет конфликт из-за двух кнопок Button1, так как по одному символу отмена идет.
УдалитьВсё в порядке. Отмена по символам будет только у свойства Caption, т.к. у его редактора (TCaptionProperty) стоит атрибут paAutoUpdate и изменения применяются сразу в процессе редактирования (и заголовок компонента динамично обновляется), а вот у редактора свойства Name (TComponentNameProperty, а точнее его предка TStringProperty) нет этого атрибута и изменения будут применяться после выхода из редактирования.