kami

У меня есть смутное подозрение, что код сервиса почему-то не обновляется. Т.е ваш сервис остается самой первой версии, какой был установлен. Ничем другим объяснить такое поведение я не могу  
Попробуйте кроме сохранения в ини писать в лог, что ли...

Нужно использовать myObject.Release, а не Free.
Только обратите внимание, что Release - это отложенное уничтожение, т.е. моментально компонент исчезает с формы, а вот уничтожится - после, когда-нибудь, когда до него дойдет очередь.
Помимо этого, если ссылка на объект есть где-то в поле класса, то нужно заnil-ить ее, дабы уменьшить счетчик ссылок.

Нужно использовать myObject.Release, а не Free.
Только обратите внимание, что Release - это отложенное уничтожение, т.е. моментально компонент исчезает с формы, а вот уничтожится - после, когда-нибудь, когда до него дойдет очередь.
Помимо этого, если ссылка на объект есть где-то в поле класса, то нужно заnil-ить ее, дабы уменьшить счетчик ссылок.

Нужно использовать myObject.Release, а не Free.
Только обратите внимание, что Release - это отложенное уничтожение, т.е. моментально компонент исчезает с формы, а вот уничтожится - после, когда-нибудь, когда до него дойдет очередь.
Помимо этого, если ссылка на объект есть где-то в поле класса, то нужно заnil-ить ее, дабы уменьшить счетчик ссылок.

Основываясь на фразе "создании приложения только для Windows"
Сама Embarcadero продолжает говорить, что под Windows ничего лучше VCL нет. Используя VCL вы можете задействовать все возможности, предоставляемые операционной системой. Если чего-то будет нехватать для работы (в чем я сомневаюсь, арсенал компонентов и контролов, созданных в рамках VCL, весьма обширен) - к вашим услугам полный набор WinAPI. Все VCL контролы основываются на вызовах WinAPI функций, что гарантирует (ну да, громко сказано, конечно) их быструю работу, поскольку она контролируется оптимальным кодом самой ОС. Помимо этого, некоторые задачи практически невозможно решить без задействования функций ОС. Например, хуки, сервисы, нестандартное поведение при движении мыши (WM_NCHITTEST)... Поведение контролов также будет 100% таким, как пользователь привык видеть во всех приложениях родной ОС.
Да, на FMX тоже можно использовать функции ОС и нативные контролы. Но микс нативных и "собственных" контролов приводит к извращениям по расположению и компоновке контролов, т.к. нативный контрол всегда отрисуется поверх собственных. Также, т.к. Windows основана на механизме передачи оконных сообщений - есть определенные сложности в применении WinAPI. Ну и - если вы задействуете WinAPI функции, т.е. привяжетесь к конкретной ОС - смысл тогда использовать FMX?
 
Резюмируя - если работа действительно планируется только под Windows - используйте VCL.
Если хоть в отдаленном будущем мелькает возможность работы приложения на других платформах - то сразу нужно работать на FMX, этим вы избавите себя от проблем портирования приложения.
 

Основываясь на фразе "создании приложения только для Windows"
Сама Embarcadero продолжает говорить, что под Windows ничего лучше VCL нет. Используя VCL вы можете задействовать все возможности, предоставляемые операционной системой. Если чего-то будет нехватать для работы (в чем я сомневаюсь, арсенал компонентов и контролов, созданных в рамках VCL, весьма обширен) - к вашим услугам полный набор WinAPI. Все VCL контролы основываются на вызовах WinAPI функций, что гарантирует (ну да, громко сказано, конечно) их быструю работу, поскольку она контролируется оптимальным кодом самой ОС. Помимо этого, некоторые задачи практически невозможно решить без задействования функций ОС. Например, хуки, сервисы, нестандартное поведение при движении мыши (WM_NCHITTEST)... Поведение контролов также будет 100% таким, как пользователь привык видеть во всех приложениях родной ОС.
Да, на FMX тоже можно использовать функции ОС и нативные контролы. Но микс нативных и "собственных" контролов приводит к извращениям по расположению и компоновке контролов, т.к. нативный контрол всегда отрисуется поверх собственных. Также, т.к. Windows основана на механизме передачи оконных сообщений - есть определенные сложности в применении WinAPI. Ну и - если вы задействуете WinAPI функции, т.е. привяжетесь к конкретной ОС - смысл тогда использовать FMX?
 
