Алекс Jenter - Программирование на Visual C++. Архив рассылки

Вторая проблема состоит в том, что MFC сама следит за временем жизни тултипа, и мы не можем точно знать, когда он уничтожается и создаётся заново. Поэтому ширину тултипа необходимо заново задавать всякий раз, когда тултип "собирается" появиться на экране. Удобнее всего делать это в ответ на уведомление TTN_NEEDTEXT, например:

BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd)

ON_NOTIFY_EX_RANGE(TTN_NEEDTEXT, 0, 0xFFFFFFFF, OnToolTipText)

END_MESSAGE_MAP()

BOOL CMainFrame::OnToolTipText(...) {

CToolTipCtrl* ptt = AfxGetThreadState()->m_pToolTip;

ptt->SetMaxTipWidth(0xFFFFFF);

return CFrameWnd::OnToolTipText(…);

}

Здравствуйте!

Благодарю Вас за прекрасную и очень полезную рассылку! Полагаю, что мою благодарность разделяют очень многие ее читатели.

В номере 36 от 11.03.2001 г. рассылки "Программирование на VC++" Сергей Петухов задал вопрос о русификации элементов окна предварительного просмотра перед печатью. В номере 38 от 25.03.2001 г. на него дал обстоятельный ответ Александр Шаргин. Предложенный в ответе метод решения проблемы имеет огромное неоспоримое достоинство – он работоспособен! Однако, не лишен и некоторых очевидных недостатков, связанных с необходимостью ручного редактирования информации ресурсных файлов в каждом из проектов, ориентированных на русскоязычного пользователя. Такой метод пригоден скорее для случаев, когда нужно изменить именно вид стандартного интерфейса MFC в соответствии с требованиями конкретного приложения, а не его язык.

MSDN предлагает иной путь решения. Кратко он освещен в статье "Localization of MFC Components" (MSDN/Visual C++ Documentation/Reference/MFC Library and Templates/MFC Library/MFC Technical notes/TN057). Чуть подробнее последовательность необходимых действий описан в статье "HOWTO: #include the Localized MFC Resources in an EXE or DLL" (ID: Q198536) Knowledge Base.

Суть заключается в том, что все языкозависимые ресурсы MFC размещены в каталогах MFC\INCLUDE\L.* и при статическом присоединении ресурсов MFC к проекту, должны использоваться именно они. Для подключения нужного подкаталога достаточно указать его в командной строке компилятора ресурсов с ключом /I (пример из MSDN /IC:\PROGRAM FILES\DEVSTUDIO\VC\MFC\INCLUDE\L.DEU).

Все довольно просто. Создаем новый подкаталог MFC\INCLUDE\L.RUS, записываем в него по образу других языков семь файлов *.rc и русифицируем их в текстовом редакторе (в редакторе ресурсов VS это сделать не удастся, т.к. файлы защищены от изменения специальной директивой). Затем указываем на вкладке свойств проекта Resources (поле Additional resource include directories) наш новый русскоязычный каталог (например, C:\PROGRAM FILES\DEVSTUDIO\VC\MFC\INCLUDE\L.RUS). В статье из KB рекомендуется еще и удалить все директивы _AFXDLL препроцессора, которые видны на той же вкладке, но в моих приложениях, со статическим присоединением ресурсов MFC, таковые не попадались. Затем открываем меню "View" и выбираем пункт "Resource Includes" и в окне "Compile-time directives" изменяем код языка и номер кодовой страницы. Данные о кодах можно найти в файле "winnt.h". Там они представлены в шестнадцатеричном формате и их следует привести к основанию 10. Для русского языка нужные строки будут выглядеть так:

LANGUAGE 25, 1

#pragma code_page(1251)

После этого проект можно собирать.

В статье из KB сказано, что в том же меню "View" – "Resource Includes" можно указать измененные маршруты заголовочных файлов, например, #include "l.rus/afxprint.rc" вместо #include "afxprint.rc". Вероятно, если это сделать, отпадет необходимость в указании маршрута каталога с русифицированными ресурсами на вкладке "Resources" свойств проекта. Кроме того, в той же статье рекомендуется с помощью редактора ресурсов удалить из раздела "String Table" все неспецифичные для конкретного приложения строки, сгенерериванные AppWizard. Полагаю, это можно не делать. В крайнем случае, на необходимость такой операции укажет компилятор.

Таким образом, нужно один раз перевести на русский язык содержимое нескольких файлов ресурсов, а затем лишь указывать в проектах нужный язык и маршрут каталога с русифицированными файлами.

Большое спасибо, Андрей.

Это все на сегодня. Пока!

Приветствую вас, уважаемые подписчики!

Мой коллега Александр Шаргин решил присоединиться к дисскуссии по поводу свойств в C++:

Свойства "в стиле VB" невозможно заменить перегрузкой оператора присваивания и приведения типа. Если в классе содержится 10 свойств типа int, мы неизбежно заходим в тупик. Что касается полезности этой концепции, она признана многими разработчиками компонентно-ориентированных средств разработки (кроме VB есть Delphi и BCB, в которые свойства вводились отнюдь не только для поддержки COM, свойства есть в новом языке C# от Микрософт и т. д.). Конечно, свойства – не революция. Вместо них можно использовать пару методов Set/Get. Но они делают смысл происходящего в программе понятнее:

wnd.style |= WS_VISIBLE;

вместо

wnd.SetStyle(wnd.GetStyle() | WS_VISIBLE);

Кроме того, они развивают концепцию сокрытия деталей реализации от пользователя класса: для него свойство выглядит как обычная переменная-член, и он даже не догадывается, что для её реализации используются функции. Не секрет, что многие программисты не любят методы Set/Get и продолжают использовать открытые члены, несмотря на все призывы Страуструпа и иже с ним. Даже в книгах по программированию этот "неправильный" подход встречается сплошь и рядом. Свойства позволяют найти компромисс между этим чисто человеческим нежеланием и важными принципами ООП. В выигрыше оказываются все.

Что касается реализации свойств с C++, здесь перед нами встают проблемы. Если вопрос портирования прграммы для нас не актуален, и мы ограничиваемся VC, я не вижу смысла игнорировать его расширенные возможности. Использование deсlspec(property) в этом случае является исключительно делом вкуса программиста. Принципиальных возражений против его использования нет.

А вот "самодельные" свойства приносят в жертву эффективность программы, и поэтому мы должны или отказаться от них, или улучшить, убрав лишние затраты. Вот пример возможного улучшения.

#include

//***************************

// Макрос для свойства

#define PROPERTY(ownertype, proptype, prop, getfunc, setfunc) \

class class __property##prop \

{ \

public: \

operator proptype() \

{ \

return ((ownertype*)((char*)this - offsetof(ownertype, prop)))->getfunc(); \

} \

void operator=(proptype data) \

{ \

((ownertype*)((char*)this - offsetof(ownertype, prop)))->setfunc(data); \

} \

}; \

friend __property##prop; \

__property##prop prop

//***************************

// Пример использования

class CValue {

private:

char m_value;

public:

int get_Value() {

return m_value; // Или более сложная логика