30 окт. 2012 г.

Долгожданные "Undo" и "Redo" в дизайнере форм Delphi. Уже скоро!

Уже совсем скоро для дизайнера форм Delphi появится такой замечательный инструмент, как история изменений.


Данный инструмент будет реализован в эксперте для IDE (если кому интересно, реализация отталкивается от IDesignNotification и сериализации).

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

На текущий момент реализовано: отслеживание создания/удаления/изменения компонентов, ведение истории состояний компонентов и операции Undo/Redo по истории состояний компонентов.

Из не реализованного: некоторые возможности, нюансы и ситуации.

В общем ожидайте :-)

P.S. бесплатно и с открытым исходным кодом.

7 комментариев:

  1. А в С++ Builder будет работать? Спасибо.

    ОтветитьУдалить
  2. Классная штука и почему в embercadero этим не озаботились...

    ОтветитьУдалить
  3. >>>А в С++ Builder будет работать? Спасибо.
    Не проверял, но теоретически должно работать (вроде как главное требование от VCL-класса в С++ Builder - он должен являться совместимым с объектной моделью Delphi).

    >>>Классная штука и почему в embercadero этим не озаботились...
    Могу сказать, что не всё так просто и есть определённые сложности, к примеру одна из них - каскадные изменения состояний компонентов, т.е. изменение состояния одного компонента влечет за собой изменение состояния другого компонента, ну и сложность заключается в том, чтобы все такие каскадные изменения определить, из одного общего "потока", и заключить в одну "транзакцию", плюс ещё имеют место ситуации, когда IDE может сама (или возможно посредством установленного стороннего эксперта) проводить такие каскадные изменения, на которые нужно по особому реагировать (пример: когда удаляем один компонент с формы, то у всех остальных компонентов автоматически пересчитывается TabOrder, а следовательно изменяются их состояния, но эти изменения не нужно учитывать). Существуют также и другие нюансы...

    ОтветитьУдалить
  4. Весьма полезная штука.
    Буду ждать!

    ОтветитьУдалить
  5. Классная идея! Жду с нетерпением.

    >Могу сказать, что не всё так просто и есть определённые сложности, к примеру одна из них - каскадные изменения состояний компонентов

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

    ОтветитьУдалить
  6. А что с конфликтами имен? Допустим была кнопка Button1 и Button13, переименовал Button13 в Button14. При отмене будет конфликт из-за двух кнопок Button1, так как по одному символу отмена идет.

    ОтветитьУдалить
    Ответы
    1. >>>При отмене будет конфликт из-за двух кнопок Button1, так как по одному символу отмена идет.

      Всё в порядке. Отмена по символам будет только у свойства Caption, т.к. у его редактора (TCaptionProperty) стоит атрибут paAutoUpdate и изменения применяются сразу в процессе редактирования (и заголовок компонента динамично обновляется), а вот у редактора свойства Name (TComponentNameProperty, а точнее его предка TStringProperty) нет этого атрибута и изменения будут применяться после выхода из редактирования.

      Удалить