Используя MFC в службе Windows?
В PHP я делаю это этот путь:
<?php
function timesince($original) {
// array of time period chunks
$chunks = array(
array(60 * 60 * 24 * 365 , 'year'),
array(60 * 60 * 24 * 30 , 'month'),
array(60 * 60 * 24 * 7, 'week'),
array(60 * 60 * 24 , 'day'),
array(60 * 60 , 'hour'),
array(60 , 'minute'),
);
$today = time(); /* Current unix time */
$since = $today - $original;
if($since > 604800) {
$print = date("M jS", $original);
if($since > 31536000) {
$print .= ", " . date("Y", $original);
}
return $print;
}
// $j saves performing the count function each time around the loop
for ($i = 0, $j = count($chunks); $i < $j; $i++) {
$seconds = $chunks[$i][0];
$name = $chunks[$i][1];
// finding the biggest chunk (if the chunk fits, break)
if (($count = floor($since / $seconds)) != 0) {
break;
}
}
$print = ($count == 1) ? '1 '.$name : "$count {$name}s";
return $print . " ago";
} ?>
3 ответа
Я не уверен, что они означают в статье MSDN. Пока вы не используете какие-либо функции графического интерфейса, все будет в порядке, но это общая проблема дизайна при разработке служб.
При этом ATL имеет функции, специально разработанные для создания служб IIRC, так что вы можете быть лучше не использовать это.
Чтобы ответить на ваши вопросы (насколько мне известно):
1) те, которые вы указали, не являются проблемой.
2) Я полагаю, они имеют в виду проблемы синхронизации с компонентами пользовательского интерфейса. Пока вы не используете классы, производные от CWnd, все будет в порядке.
3) Не понимаю вопроса.
4) См. Ранее, плюс ATL более легкий, поэтому вам придется меньше распространять и предоставляет встроенную функциональность, которая облегчит разработку сервиса. См. Например CAtlServiceModuleT. Вы по-прежнему сможете в основном использовать свои собственные классы, поскольку в настоящее время CString используется совместно MFC и ATL, а в ATL есть классы для программирования сокетов и самого сопоставления файлов памяти. У него нет эквивалента для CArchive, и я не уверен, какие функции вы используете в CObject, поэтому я не могу сказать, есть ли эквивалент в ATL. В заключение я бы сказал «да» на этот вопрос.
(Я знаю, что этот ответ немного запоздал, и на этот вопрос уже был дан ответ, но MFC в сервисах - больное место для меня ...)
CSockets, насколько я помню, требуется Окно . Он делает невидимым на заднем плане. Я обнаружил это на собственном горьком опыте, когда попытался включить какой-то ранее существовавший код MFC в службу Windows. Может быть, это было необходимо только в том случае, если вы приняли подключение к сокету - я не могу вспомнить? Но это не сработало! (Как именно я потратил столько времени на это без осознания этого ограничения - длинная история)
CObject? Если вам нужен материал для идентификатора класса среды выполнения, используйте RTTI (dynamic_cast и т. Д.)
CString, мне нравится CString, я знаю, что сейчас он используется совместно с ATL, не уверен, что вы его используете без MFC или ATL. .. Вы можете использовать std :: string. Кроме того, я помню, что кто-то создал производный std :: (РЕДАКТИРОВАТЬ: нашел код - чувак !! это взрыв из прошлого ...)
CArchive, CMemFile: они вам действительно нужны?
В любом случае, как сказал Роэл, ATL может быть более полезным. Я бы не стал использовать MFC в серверном приложении (когда-либо!) ATL? Может быть. Если мне понадобится COM, вызывающе. Нет COM, но для CAtlServiceModuleT и т. Д ... возможно ....
И еще одна плохая вещь о MFC в сервисах, с которой я только что столкнулся, пытаясь превратить обычное приложение MFC-ATL в сервис: Использование AfxConnectionAdvise() фактически бесполезно без процедуры Window. Потоки в моей службе - это обычные потоки, не перекачивающие сообщения. Я считаю, что именно поэтому я никогда не получаю события от другого COM-сервера, который я разработал. Этот другой COM-сервер зависает на Fire_xxxEvent(), вызывая большой беспорядок во всей системе.