Ревизия или скорость инвентаризации

Ревизия может быть не только кода, но и любого товара и здесь тоже очень важен фактор скорости. Хочу сказать про сканер штрихкода opn 2001, что он один из самых скоростных сканеров, легок, в обращении, прост (всего две кнопки), надежен. Все эти качества да плюс софт (естественно на nexus) дают в сумме очень хороший результат по скорости проведения инвентаризации в магазине.

Как оказалось в итоге, могу написать любой софт для этого сканера на С# vsnet 2005. А вот можно ли вызвать dll, написанную на шарпе из старого C++?

Комментарии

Изображение пользователя Serguei_Tarassov.

Можно

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

Изображение пользователя ipanshin.

Сережа, если

Сережа, если делал такое, то можешь дать пример?
Какие изменения в нексус клиенте я сделал. Если написать dll На с++ я ее могу подгрузить при работе клиента нексуса и вызывать некие модули из этой длл-ки. Теперь для OPN 2001 есть библиотечка на С# и переписывать ее мне не очень хочется. Хочется сделать только один вызов GetBarcodes но из клиента нексуса. Этого было бы мне достаточно, чтобы загрузить в базу штрихкод со сканера, подключенного к порту.

Хотя я могу и просто написать exe на С# и потом дергать его из базы как только я подключаю сканер к порту.

Не хочу ничего делать:)

Изображение пользователя Serguei_Tarassov.

Вот

Вот небольшая статейка
http://www.csharphelp.com/archives/archi...

Мысль оформить пошарпанный модуль в виде хранимой процедуры на сервере также не лишена смысла. ИМХО, здесь усилия минимальны.

Изображение пользователя ipanshin.

Начало софтостроения

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

Второй вариант касается нексус клиента. Я тоже "ревизовал" код и обнаружил залежи невоспользуемого функционала. Скажем, если построить динамическую библиотеку с модулями

extern "C" int PASCAL EXPORT Exported_Class_1( int UDN )
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());

CString str;
str.Format("We are inside Dll class 1 UDN=%i",UDN);
MessageBox(::GetForegroundWindow(), str, "Dll message", MB_OK|MB_ICONINFORMATION);

// normal function body here

UDN=1;
return UDN;
}

то клиент может их вызывать как

// definition
// hInstF=LoadLibrary( ".\\dll\\dll_core.dll" );
// LPFNDLLFUNCB DllFuncB; // Function pointer in the calling module
// DllFuncB = (LPFNDLLFUNCB)GetProcAddress(hInstF, "Exported_Class_1");

// call the function
//dllUDN=333;
//bRet = DllFuncB( dllUDN );

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

И третий путь - это я просто пишу exe модуль, работающий и в командной строке и через графический интерфейс, который читает порт и заполняет таблицу в базе данных. А запускаю я его из нексуса по требованию, скажем как пункт главного меню. Этот модуль я уже могу сделать многоплатформенным так как имею поддержку ado.net for mssql, mysql and postgress.

Покритикуйте, может еще какой путь есть?