kami

Вы уверены, что это хорошая идея? Когда много уровней вложенности есть хороший шанс вообще не увидеть веток дерева. В какой-то версии TTreeView исправлялся так, чтобы текст не обрезался. А Вы хотите вернуть такое поведение назад?
Item1
  SubItem1
    SubItem2
      SubIte
        SubI
          Su
            ...
   
 
 

Нормативная документация (устав, цели, программа)
Актуальные вопросы на предстоящую повестку дня на какой-нибудь сессии
Обращения от граждан (хотя они гораздо чаще идут на конкретного представителя)
"Внутреннее" голосование по какому-нибудь разрабатываемому документу / согласование уполномоченными должностными лицами
А вообще - лучше всего уточнить у заказчика. Не "какой функционал должен быть у приложения" , "дайте ТЗ", а "давайте вместе подумаем / пофантазируем - вот у нас есть мобильное приложение. И мы будем его использовать для / чтобы ...". Причем это лучше делать не в письменной форме, а при личной встрече (при наличии такой возможности).
 

Нормативная документация (устав, цели, программа)
Актуальные вопросы на предстоящую повестку дня на какой-нибудь сессии
Обращения от граждан (хотя они гораздо чаще идут на конкретного представителя)
"Внутреннее" голосование по какому-нибудь разрабатываемому документу / согласование уполномоченными должностными лицами
А вообще - лучше всего уточнить у заказчика. Не "какой функционал должен быть у приложения" , "дайте ТЗ", а "давайте вместе подумаем / пофантазируем - вот у нас есть мобильное приложение. И мы будем его использовать для / чтобы ...". Причем это лучше делать не в письменной форме, а при личной встрече (при наличии такой возможности).
 

Нормативная документация (устав, цели, программа)
Актуальные вопросы на предстоящую повестку дня на какой-нибудь сессии
Обращения от граждан (хотя они гораздо чаще идут на конкретного представителя)
"Внутреннее" голосование по какому-нибудь разрабатываемому документу / согласование уполномоченными должностными лицами
А вообще - лучше всего уточнить у заказчика. Не "какой функционал должен быть у приложения" , "дайте ТЗ", а "давайте вместе подумаем / пофантазируем - вот у нас есть мобильное приложение. И мы будем его использовать для / чтобы ...". Причем это лучше делать не в письменной форме, а при личной встрече (при наличии такой возможности).
 

Нормативная документация (устав, цели, программа)
Актуальные вопросы на предстоящую повестку дня на какой-нибудь сессии
Обращения от граждан (хотя они гораздо чаще идут на конкретного представителя)
"Внутреннее" голосование по какому-нибудь разрабатываемому документу / согласование уполномоченными должностными лицами
А вообще - лучше всего уточнить у заказчика. Не "какой функционал должен быть у приложения" , "дайте ТЗ", а "давайте вместе подумаем / пофантазируем - вот у нас есть мобильное приложение. И мы будем его использовать для / чтобы ...". Причем это лучше делать не в письменной форме, а при личной встрече (при наличии такой возможности).
 

Нормативная документация (устав, цели, программа)
Актуальные вопросы на предстоящую повестку дня на какой-нибудь сессии
Обращения от граждан (хотя они гораздо чаще идут на конкретного представителя)
"Внутреннее" голосование по какому-нибудь разрабатываемому документу / согласование уполномоченными должностными лицами
А вообще - лучше всего уточнить у заказчика. Не "какой функционал должен быть у приложения" , "дайте ТЗ", а "давайте вместе подумаем / пофантазируем - вот у нас есть мобильное приложение. И мы будем его использовать для / чтобы ...". Причем это лучше делать не в письменной форме, а при личной встрече (при наличии такой возможности).
 

Видимо, они были не универсальны, а расширяемы. То есть - заточены под текущую задачу с большим заделом "на будущее".
Справедливости ради надо сказать, что у меня тоже http-обмен всегда затачивался под конкретную задачу, без использования чего-то универсализированного. В отличие от некоторых других областей.

Подумайте о будущем, если проект будет развиваться и одной цифры ошибки станет не достаточно. Подумайте о наследниках-программистах (или о себе через пять лет) которые будут чесать репу и угадывать (вспоминать) что же означает каждая цифра ответа. Времена экономии каждого байта трафика прошли. Вспомните истории предшественников - 640 килобайт более чем достаточно для любого компьютера, 4294967296 ip адресов достаточно для всего человечества, размера MTU 1500 байт достаточно для TCP пакета в обозримом будущем, максимального размера файла в 4 гигабайта достаточно для любых нужд и вряд ли в будущем появятся накопители объемом более 9 терабайт (FAT32).
Отдавая данные/результат в теле ответа в формате JSON вы развязываете себе руки и делаете задел на будущее. Вначале вам достаточно будет вот такого 
{ "status" : true, "error" : 0 } потом возможно такое
{ "status" : false, "error" : 123, "errormessage" : "mysql deadlock in tables employments", } а потом еще что нибудь
{ "status" : true, "error" : 0, "errormessage" : "", "executiontime" : 304, "clastersource" : "bagama_server" } все эти добавления займут у вас одну-две строчки на php и одну-две строчки в приложении. При этом, вы сможете диагностировать ответ сервера, сидя на берегу моря, с помощью браузера вашего телефона.

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

ADO?
Работаем с первым. Потом:
myADOStoredProc.Recordset := myADOStoredProc.NextRecordset(i); // здесь i - фейковая Integer переменная, она не понадобится далее И продолжаем работать с первым, но теперь там уже сидит второй

Возможно, прокатит и такой финт ушами:
 
