Опрос о приоритетах
В идеале так и должно быть, но к сожалению эта функция не совсем корректно работает. Да в большинстве случаев вообще не работает. (как я понял - это происходит потому что большинство клиентов не принимает контакты - видимо они передаются каким-то особым методом. Но не понятно тогда почему нельзя сделать так, чтобы они передавались просто в виде слова(ник)-и цифр(UIN)? )
Мне кажется либо уж ее совсем стоит убрать, чтобы не мозолила глаза, либо отладить!
Благодарю за лучший ICQ клиент!
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Wendor писал(а):
Я бы тоже ЗА, но сначала одно, а потом другое...Я за jabber и за общий клиент (ICQ + Jabber в одной запущенной копии)
Самое лучшее, это если попробовать развивать первое и второе направление одновременно.
Вот у меня к примеру две аськи (одна личная, другая рабочая), а ещё я очень давно хочу подключить свой гугловский аккаунт, только вот держать на десктопе (и трее) кучу копий окон R&Q я совсем не хочу, а вот еслиб всё это работало в одном окне...
В итоге получается, что поддержка XMPP это круто! Только вот без поддержки многоаккаунтности для меня это абсолютно не юзабильно.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Дело не в ос, насколько я помню стандартные средства работы с файлами позволяют писать по смещению.Пушкожук писал(а):
В Windows Vista появилась возможность писать файлы транзакциями.xml-файл тоже может повредиться. Нужно как-то по-другому писать в файлы (FILE_FLAG_WRITE_THROUGH? Или делать бэкапы автоматически с некоторым интервалом?)
...
Из-за того, что в XP такого нет, я не стал заморачиваться с этим.
Rapid D писал(а):
В общем, если кто знает как сделать сохранение более надёжным - прикладывайте код, который нужно поменять.
По моей логике, код:подразумевает, что в любой момент существует целый файл настроек. И только при условии кривых дров, старый файл стирается быстрее, чем запишется новый.zf.SaveToFile(uPath+dbFileName + '4.new'); DeleteFile(uPath+dbFileName + '4'); RenameFile(uPath+dbFileName + '4.new', userPath+dbFileName + '4');
Могут быть бока если конфиг сохраняется при завершении приложения, такого не должно быть.
Также нужно паузу добавить между операциями если есть проблема с асинхронным выполнением операций. И изменить их порядок. И добавить обработчики исключений.
Во первых доступ на чтение к файлу настроек должен открываться только в случает
1) запуска программы
2) открытия окна настроек
После чего файл конфига считывается и доступ к нему закрывается.
Во вторых доступ на запись открывается только при нажатии на кнопку ОК или ПРИМЕНИТЬ в окне настроек.
В этот же момент происходит сохранение конфига. Больше ни в каких других частях программы (кроме запоминания пароля я так понимаю).
В итоге должно выглядеть как то так.
if(zf.SaveToFile(uPath+dbFileName + '4.new')==0) then begin
pause(100);
if(FileExist(uPath+dbFileName + '4.old') then DeleteFile(uPath+dbFileName + '4.old');
pause(100);
RenameFile(uPath+dbFileName + '4', userPath+dbFileName + '4.old');
pause(100);
if(RenameFile(uPath+dbFileName + '4.new', userPath+dbFileName + '4')<>0(Ошибка)) then begin
pause(100);
RenameFile(uPath+dbFileName + '4.old', userPath+dbFileName + '4');
Error window;
end;
end;Увы как на делфи писать уже не помню
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Но есть же кэширование записи. То есть, после закрытия файла данные на самом деле могут лежать в кэше, а не на диске. Сколько они там пролежат - известно только разработчикам WindowsПо моей логике, код:
подразумевает, что в любой момент существует целый файл настроек. И только при условии кривых дров, старый файл стирается быстрее, чем запишется новый.zf.SaveToFile(uPath+dbFileName + '4.new'); DeleteFile(uPath+dbFileName + '4'); RenameFile(uPath+dbFileName + '4.new', userPath+dbFileName + '4');
Помню, читал на другом форуме, что данные могут месяцами не записываться на диск, если постоянно обновляются (тема была о восстановлении БД после сбоя). Флаг FILE_FLAG_WRITE_THROUGH (если верить MSDN) отключает кэширование, но, по идее, замедлит работу программы.Legeon писал(а):
Файл настроек представляет собой zip-архив, поэтому можно только писать его полностью, с начала и до конца.Дело не в ос, насколько я помню стандартные средства работы с файлами позволяют писать по смещению.
Ещё проблема в том, что в архиве хранятся не только настройки, а много чего ещё:
- тексты автосообщений и доп. статусов
- контакт-лист
- база данных контактов
- список видящих, невидящих, игнора и др.
- список открытых вкладок чата
- непрочитанные входящие сообщения
- неотправленные исходящие сообщения (которые можно просмотреть в Меню-Дополнительно-Исходящие)
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Давненько досовских фукций типа "pause" не встречала.В итоге должно выглядеть как то так.
if(zf.SaveToFile(uPath+dbFileName + '4.new')==0) then begin pause(100); if(FileExist(uPath+dbFileName + '4.old') then DeleteFile(uPath+dbFileName + '4.old'); pause(100); RenameFile(uPath+dbFileName + '4', userPath+dbFileName + '4.old'); pause(100); if(RenameFile(uPath+dbFileName + '4.new', userPath+dbFileName + '4')<>0(Ошибка)) then begin pause(100); RenameFile(uPath+dbFileName + '4.old', userPath+dbFileName + '4'); Error window; end; end;
Вообще то, для Windows уже давно сделали вот такое WaitForSingleObjectEx
А также, асинхронный I/O (см. состояние Alertable).
Правила применения этих WinAPI функций от языка (Deplhi/C/C++) не зависят, разве что синтаксис чуть отличается.
Пушкожук писал(а):
Самое интересное еще может скрываться в объектном методе "zf.SaveToFile".Rapid D писал(а):
По моей логике, код:
zf.SaveToFile(uPath+dbFileName + '4.new'); DeleteFile(uPath+dbFileName + '4'); RenameFile(uPath+dbFileName + '4.new', userPath+dbFileName + '4');
Есть большие сомнения, что реализация класса владельца пишет свой поток одной порцией (то есть одним вызовом WriteFile), это скорее всего только объектная чать выглядит красиво.
Это плюс к проблеме неопределенного по времени кэширования. Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Ну не такие уж они и досовские, просто блокировка потока на время, я к тому что если там асинхронная белиберда и нормально обрабатывать ее нет возможности то небольшая пауза решит проблему, или по крайней мере ее смягчит.Давненько досовских фукций типа "pause" не встречала.
Вообще то, для Windows уже давно сделали вот такое WaitForSingleObjectEx
А также, асинхронный I/O (см. состояние Alertable).
Правила применения этих WinAPI функций от языка (Deplhi/C/C++) не зависят, разве что синтаксис чуть отличается.
Самое интересное еще может скрываться в объектном методе "zf.SaveToFile".
Есть большие сомнения, что реализация класса владельца пишет свой поток одной порцией (то есть одним вызовом WriteFile), это скорее всего только объектная чать выглядит красиво.
А по поводу хеша, не так часто что то в этот конфиг пишеться.
К тому же, как я уже раньше писал, так ли целесообразен этот зип что там формат.
Может отказаться от подобного и разделить эту мегабазу на несколько xml файлов без всяких сжатий.
Кстати кстати, а где можно последние исходники глянуть и в чем их можно открыть? Может гляну что там...? Вспомню молодость)
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
DarkHeavy писал(а):
Могу попробовать реализовать это в виде плагинаСделать возможность записывать историю переписки только с определёнными UIN'ами.
Другими словами добавить в поп-ап меню, которое появляется при нажатии на номер контакта правой кнопкой, "галочку" записывать историю. Глобально запись/не запись истории выставляется в настройках, но если надо, чтобы история записывалась не для всех, выбираем контакт и снимает "галочку" записывать истори. непосредственно с контакта
Ну пожалуйста!
Был бы очень признателен
Спасибо Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
эти кнопки даже в квипе работают... в миранде тоже. Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
А разве процедура Pause есть вообще в актуальных версиях Delphi (Delphi 6 и выше)? Не смогла найти ее исходник в CRT.Ну не такие уж они и досовские, просто блокировка потока на время, я к тому что если там асинхронная белиберда и нормально обрабатывать ее нет возможности то небольшая пауза решит проблему, или по крайней мере ее смягчит.
Приостановка потока выглядит так: SleepEx .
Но прежде чем его приостанавливать (тем более на длительный интервал), не стоит ли разобраться, есть ли какая другая асинхронная обработка в этом потоке(те же UserAPC которые так любит Delphi), и чем это чревато?
Да и зачем все это мучение, когда WinAPI всегда может точно сказать, когда закончилась какая-либо операция?
Имхо, ненадежность записи "db5", это вопрос надежности кода компонента SciZipFile.
Вряд ли сама крыса этим грешит.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Хм, а зажать ctrl или alt, и потом нажимать "Page Up, Page Down, Home и End" - так вам очень не нравица?Еще, еще.
Нужно чтобы в окне чата работали кнопки Page Up, Page Down, Home и End, не то чтобы без них никак но навигация затрудняется.
cy6 писал(а):
По моему мы с вами уже это обсуждали, и меня даже убедили в ненадёжности "кода компонента SciZipFile".Legeon писал(а):
А разве процедура Pause есть вообще в актуальных версиях Delphi (Delphi 6 и выше)? Не смогла найти ее исходник в CRT.Ну не такие уж они и досовские, просто блокировка потока на время, я к тому что если там асинхронная белиберда и нормально обрабатывать ее нет возможности то небольшая пауза решит проблему, или по крайней мере ее смягчит.
...
Имхо, ненадежность записи "db5", это вопрос надежности кода компонента SciZipFile.
Вряд ли сама крыса этим грешит.
А потому, считайте, что строка "zf.SaveToFile(uPath+dbFileName + '4.new');" передаёт весь файл одним куском!
Можно попробовать добавить флаг FILE_FLAG_WRITE_THROUGH для записи БД (включаемое отдельной настройкой, для неблагоприятных компов).
Правда тогда наверное придёться выносить сохранение в отдельный поток, чтобы вся программа не подвисала.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.