Я обычно стараюсь не подвергать автоматически сгенерированные файлы SCM. Автоматически сгенерированные файлы должны быть сгенерированы от исходных файлов, которыми управляет разработчик, и те могут быть подвергнуты SCM. Если конкретный инструмент хранит данные в непрозрачном и хрупком формате, это - проблема инструмента.
Относительно Visual Studio, хотя я думаю, что она имеет достойные компиляторы, библиотеки и среду отладки, я полагаю, что файлы в генерируют (PRJ, SLN, RC) очень проблематичны. Кроме проблем Вы упоминаете, они также изменяются много между различными версиями VS. Поэтому мы пишем наши собственные make-файлы и создаем программы внешне, использование делают. Кроме того, мы разделяем файлы ресурсов на части, для которых мы вынуждены полагаться на VS, и те мы можем нормально обработать с нормальным редактором. Мы генерируем много файлов ресурсов автоматически из высокоуровневого описания, записанного на пользовательских проблемно-ориентированных языках. Мы таким образом минимизируем влияние изменений, которые трудно обработать под SCM.
Посмотрите на метод SetRedraw. Вызовите SetRedraw (FALSE) перед началом заполнения элемента управления, SetRedraw (TRUE) по завершении.
Я бы также рекомендовал использовать RAII для этого:
class CFreezeRedraw
{
public:
CFreezeRedraw(CWnd & wnd) : m_Wnd(wnd) { m_Wnd.SetRedraw(FALSE); }
~CFreezeRedraw() { m_Wnd.SetRedraw(TRUE); }
private:
CWnd & m_Wnd;
};
Затем используйте как:
CFreezeRedraw freezeRedraw(myListCtrl);
//... populate control ...
Вы можете создать искусственный блок вокруг кода где вы заполняете элемент управления списком, если хотите, чтобы freezeRedraw
выходил из области видимости до завершения функции.
Если у вас много записей, может быть более подходящим использовать стиль виртуального списка ( LVS_OWNERDATA
). Дополнительную информацию можно найти здесь .