Нет - Вы не можете непосредственно протестировать статическую функцию, не изменяя источник, по крайней мере, немного (который является определением помех в C - что это нельзя назвать от функции в другом файле).
Вы могли создать отдельную функцию в тестовом файле, который просто вызывает статическую функцию?
, Например:
//Your fn to test
static int foo(int bar)
{
int retVal;
//do something
return retVal;
}
//Wrapper fn
int test_foo(int bar)
{
return foo(bar);
}
Мы обычно не тестируем наши статические функции непосредственно, а скорее удостоверяемся, что логика, которую они выполняют, соответственно тестируется различными тестами функции вызова.
Чтобы разрешить CEdit
для отображения символов Unicode вы должны создать его с помощью функции CreateWindowW
. Я только что протестировал его в программе ANSI MFC.
// allows Unicode characters
CreateWindowW( L"EDIT", L"", WS_CHILD|WS_VISIBLE, 10, 10, 50, 20, GetSafeHwnd(), 0, 0, 0 );
// shows Unicode characters as ?
CreateWindow( "EDIT", "", WS_CHILD|WS_VISIBLE, 10, 10, 50, 20, GetSafeHwnd(), 0, 0, 0 );
Вы можете создать все поля редактирования вручную в функции диалогового окна OnInitDialog
. А позже подклассифицируйте их к пользовательскому классу CMyEdit с поддержкой Unicode.
Можете ли вы заменить эти поля редактирования на многофункциональные элементы управления? Тогда вы сможете вводить международные символы даже в сборке без Unicode; внутри они будут закодированы в формате rtf, но затем при потоковой передаче текста из элемента управления вы можете использовать формат SF_UNICODE для получения представления Unicode.
Это слайд-шоу PowerPoint может вас заинтересовать - оно немного устарело (2000 г.), но в нем говорится о преобразовании программы в смешанный ANSI / Unicode.
Просто подумайте - вы можете попробовать включить UNICODE для своей сборки и использовать вызовы ANSI там, где вам нужно (например, CStringA).
( Я понимаю, что это не может вариант для вас, но подумал, что стоит отметить, что вы можете решить эту проблему наоборот )