SingleApplication (qt4.4)

[ритт]

так тоже пробовал - глухо

windows.h подключает winuser.h, где при условии #if (_WIN32_WINNT >= 0x0500 || _WIN32_WINDOWS >= 0x0490) объявляется BOOL AllowSetForegroundWindow(DWORD);

другими словами,
win32:LIBS   += -luser32
+

Код:

#ifdef Q_WS_WIN
// WindowsNT4   0x0400
// Windows2000  0x0500
// WindowsXP    0x0501
// Windows2003  0x0502
// WindowsVista 0x0600
#	define _WIN32_WINNT 0x0501
#	include <windows.h>
#endif

int main(int argc, char* argv[])
{
#ifdef Q_WS_WIN
	AllowSetForegroundWindow(ASFW_ANY);
#endif
//...

программа работает, окно на переднем плане
если не устанавливаю _WIN32_WINNT, гцц матерится на AllowSetForegroundWindow и ANY - значит, _WIN32_WINNT пустая...
как в таком случае устанавливать _WIN32_WINNT автоматом?

всё это, конечно, чепуха...мне по?ую будет ли у кустомера в примере окно фореграундом...
но не понимаю почему с резолвом символа такой облом

[Tonal]

Вот очень подробная статья: http://rsdn.ru/article/baseserv/avins.xml

[ритт]

ещё до 0.1-го релиза у меня была мысля создавать/проверять системный мутекс перед запуском серверной части...и даже было частично реализовано
в общем, добавлю в версии 0.5

[ритт]

подтверждаю делом
0.5б1: реализовал настоящее "один экземпляр на пользователя" посредством системного (КО) семафора + уникального для пользователя префикса к имени пайпы
если общение между экземплярами не требуется, достаточно семафора

поскольку под рукой нет лялихи с четвёртой кутёй, тестировалось (и работало) по хренью сп2
под лялихами знаю только, что должно собираться...теоритически работать тоже должно, но мог наплужить с таймаутами у семафора

слышал, что со сборкой статиклиба тоже что-то невменяемое
поэтому выкладываю бэту и надеюсь, что кто-нибудь погоняет под *нихами и отпишется

[ритт]

ауу! протестируйте кто-нибудь под лялихами и отпишитесь?
если всё гут, я остановлюсь пока на версии 0.5 и ничего в ближайшее время дописывать не буду

[Red Devil]

На Qt 4.3.1 будет работать ?
я могу потестить, но 4.4 у меня под линуксом собрать невозможно из-за компилятора древнего.

[ритт]

SA зависит от QLocal(Client|Server), которые были добавлены в 4.4
сейчас обкромсаю код и попробую собрать у знакомого под 4.3.4 (фактически меня только семафор интересует, т.к. работа с сокетами не менялась)

но всё-равно хотелось бы услышать о боевом испытании...

[ритт]

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

версия 0.5 доступна для загрузки: http://www.qt-apps.org/content/show.php/SingleApplication?content=81163
надеюсь, кому-нибудь оно будет полезно!

[Red Devil]

Проверил на Slackware 12.1 (Qt 4.4.0).
Все работает и компилируется без единого варнинга и ошибки.

Позже еще себе буду Suse ставить, на ней проверю.

[ритт]

версия 1.0 доступна для загрузки: http://www.qt-apps.org/content/show.php/SingleApplication?content=81163

системный семафор заменён на шаред мемори (теперь должно работать под маковками)
увеличена стабильность и немного - производительность
версия 1.0 не совместима с предыдущими версиями - для нормальной работы необходимо пересобрать проекты, используйющие SA

[Hort]

плохо что мне нужно именно под qt4.3

[ритт]

плохо, конечно, но ты всегда можешь взять реализацию QSharedMemory и QLocal(Server|Socket) из самой кутэ и добавить непосредственно к SA

[ритт]

версия 1.1:
   

• страшная модель "по потоку на сокет" заменена на "все сокеты в одном потоке" (всё-равно локалсервер по умолчанию принимает до 30 соединений - это не так много для одного потока, а больше вряд ли кому-то потребуется);
• статические методы отправились в небытие (так и не смог придумать ни одного примера, где это могло бы пригодиться);
• добавлен пример "console".

предполагается, что 1.1 - это последняя версия, использующая локалсокеты и зависящая от 4.4. в свободное время займусь новой реализацией.
заодно хотелось бы поинтересоваться у /* потенциальных */ пользователей:

• нужен ли режим обнаружения другого экземпляра без возможности передачи данных между экземплярами? если да, то на каком этапе этот режим следует определять (compile-time/run-time)?
• имеет ли смысл ввести метод для отправки "сырых данных" ака QByteArray? другими словами, будет ли полезной возможность передавать на сервер не только строки, но и произвольные структуры?
• будет ли полезной возможность отправлять сообщения от сервера клиенту(ам) (вроде броадкаста)?

тестирование, предложения и пожелания приветствуются!

[kuzulis]

будет ли полезной возможность отправлять сообщения от сервера клиенту(ам) (вроде броадкаста)?

если имеется ввидо это:
1. клиент подключается к серверу
2. запрашивает у сервера какие то данные спорадически  (не отключаясь после запроса - а поддерживая канал в коннекте)
3. сервер время от времени шлет ПОДКЛЮЧЕННОМУ  клиенту данные спорадически (не отключая при этом клиента после передачи ему данных)

то это оч нужно! (мне по крайней мере для моего "проекта")
штобы был FullDuplex

ЗЫ: и кстати, когда там xml-rpc под QT4 переделаете? оч нужно !!! (именно там нужен FULL DUPLEX)

[ритт]

"отключений" как таковых не продполагается вообще, т.к. при внезапной смерти клиент не в состоянии уведомить сервер об отключении. можно, конечно, следить за клиентами по их пиду (всё-таки клиент и сервер выполняются на одной машине в единой сессии), но имеет ли смысл серверу вообще знать своих клиентов "в лицо"?
всё же последний пункт мне не кажется востребованным, но спросить никогда лишним не бывает...

на счёт хмл-рпц: бОльшая часть запланированного уже реализована, но продолжить смогу только на следующей неделе...если в новом месяце не загрузят с головой...