HankHank
|
Posted: Mon Apr 19, 2010 10:02 Post subject: |
|
|
Привет, MVV.
Написанное тобой только слегка подрихтовал под Visual c 6.0: в функциях, содержащих L”…, перешёл с обнобайтовым строкам, и двухбайтовые char-типы соответственно заменил на char).
Небольшая описЬка в
Code: |
bool IsForbiddenLevelUp()
{
char buf[1024];
GetWindowText(stpath, buf, TSIZE(buf));
if (*(int*)buf!='\\\0\\' || buf[2]=='\\')
…
|
Заменена на
Code: |
bool IsForbiddenLevelUp()
{
char buf[1024];
GetWindowText(stpath, buf, TSIZE(buf));
if (!((buf[0]=='\\' && buf[1]=='\\') || buf[2]=='\\'))
…
|
и… всё заработало почти с пол-оборота. Отдаю должное профессиональной прозрачности написанного кода. И всё это – при вполне удовлетворительной скорости.
Поразмыслив о твоём предложении запрограммировать контроль, когда находимся “в среде моего плагина” – работает хук, вышли – хук сбросить, пришёл к выводу, который озвучивал ранее:
- возможны коллизии, когда в обеих панелях сетевая среда,
- моя “сетевая среда” была создана плагином, вышли из него, но вошли через командную строку, написав ту же магическую строчку cd \\< IP или имя>.
Поэтому решил оставить хук работающим после вызова плагина – хуже не будет.
Остались несколько мелких вопросов:
1. Поскольку имитируем ввод в командную строку “забивкой в клавиатуру” Коммандеру:
Code: |
void DoMyAction()
{
// focus to command line
SendMessage(hMainWnd, WM_USER + 51, 4003, 0);
// type of plugin
SetWindowText(GetFocus(), "cd \\\\\\net");
// ENTER-pressing
keybd_event(VK_RETURN, 0, KEYEVENTF_EXTENDEDKEY, 0);
}
| ,
то в командной строчке успевает мелькнуть пресловутый вызов “cd \\\net”.
Нет ли другого способа “невидимого” вызова пллагина, чтобы “погасить” cd \\\net ?
2. При нахождении “в среде плагина” попытка ввести “cd \\< IP или имя>” не приводит к успеху – надо слегка подриххтовать логику. Ты, впрочем, об этом вскользь уже говорил.
3. До сего момента руки не доходили разобраться с вызовом плагина, как DLL-библиотеки. Поэтому был слегка озадачен, когда увидел, что вызов
Code: |
BOOL APIENTRY DllMain(HANDLE hModule,DWORD ul_reason_for_call,LPVOID lpReserved)
|
происходит несколько раз (!) с параметрами ul_reason_for_call 1 и 2 – запуск самого процесса и первого его TREAD'а. Меня, собственно интересовал момент с условием
Code: |
ul_reason_for_call==DLL_PROCESS_DETACH
| , которого я так и не увидел.
Интересно, при каких условиях Гислер выдаёт такой параметр ? Или этот момент целиком на откупе у операционной системы ?
4. И последнее. Поскольку уже много лет, как профессионально не занимаюсь программированием, инструментарий у меня – дедовский – 6-я версия Visual’а.
Пробовал как-то из любопытства установить MS Visual 2005-ый из журнального диска – “Trial Express”, так был сильно разочарован. Внешне “верстак” выглядит красивее, чем в 6-ке, но в сущности – мЕньшая функциональность, ужасные объёмы базы MSDN. При том, что этот монстр ставится на комп довольно долго. И сносится также весьма небыстро. С месяц-два назад в Сети проходила инфо о выпуске Visual 2010- го.
Что говорят профи ? И, кстати, на чём работает Гислер ?
------------------------
Обновив страничку, увидел, что подключились ещё спецы с комментариями. За что участникам обсуждения – гран мерси.
Немного позже попробую внести соответствующие изменения.
С уважением. |
|