Резюмируя - если работа действительно планируется только под Windows - используйте VCL.
Если хоть в отдаленном будущем мелькает возможность работы приложения на других платформах - то сразу нужно работать на FMX, этим вы избавите себя от проблем портирования приложения.
 

Основываясь на фразе "создании приложения только для Windows"
Сама Embarcadero продолжает говорить, что под Windows ничего лучше VCL нет. Используя VCL вы можете задействовать все возможности, предоставляемые операционной системой. Если чего-то будет нехватать для работы (в чем я сомневаюсь, арсенал компонентов и контролов, созданных в рамках VCL, весьма обширен) - к вашим услугам полный набор WinAPI. Все VCL контролы основываются на вызовах WinAPI функций, что гарантирует (ну да, громко сказано, конечно) их быструю работу, поскольку она контролируется оптимальным кодом самой ОС. Помимо этого, некоторые задачи практически невозможно решить без задействования функций ОС. Например, хуки, сервисы, нестандартное поведение при движении мыши (WM_NCHITTEST)... Поведение контролов также будет 100% таким, как пользователь привык видеть во всех приложениях родной ОС.
Да, на FMX тоже можно использовать функции ОС и нативные контролы. Но микс нативных и "собственных" контролов приводит к извращениям по расположению и компоновке контролов, т.к. нативный контрол всегда отрисуется поверх собственных. Также, т.к. Windows основана на механизме передачи оконных сообщений - есть определенные сложности в применении WinAPI. Ну и - если вы задействуете WinAPI функции, т.е. привяжетесь к конкретной ОС - смысл тогда использовать FMX?
 
Резюмируя - если работа действительно планируется только под Windows - используйте VCL.
Если хоть в отдаленном будущем мелькает возможность работы приложения на других платформах - то сразу нужно работать на FMX, этим вы избавите себя от проблем портирования приложения.
 

Основываясь на фразе "создании приложения только для Windows"
Сама Embarcadero продолжает говорить, что под Windows ничего лучше VCL нет. Используя VCL вы можете задействовать все возможности, предоставляемые операционной системой. Если чего-то будет нехватать для работы (в чем я сомневаюсь, арсенал компонентов и контролов, созданных в рамках VCL, весьма обширен) - к вашим услугам полный набор WinAPI. Все VCL контролы основываются на вызовах WinAPI функций, что гарантирует (ну да, громко сказано, конечно) их быструю работу, поскольку она контролируется оптимальным кодом самой ОС. Помимо этого, некоторые задачи практически невозможно решить без задействования функций ОС. Например, хуки, сервисы, нестандартное поведение при движении мыши (WM_NCHITTEST)... Поведение контролов также будет 100% таким, как пользователь привык видеть во всех приложениях родной ОС.
Да, на FMX тоже можно использовать функции ОС и нативные контролы. Но микс нативных и "собственных" контролов приводит к извращениям по расположению и компоновке контролов, т.к. нативный контрол всегда отрисуется поверх собственных. Также, т.к. Windows основана на механизме передачи оконных сообщений - есть определенные сложности в применении WinAPI. Ну и - если вы задействуете WinAPI функции, т.е. привяжетесь к конкретной ОС - смысл тогда использовать FMX?
 
Резюмируя - если работа действительно планируется только под Windows - используйте VCL.
Если хоть в отдаленном будущем мелькает возможность работы приложения на других платформах - то сразу нужно работать на FMX, этим вы избавите себя от проблем портирования приложения.
 