myADOStoredProc.open; tmpQuery.Recordset:=myADOStoredProc.NextRecordset(i); // и пробуем использовать StoredProc как первый набор данных, а tmpQuery - как второй. Но не факт, что такое получится, // возможно - для правильного подтягивания рекордсета в сторонний квери потребуется сперва открыть его фейковым запросом, например /// `Select 1`  

Да. И иногда очень удобно.
Сразу получаешь полный набор консистентных данных (главных и зависимых), выполнив всего один запрос к базе.

Да. И иногда очень удобно.
Сразу получаешь полный набор консистентных данных (главных и зависимых), выполнив всего один запрос к базе.

ADO?
Работаем с первым. Потом:
myADOStoredProc.Recordset := myADOStoredProc.NextRecordset(i); // здесь i - фейковая Integer переменная, она не понадобится далее И продолжаем работать с первым, но теперь там уже сидит второй

Возможно, прокатит и такой финт ушами:
 
myADOStoredProc.open; tmpQuery.Recordset:=myADOStoredProc.NextRecordset(i); // и пробуем использовать StoredProc как первый набор данных, а tmpQuery - как второй. Но не факт, что такое получится, // возможно - для правильного подтягивания рекордсета в сторонний квери потребуется сперва открыть его фейковым запросом, например /// `Select 1`  

идея Клиент-сервер не работает на мобильных. Используется многозвенная архитектура.
Приложение-клиент через HTTP (класс THTTPClient) связывается с веб-сервером в интернете
а уже веб-сервер связывается с БД и делает что нужно, ну и результаты шлет обратно
веб-сервер можно писать на чем угодно. php js asp и даже на делфи, только сложнее )

Вы подменяете понятия. Озвученное - это (возможно) "самое разумное решение",  если "надо сделать быстро, а дальше трава не расти" (вспоминаем картинку быстро-качественно-дорого), а никак не самое правильное. У индейцев есть как минимум одна плохая черта - они очень любят покушать ресурсы системы, особенно - посоздавать потоков. Посему система, построенная на тетеринге будет не очень масштабируемой в условиях интенсивного обмена. Небольшая ремарка - еще в первой версии появления нативных http компонентов официальные представители Embarcadero настоятельно стали рекомендовать отказаться от Indy.
Самое правильное решение должно удовлетворять всем требованиям, предъявляемым к приложению, обладать хорошей способностью к модификации/устранению ошибок/надстраиваемостью функционала и быть легко масштабируемым.
У тетеринга есть одно неоспоримое преимущество - это кроссплатформенность. В остальном правильность выбора его в качестве решения зависит от задачи.

Вы подменяете понятия. Озвученное - это (возможно) "самое разумное решение",  если "надо сделать быстро, а дальше трава не расти" (вспоминаем картинку быстро-качественно-дорого), а никак не самое правильное. У индейцев есть как минимум одна плохая черта - они очень любят покушать ресурсы системы, особенно - посоздавать потоков. Посему система, построенная на тетеринге будет не очень масштабируемой в условиях интенсивного обмена. Небольшая ремарка - еще в первой версии появления нативных http компонентов официальные представители Embarcadero настоятельно стали рекомендовать отказаться от Indy.
Самое правильное решение должно удовлетворять всем требованиям, предъявляемым к приложению, обладать хорошей способностью к модификации/устранению ошибок/надстраиваемостью функционала и быть легко масштабируемым.
У тетеринга есть одно неоспоримое преимущество - это кроссплатформенность. В остальном правильность выбора его в качестве решения зависит от задачи.

и однобокая.
Далеко не всегда есть необходимость парсить гигабайтные джейсоны. Чаще (имхо) бывает нужно обработать много достаточно маленьких, но с какой-нибудь структурой а-ля "массив объектов в объекте, который в...". Или быстро сформировать свой (много своих). И вот тут картина может поменяться.

Ну, из всех вопросов - важен только первый. Остальное уже есть неоднократно. Пропиарю себя: https://github.com/kami-soft/SimpleTCPComponents

В описании русским по экрану написано: " Классы-обертки над TClient|TServerSocket, работоспособны Delphi 2009 и выше "

Ну, из всех вопросов - важен только первый. Остальное уже есть неоднократно. Пропиарю себя: https://github.com/kami-soft/SimpleTCPComponents

Ну, из всех вопросов - важен только первый. Остальное уже есть неоднократно. Пропиарю себя: https://github.com/kami-soft/SimpleTCPComponents

То, что "жирность" шрифта в этом блоке скачет как хочет - это, по большому счету, ерунда.
Но вот то, что "последнее сообщение" в теме не соответствует реальному - это уже плохо.
В качестве примера:
1 - скрин главной страницы после нажатия Ctrl+F5 (полное обновление, минуя кеш)

2 - скрин темы. Самое интересное - что цифра 4 на главной странице действительно соответствует количеству ответов в теме. Вот только последний - не от того пользователя.

Починил

я так понимаю, вы хотите отправлять почту, не вызывая интерфейс почтового клиента?
здесь самый простой способ имхо описан на StackOverflow
You can build such System. Run a Server side Script in PHP/perl/.net or anything that takes inputs like from, to, subject, body from GET/POST arguments and send the mail. and them use curl or do something similer to convey the information to that page and that page will eventually send the mails for You.

То, что "жирность" шрифта в этом блоке скачет как хочет - это, по большому счету, ерунда.
Но вот то, что "последнее сообщение" в теме не соответствует реальному - это уже плохо.
В качестве примера:
1 - скрин главной страницы после нажатия Ctrl+F5 (полное обновление, минуя кеш)

2 - скрин темы. Самое интересное - что цифра 4 на главной странице действительно соответствует количеству ответов в теме. Вот только последний - не от того пользователя.