kami

Вы побороли следствие. Вам же предлагалось устранить причину. Но - как хотите.

Есть мнение, что для (например) списка контактов нужно использовать ListView, а не ScrollBox

Код все-таки приведите. Тот участок, где получается текст из сканера и пихается в мемо. Включая объявленные переменные.

Это текст в кодировке cp1251 - "Дата розлива 25.10.2015". В каком виде текст появляется в программе?

Да, и забыл сказать: работа с визуальными элементами в отдельном потоке - это плохо, очень плохо...

Я думаю, что просто ListItem - это не тот ListItem, который должен быть Без кода, показывающего, откуда он взялся сложно что-то сказать.

А меня очень смущает вот эта фраза: Я очень надеюсь, что это не то, о чем я подумал.

А нету

Странно... Здесь и на главной delphitour стоит дата 24 ноября. А на странице регистрации уже 26 ноября. Причем 100% помню, еще сегодня днем, когда регистрировался - везде было 24 число. Кому верить? Кстати - а должно прийти на почту что-то типа "спасибо, что зарегистрировались"?

Сто тысяч элементов Не уверен, что какой-либо компонент, кроме VirtualTreeView способен на такое "быстро", но он - только под винду. Пожалейте пользователя - ему явно не нужно столько элементов. Может, стоит пересмотреть UI? В очень редких случаях нужно отображать более 100 (для десктопа) и 20-30 (для мобильных платформ), юзер все равно не охватит такое количество ни взглядом, ни своей оперативкой И - если у Вас дерево одноуровневое, судя по примеру (понятно, что он упрощен) - может, лучше задействовать listView?

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

Доброго времени суток всем! Немного предистории: есть проект, Delphi XE7 под iOS (Ad hoc), делается под нескольких заказчиков со слегка отличающимся функционалом. В модулях проставлены {$IFDEF тра-ля-ля}, с этим проблем нет. Хочется немножко упростить билд релизов, создав "деток" для Build Configurations - Release -- Customer1 -- Customer2 -- etc... Что делаю: В Project Manager правой кнопкой на Release - > New Configuration , задаю имя. Проверяю - все опции наследуются от Release, все (вроде) нормально, добавляю новые Conditional Defines Делаю билд, в Output\IOSDevice создается папка Customer1 и в ней все dcu Делаю деплой - а файлик ipa не появляется, при этом в Target platforms, естественно, выставлено iOSDevice - Ad hoc. Наличие ipa смотрю на подключенном Mac и в output-папке. Сам paserver что-то делает, но не так много, как при Release, такое ощущение, что создает Debug версию. Смотрю в Deployment конфигурации Customer1 - а там все пути указывают не на Output\iOSDevice\Customer1, а на Output\iOSDevice\Release. Ручками в конфигурации задаю все пути как .\Output\$(Platform)\Release , но это тоже не помогает. Что я делаю не так?

Неполный пример - Integer, как и pointer укладывается в регистр EAX/EBX или какие_там_сейчас_у_процессоров. С учетом модели вызовов register, используемой в Delphi, для integer выигрыша в передаче по ссылке/по значению нет. Ну, разве что при передаче по ссылке в винде будет PageFault и процессору придется подгружать страничку. Но это крайне маловероятно, с учетом того, что реальное значение было доступно в вызывающем коде. Поэтому и передается по значению. Корректнее было бы сравнить string, record и array, ибо

rustam_d, сам с удивлением узнал - оказывается (по крайней мере в Seattle) - не обязательно. Пруф: http://docwiki.embarcadero.com/RADStudio/Seattle/en/Parameters_%28Delphi%29#Constant_Parameters Особенно добила фраза Она появилась как минимум в D2010, версии старше просто нет

Andy, вы просто не умеете их готовить В других IDE/языках тоже проблем и глюков более чем есть. А по факту - я надеюсь, что FMX не остановят в развитии. Имхо, Embarcadero сейчас в направлении кросс-платформенности впереди планеты всей. Повторюсь - это было имхо и не повод для холиваров.

Давайте уже действительно прекратим холивары. ТС хочет создать приложение, насколько я понимаю - одно из своих первых. Двузвенка, трехзвенка - без разницы, набьет шишек (зато своих) и дальше уже будет строить архитектуру как надо, исходя из своих задач. Я вот, как ни странно, для Indy10 не нашел примеров организации работы idHTTPServer. С клиентом там все понятно, хотя его работа и вызывает нарекания, к примеру - на кой нужно возбуждать исключение на ответ сервера 400 - непонятно. А вот по серверу - полный ноль, а если мне память не изменяет - сигнатуры событий у индейцев в 10 отличаются от 9. Сам я не использую Indy на сервере, предпочитаю Mormot, он гораздо быстрее и легковеснее. Поделитесь с ТС...

от задачи зависит конечно, но толстого клиента убил Devart.com еще в 90-х..., а если не умеете писать хранимые процедуры...то вам точно не пойдет "толстый" клиент ) теоретически в реализации и задумке, андроид и иос не отличаются от виндовс приложений, а в них ВСЕ толстые )), толстые чтоб вы знали, это "не зависимый интерфейс", веб дефакто тонкий... а вот дроид и иос увольте ), можно тонкий и на них...но не для этого они ) есть магаз же, сбегал обновился, а винде его не было ранее...да и щас мало кто юзает Даже если и умеете писать - толстые клиенты это зло. Именно сервер должен заниматься не только хранением, но и иметь бОльшую часть функционала по обработке данных. Это значительно упрощает всяческие обновления, нововведения и устранения глюков. Попробуйте выпустить мобильного толстого клиента с какой-нибудь незамеченной ошибкой, которая приводит к нестыковке данных в БД, а потом заставить всех пользователей обновить приложение - да половина не сделает этого в разумные сроки. И будете вставлять костыли в свои хранимки. В Windows далеко не все клиенты толсты, у вас устаревшие сведения. "Есть магаз" - я вот принципиально не обновляю из магаза некоторые приложения: часть из них убили отвратительным переводом на Material Design, а часть от версии к версии все больше кушает память, что для моего телефона уже непозволительно. И чтобы вы знали - "толстость" клиента к "независимому интерфейсу" отношения не имеет. Если я правильно вас понял, то под независимым интерфейсом вы понимаете MVC. А "толстость" определяется тем, где производится основная работа с данными: обработка, преобразование, вылавливание ошибок и т.п. Если на клиенте - он толстый, если на сервере - то тонкий.

rustam_d - предлагаете делать двузвенку "мобильный толстый клиент - СУБД"? Имхо, не стоит.

Тогда тем более не стоит возиться с TCP. HTTP вам в руки HTTP API Server - этот компонент не входит в состав Delphi, а является частью ORM mormot - http://synopse.info/fossil/wiki/Synopse+OpenSource Не хотите ставить - используйте Indy и там и сям

Прежде чем что-то обновлять, неплохо было бы вычислить виновника, поскольку исходное сообщение AV - не информативно совсем. При компиляции под винду задействуйте MadExcept /EurecaLog, etc..., он покажет полный стек, включая строки кода, который привел к возникновению AV. Таким образом можно вычислить, кто сплоховал, а дальше ... по обстоятельствам.

Я бы порекомендовал использовать idHTTP на клиенте, а на сервере - mormot HTTPAPIServer. На худой конец - на сервере тоже idHTTPServer. Не стоит использовать TCP для передачи дискретных данных, замучаетесь нивелировать воздействие Нагла и разбиение/склейку пакетов по пути.

Сделайте build (Shift+F9) а не Compile (Ctrl+F9)

Меня одного этот участок кода несколько озадачил? Ну и - не в http дело, тут же tcp в "чистом" виде используется вроде как. То есть - должно быть достаточно указания порт + хост (желательно - в IP виде) Serg557, вы бы хоть сказали - на какой строке выдает ошибку, бо непонятно - то ли при коннекте, то ли при отправке. И кто выдает - клиент или сервер?

Коллеги, никак не могу найти официальную сравнительную таблицу редакций - к примеру, чем Architect отличается от Enterprise. Киньте ссылкой, пожалуйста, ежели кто нашел...

Коллеги, подскажите, на какие блоги надо ходить?