Основываясь на фразе "создании приложения только для Windows"
Сама Embarcadero продолжает говорить, что под Windows ничего лучше VCL нет. Используя VCL вы можете задействовать все возможности, предоставляемые операционной системой. Если чего-то будет нехватать для работы (в чем я сомневаюсь, арсенал компонентов и контролов, созданных в рамках VCL, весьма обширен) - к вашим услугам полный набор WinAPI. Все VCL контролы основываются на вызовах WinAPI функций, что гарантирует (ну да, громко сказано, конечно) их быструю работу, поскольку она контролируется оптимальным кодом самой ОС. Помимо этого, некоторые задачи практически невозможно решить без задействования функций ОС. Например, хуки, сервисы, нестандартное поведение при движении мыши (WM_NCHITTEST)... Поведение контролов также будет 100% таким, как пользователь привык видеть во всех приложениях родной ОС.
Да, на FMX тоже можно использовать функции ОС и нативные контролы. Но микс нативных и "собственных" контролов приводит к извращениям по расположению и компоновке контролов, т.к. нативный контрол всегда отрисуется поверх собственных. Также, т.к. Windows основана на механизме передачи оконных сообщений - есть определенные сложности в применении WinAPI. Ну и - если вы задействуете WinAPI функции, т.е. привяжетесь к конкретной ОС - смысл тогда использовать FMX?
 
Резюмируя - если работа действительно планируется только под Windows - используйте VCL.
Если хоть в отдаленном будущем мелькает возможность работы приложения на других платформах - то сразу нужно работать на FMX, этим вы избавите себя от проблем портирования приложения.
 

Это далеко не всем очевидно
Есть определенная категория пользователей и работающих на них программистов - финансисты. Дык вот, эта категория действительно считает, что они должны видеть все, абсолютно все данные сразу. На самом деле, им это конечно не нужно. Но надо! При этом на предложение сделать lazy load делаются круглые глаза и "не, это слишком сложно". Ну да, лучше получать Out of memory...

Это плохо. Лучше сделать Last/First возвращенного датасета (чтобы он 100% подсчитал количество строк) и сразу выставить нужное количество строк для грида.

Дался вам этот акутест. Лучше посоветуйте на счет TreeView

Можно помучаться с TListView, но я остановился на TPresentedScrollBox и стилизованных Label'ах (облачки сообщений, под разные scale на png 9patch), скорость скролла хорошая, плюс есть боунсы и тд.
Приложил исходники проекта, также в архиве отдельно chat.style
procedure TForm2.ChatUp(UsID: integer; LastId: integer; CText: string); var   Labb: TLabel;   Marg: Single;   LT: TLayout; begin   LT := TLayout.Create(PR);   LT.Parent := PR.Content;   LT.Margins.Top := 2;   LT.Align := TAlignLayout.Top;   LT.Position.Y := PR.ContentBounds.Height + 50;   Marg := PR.Width * 0.20;   Labb := TLabel.Create(PR);   Labb.Parent := PR;   Labb.Align := TAlignLayout.Top;   Labb.AutoSize := True;   Labb.WordWrap := True;   Labb.TextSettings.WordWrap := True;   if UsID = 0 then   begin     Labb.Margins.Left := Marg;     Labb.Margins.Right := 4;     Labb.TextAlign := TTextAlign.Trailing;     Labb.StyleLookup := 'labelchat_green';   end   else   begin     Labb.Margins.Right := Marg;     Labb.Margins.Left := 4;     Labb.TextAlign := TTextAlign.Leading;     Labb.StyleLookup := 'labelchat_white';   end;   Labb.NeedStyleLookup;   Labb.Text := ' ' + CText + ' ';   LT.Height := Labb.Height + 4;   Labb.Parent := LT;   if UsID = 0 then     Labb.Align := TAlignLayout.Right   else     Labb.Align := TAlignLayout.Left; end; Первые признаки шизофрении:

Chat.zip

vkbdHelper имеет весьма интересный алгоритм - если он находит scrollbox и понимает, что тот в состоянии поднять поле ввода так, чтобы оно было над клавиатурой, то собственный Layout не создается, а прокручивается имеющийся ScrollBox. Но там какой-то алгоритм работы со scrollbox-ом, который отличается от штатной демки.
Не проверял этот момент и не менял его, попробую посмотреть, когда разгребусь с текущими вопросами.

