Сборка для Windows NT 4.0 с помощью Visual Studio 2005?

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

Поэтому, когда вы выбираете элемент из одного из списков со списком, текущий Position базы управления общим связыванием изменяется, и все поля со списком попадают в эту позицию их общих данных source.

Чтобы решить проблему, вы можете привязать ее к другому источнику данных:

  • Вы можете привязать их к yourList.ToList() или к любому другому списку, например, к другим BindingList ,
    combo1.DataSource = yourList.ToList();
    combo2.DataSource = yourList.ToList();
    
  • Вы можете использовать для них разные BindingSource и установить свой список как DataSource BindingSource
    combo1.DataSource = new BindingSource { DataSource= yourList};
    combo2.DataSource = new BindingSource { DataSource= yourList};
    

Также как еще один вариант:

  • Для ваших комбинированных полей вы можете использовать разные BindingContext . Таким образом, даже когда вы привязываете их к одному списку, они больше не синхронизируются.
    combo1.BindingContext = new BindingContext();
    combo1.DataSource = yourList;
    combo2.BindingContext = new BindingContext();
    combo2.DataSource = yourList;
    

На самом деле все элементы управления формы используют общий BindingContext. Когда вы привязываете 2 элемента управления к одному и тому же источнику данных, тогда они также используют тот же BindingManagerBase таким образом, когда вы, например, переходите к следующей записи, все элементы управления переходят к следующей записи значения отображения из связанного свойства следующей записи. Это то же поведение, что и в ваших списках. Выполнение синхронизации для элементов управления, использующих один и тот же BindingManagerBase, является желательным поведением. Так или иначе, нам не нужно такое поведение. Сообщение разделяет причину и решение.

18
задан user7116 1 May 2012 в 17:33
поделиться

5 ответов

Для избавлений от _AFXDLL ошибки Вы попытались измениться на настройки для использования MFC в качестве статического lib вместо DLL? Это подобно тому, что Вы уже делаете в изменении времени выполнения, освобождает к помехам вместо DLL.

4
ответ дан 30 November 2019 в 09:15
поделиться

Нет, существует много приложений, созданных с VS2005, которые должны поддерживать Windows XP, 2000, NT, целый стек. Проблема - то, что (по умолчанию) VS2005 хочет использовать библиотеки/экспорт не подарок на NT.

См. этот поток для некоторого фона.

Затем начинают ограничивать Ваши зависимости через макросы препроцессора и избегать API, которые не поддерживаются на NT.

9
ответ дан 30 November 2019 в 09:15
поделиться

Обходное решение должно зафиксировать многопоточный DLL. Простые инструкции . Краткое изложение:

поставка 8.0 Библиотек времени выполнения C DLL (MSVCR80.DLL) не поддерживает NT 4.0 SP6 по одной причине и одной причине только: кто-то в Microsoft добавил вызов функции к GetLongPathNameW, который не существует в kernel32.dll на NT 4.0.

CRTLIB.C На строке 577, существует вызов к GetLongPathNameW. просто замените его: ret = 0; только использование эта сборка MSVCR80.DLL на NT 4.0.

, После того как Вы имеете, те, которые работают, предлагая более универсальное решение, должны быть тривиальными.

3
ответ дан 30 November 2019 в 09:15
поделиться

Идея состоит в том, что exe необходим для соединения со статической библиотекой.

попробуйте эту "Конфигурацию Свойства", "Общий", "Использование MFC" для "Использования MFC в Статической Библиотеке" "Свойства Конфигурации", "Общий", "Использование ATL" к "Статической Ссылке на ATL"

"Свойства Конфигурации", "C\C ++", "Генерация кода", "Библиотека времени выполнения" к "Многопоточному (\MT)"

Тестовая Машина Сборки Платформы: Visual Studio 2005 на Window XP Клиентская Машина SP2: SP2 Window XP (№ VS2005 установил)

-1
ответ дан 30 November 2019 в 09:15
поделиться

Хотя я не знаком с afxext.h, я задаюсь вопросом что относительно него, делает это несовместимым с Windows NT4....

However, для ответа на исходный вопрос: "Мое исследование до настоящего времени указывает, что невозможно создать приложение для выполнения на Windows NT 4.0 с помощью Visual Studio (C++, в этом случае) 2005".

ответ должен быть да особенно, если бы приложение было первоначально записано или работающий на NT4! С afxext.h вещью в стороне, это должно быть легким ДА.

другая вещь я нахожу, что проблема с является свободной природой, в которой люди выводят термин NT. Предоставленный большинство людей думают о 'NT' как о Windows NT4, но это все еще неоднозначно, потому что 'большинство людей' не равно 'всем людям'.

В действительности условие 'NT' равно серии NT. Серия NT является NT3, NT4, NT5 (2000, XP, 2003) и NT6 (Vista).

Win32 является подсистемой, которая Вы нацелены на свой код C/C++ также. Таким образом, я не вижу оснований, почему не нужно мочь цель эта платформа NT4 & подсистема или, если это - осуществление портирования платформы, удаляет зависимости MFC, что VC возможно внушителен.

Добавление afxext.h к соединению, это звучит мне как проблема совместимости подсистемы. Это - часть MFC от моего исследования Google. afxext.h, кажется, MFC (Microsoft Foundation Class) расширения.

можно ли удалить зависимость от MFC? Какое приложение - это? (CLR, сервис, графический интерфейс?) Можно ли преобразовать проект в неуправляемый проект C++ в VC 8.0?

, Надо надеяться, часть этого будет способствовать Вам.

1
ответ дан 30 November 2019 в 09:15
поделиться
Другие вопросы по тегам:

Похожие вопросы: