kami

Пользователи
  • Публикации

    452
  • Зарегистрирован

  • Посещение

  • Days Won

    17

Все публикации пользователя kami

  1. В первую очередь - ошибка в месте вызова Log.d Где производится запись в лог? Правильно, в конструкторе компонента. А где выставляются позиция и габариты? Да, после завершения работы конструктора. Когда Log.D уже отработал.
  2. userSelectedRowIndex:=grid.Selected; Или использовать OnSelectCell, там Row и Col выбранной ячейки доступны напрямую. Всё, строка (возможно - и колонка) получены, дальше дело за вашим кодом.
  3. Этот глюк идет в делфи с незапамятных времен. Я выхожу из ситуации так: если что-то нужно подправить визуально: 1 меняю предка на TFrame. 2 сохраняю модуль, заново его открываю (теперь дизайнер будет работать нормально, но естественно - не скомпилируется). 3 кидаю все что нужно на фрейм, настраиваю свойства и события 4 сохраняю 5 меняю предка опять на нужного и работаю с кодом (теперь компилироваться будет, но дизайнер опять недоступен). Иногда получается после п.2 выполнить 5 и дизайнер продолжает быть доступным. До закрытия вкладки с модулем.
  4. Вы слишком категоричны. 90% глюков, на которые разработчик отвечает "ну у меня же работает" все-таки связаны с недочетами в коде. Да, в этом недочете принимает участие конфигурация оборудования, установленного ПО, объема ОЗУ и т.д. и т.п. Но именно Вам придется "обходить" эту ситуацию, а не пользователю - менять конфигурацию. И стартом в этом направлении могут послужить рекомендации ENRGY.
  5. Нормативная документация (устав, цели, программа) Актуальные вопросы на предстоящую повестку дня на какой-нибудь сессии Обращения от граждан (хотя они гораздо чаще идут на конкретного представителя) "Внутреннее" голосование по какому-нибудь разрабатываемому документу / согласование уполномоченными должностными лицами А вообще - лучше всего уточнить у заказчика. Не "какой функционал должен быть у приложения" , "дайте ТЗ", а "давайте вместе подумаем / пофантазируем - вот у нас есть мобильное приложение. И мы будем его использовать для / чтобы ...". Причем это лучше делать не в письменной форме, а при личной встрече (при наличии такой возможности).
  6. Видимо, они были не универсальны, а расширяемы. То есть - заточены под текущую задачу с большим заделом "на будущее". Справедливости ради надо сказать, что у меня тоже http-обмен всегда затачивался под конкретную задачу, без использования чего-то универсализированного. В отличие от некоторых других областей.
  7. Комбобокс отсылает сообщение о создании своего окна выпадающего списка.
  8. А оно и будет хорошо до тех пор, пока хендл формы не пересоздастся.
  9. просто закомментировать пересоздание нативного браузера - не самая хорошая идея. Иногда оно действительно необходимо.
  10. LibraryPath для выбранной платформы в норме?
  11. а это не дедлок. Это, грубо говоря, while true do sleep(maxint); т.е просто засыпаем текущий поток, не влияя при этом на остальные. Дедлок - это когда один поток ждет реакции от другого потока, который ждет реакции от первого потока. Возможно - даже через третьи, четвертые... руки. Получается кольцо ожидания. В приведенном примере никакой зависимости от другого потока, у которого зависимость от этого потока - нет.
  12. не-а. В пределах одного потока можно хоть MaxInt раз входить в критическую секцию, ничего от этого не замерзнет. А вот CS.Enter; myThread.Start; // и внутри execute тоже CS.Enter myThread.WaitFor; Главный поток вошел в критическую секцию, запустил доп.поток и ожидает, пока тот завершится (надуманный пример, не надо делать поток ради делания потока). Доп.поток тоже вошел в критическую секцию и оказался заблокирован, потому что главный поток уже занял ее "под себя". Итого - главный поток висит, ожидая пока завершится доп., а доп.висит, ожидая пока освободится секция.
  13. Да. И иногда очень удобно. Сразу получаешь полный набор консистентных данных (главных и зависимых), выполнив всего один запрос к базе.
  14. ADO? Работаем с первым. Потом: myADOStoredProc.Recordset := myADOStoredProc.NextRecordset(i); // здесь i - фейковая Integer переменная, она не понадобится далее И продолжаем работать с первым, но теперь там уже сидит второй Возможно, прокатит и такой финт ушами: myADOStoredProc.open; tmpQuery.Recordset:=myADOStoredProc.NextRecordset(i); // и пробуем использовать StoredProc как первый набор данных, а tmpQuery - как второй. Но не факт, что такое получится, // возможно - для правильного подтягивания рекордсета в сторонний квери потребуется сперва открыть его фейковым запросом, например /// `Select 1`
  15. Вы подменяете понятия. Озвученное - это (возможно) "самое разумное решение", если "надо сделать быстро, а дальше трава не расти" (вспоминаем картинку быстро-качественно-дорого), а никак не самое правильное. У индейцев есть как минимум одна плохая черта - они очень любят покушать ресурсы системы, особенно - посоздавать потоков. Посему система, построенная на тетеринге будет не очень масштабируемой в условиях интенсивного обмена. Небольшая ремарка - еще в первой версии появления нативных http компонентов официальные представители Embarcadero настоятельно стали рекомендовать отказаться от Indy. Самое правильное решение должно удовлетворять всем требованиям, предъявляемым к приложению, обладать хорошей способностью к модификации/устранению ошибок/надстраиваемостью функционала и быть легко масштабируемым. У тетеринга есть одно неоспоримое преимущество - это кроссплатформенность. В остальном правильность выбора его в качестве решения зависит от задачи.
  16. не соглашусь. Тетеринг основан на Indy, а это уже автоматически означает "не самое правильное".
  17. и однобокая. Далеко не всегда есть необходимость парсить гигабайтные джейсоны. Чаще (имхо) бывает нужно обработать много достаточно маленьких, но с какой-нибудь структурой а-ля "массив объектов в объекте, который в...". Или быстро сформировать свой (много своих). И вот тут картина может поменяться.
  18. В описании русским по экрану написано: " Классы-обертки над TClient|TServerSocket, работоспособны Delphi 2009 и выше "
  19. Ну, из всех вопросов - важен только первый. Остальное уже есть неоднократно. Пропиарю себя: https://github.com/kami-soft/SimpleTCPComponents
  20. Ну, чукча не читатель, чукча писатель Не посмотрел что обсуждалось ранее, полез сразу в исходники TreeView. Ну, тогда только рекурсия остается...
  21. То, что "жирность" шрифта в этом блоке скачет как хочет - это, по большому счету, ерунда. Но вот то, что "последнее сообщение" в теме не соответствует реальному - это уже плохо. В качестве примера: 1 - скрин главной страницы после нажатия Ctrl+F5 (полное обновление, минуя кеш) 2 - скрин темы. Самое интересное - что цифра 4 на главной странице действительно соответствует количеству ответов в теме. Вот только последний - не от того пользователя.
  22. Мне, по большому счету, без разницы что за дата Я ориентируюсь на ники участников. Я считал, что если заголовок блока - "Последние сообщения", то и информация должна быть о последних сообщениях. В приведенном мной примере в п.1 - автор "последнего сообщения" - один, а по факту, когда заходишь в тему - совсем другой. Получается, что в текущей реализации блок стоило бы назвать "обновления в темах", "обсуждаемые темы" или что-то в этом духе. Дабы не вводить в заблуждение.
  23. на потерю фокуса эдитом - скрыть клавиатуру. на получение фокуса - показать. как-то так.