Вам нужны координаты клавиатуры (пересчитанные из Screen в Client)  и AbsoluteRect поля ввода.
if vkbdRect.IntersectsWith(EditAbsoluteRect) then   // пересекаются. Однако, следует обратить внимание на оба issue в комментариях - сообщенный приложению размер клавиатуры не всегда соответствует действительности.

Коллеги, прошу при возможности протестировать очередную модификацию модуля.
К сожалению, Santya видимо покинул форум надолго, так что отработать решение проблемы и возможные недостатки на "первом подопытном" не удалось.
 
Основные изменения: очень многое переписал. По большому счету от исходного модуля осталась идея и два фундаментальных момента.
 
Как обычно, спасибо Rusland за тестирование.    Осталось проверить, как ведет себя модуль с ScrollBox-ами, которые не растянуты на всю форму.
 
vkbdhelper.zip

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

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

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

Победил сортировку по умолчанию. Теперь для рубрики Вопрос/Ответ по умолчанию используется сортировка по дате публикации.

что значит "просто показать клавиатуру"? Грид сам по себе не работает с клавиатурой, его дело - просто нарисовать содержимое. Чтобы ячейку можно было изменить, гридом каждый раз создается редактор, умеющий принимать фокус ввода, события от клавиатуры и т.п. Если его не создаете вы - его создаст сам грид, на основе своих предпочтений.
Допустим, что возможно показанной клавиатуре изменить тип программно. Но не думаю, что клавиатура нужна вам только в гриде. Получается - задача разрастается:
1. отловить поднятие клавиатуры
2. определить, что элемент, "поднявший" ее - находится в нужном гриде, в нужной колонке (а как? Лень смотреть код грида, но это будет нужно лезть через Parent-ы, определять принадлежность редактора к гриду, определять к какой колонке относится редактор)
3. Если все условия выполнены - менять тип клавиатуры.
И весь этот код не будет относиться к самому модулю с гридом напрямую. Плохо. Некрасиво.

Создавайте свой редактор в OnCreateCustomEditor и выставляйте ему нужный тип клавиатуры.

Так и делайте.
ParseItem(i). Емнип, значение будет размещено в стеке, так что последующие изменения переменной на уже созданный таск не повлияют.

Да никто вас не отфутболивает. Но, с учетом того, что TMS-ом среди участников форума (вроде как) пользуется не так уж много народа - вряд ли стоит ожидать глобального понимания проблемы. Тем более - если она не воспроизводится у других.
Кроме того - если не получается создать минимальный воспроизводимый пример, вряд ли смогут помочь и сами TMS-овцы, и тем более - Embarcadero-вцы.
Судя по исходникам TMS - начиная с XE7 они используют свою реализацию для Edit-а, основанную на TStyledControl. И эта реализация по беглому взгляду не должна отличаться на Seattle и Seattle Upd1. Поэтому в решении проблемы поможет только MVCE - Minimal, Complete, and Verifiable example

Вы не ответили на вопрос. Слова "по приемке" для меня и, думаю, большинства остальных посетителей форума ничего не скажут.
Я понимаю, что вы можете это сделать, но испытываете какие-то затруднения, иначе не задали бы этот вопрос.
 
Давайте уйдем от специфики вашей области и оставим чисто программные понятия (дальше нужны ваши уточнения):
1. Стороннее приложение (а сторонее ли, или ваше ? Это очень важный момент) рисует что-то.
1. Это что-то сохраняется как ...??? Совершенно непонятно, что вы имеете ввиду под словом "схема" - это может быть что угодно, включая никому кроме автора неизвестный формат.
2. есть необходимость найти на ней пиксели определенного цвета и поверх них отрисовать картинку.
 
В общем - конкретизируйте вашу задачу. Перечитайте свой вопрос с точки зрения человека, который первый раз его видит и вообще "не в теме", что там у вас за лампочки и схемы.