Forum Replies Created
-
Posts
-
В 10.18 исправлен цвет spinedit'ов, которые неактивны.
Но осталась проблема с отображением кнопок при ShowSpinButtons=False 🙂 Достаточно повторить шаги в демке:
1. Запустить программу.
2. Два раза нажать “Change Enabled”.
В итоге на всех spinedit'ах отображаются кнопки. Даже где ShowSpinButtons=False.
Насколько я понимаю, используется OnAdvancedHeaderDraw для отрисовки. В определение Flags для вывода текста можно добавить что-то вроде:
Code:var
…
CaptionAlignment: string;
begin
…
CaptionAlignment := GetEnumProp(PaintInfo.Column, 'CaptionAlignment');
if CaptionAlignment = 'taLeftJustify' then
Flags := Flags + DT_LEFT
else if CaptionAlignment = 'taRightJustify' then
Flags := Flags + DT_RIGHT
else if CaptionAlignment = 'taCenter' then
Flags := Flags + DT_CENTERHave you selected style csOwnerDrawFixed or csOwnerDrawVariable? I am using TsComboBox in some projects and with almost all 10.* AC versions and don't have this problem.
'Yog' wrote:Ибо для ListBox нужно место на форме, которого у меня нет.. А создавать (или хранить на существующей) на отдельной форме пока не хочеться…
Вы можете создавать его динамически вместо меню. В одном проекте использую похожим образом “меню”, которое на самом деле является TVirtualStringTree. Если интересно, могу чуть позже сделать демку с примером меню из TListBox/TsListBox.
Здесь объясняется причина такого поведения TListView. Если вкратце, то при изменении выделения для нескольких записей одновременно вместо OnSelectItem для каждого элемента приходит одно сообщение LVN_ODSTATECHANGED и вызывается OnDataStateChange. Я в Вашем демо добавил обработку этого события для примера. И использовать его для обновления количества записей в заголовке формы будет экономнее, поскольку в OnChanged обновление заголовка будет происходить слишком часто. OnChanged в VCL вызывается после каждого чиха 😀
И до, и после inherited проблема. Похоже, при csLoading в ComponentState не вызывается inherited SetChecked метод внутри TsCheckBox.SetChecked. Может быть это условие стоит оставить для предотвращения каких-то действий со скином, но вызов inherited SetChecked, мне кажется, надо сделать обязательным без всяких условий.
Прикладываю демку с примером. На всякий случай проверил TsRadioButton, но там всё нормально, поведение такое же как и у TRadioButton.[attachment=7300:CheckboxTest.zip]
Там же написано, что это предупреждение только в дизайнере выводится. В скомпилированной программе не должно быть. Не такая уж это проблема.
Сделал демку с двумя гридами (TsDBGrid из AlphaDB и TJVDBUltimGrid из JVCL) и скомпилировал под AC 9.20 и 10.10. Погоняли её на планшете. Выяснилось, что “родной” TsDBGrid всё-таки работает нормально при включенном и выключенном скине. А вот сторонний грид при включенном скине не прокручивается ни в 9.20, ни в 10.10.
TsHintManager is deprecated in 10.x version. You can see it in changelog:
Quote:24.02.2015 AlphaControls v10.00 Beta released…
* Removed TsHintManager deprecated component
Cannot try 9.20 now, but with last 10.05 beta your code works fine for me. In both TListView and TsListView groups are showing with enabled/disabled skins. Maybe you can try it?
Точно такая же ошибка появляется иногда при закрытии приложения (и главной формы, соответственно).
Code:exception class : EAccessViolation
exception message : Access violation at address 00902CF6 in module 'Project1.exe'. Read of address 0FE38FEC.main thread ($1a30):
00902cf6 +036 Project1.exe sCommonData TsCommonData.Destroy
009061f3 +027 Project1.exe sCommonData TsScrollWndData.Destroy
004084fc +008 Project1.exe System 15524 +1 TObject.Free
00458e1c +008 Project1.exe System.SysUtils 24840 +2 FreeAndNil
008ba62b +167 Project1.exe acSBUtils TacMainWnd.Destroy
008aee9d +02d Project1.exe acSBUtils TacScrollWnd.Destroy
004084fc +008 Project1.exe System 15524 +1 TObject.Free
00458e1c +008 Project1.exe System.SysUtils 24840 +2 FreeAndNil
009293a4 +014 Project1.exe sSkinProvider TacAdapterItem.Destroy
004084fc +008 Project1.exe System 15524 +1 TObject.Free
00458e1c +008 Project1.exe System.SysUtils 24840 +2 FreeAndNil
0092924c +040 Project1.exe sSkinProvider TacCtrlAdapter.CleanItems
00928c71 +00d Project1.exe sSkinProvider TacCtrlAdapter.Destroy
004084fc +008 Project1.exe System 15524 +1 TObject.Free
00458e1c +008 Project1.exe System.SysUtils 24840 +2 FreeAndNil
00912f72 +1ce Project1.exe sSkinProvider TsSkinProvider.Destroy
004084fc +008 Project1.exe System 15524 +1 TObject.Free
0053c633 +05b Project1.exe System.Classes 15796 +10 TComponent.DestroyComponents
0053c30b +01b Project1.exe System.Classes 15652 +3 TComponent.Destroy
005b4039 +121 Project1.exe Vcl.Controls 5380 +24 TControl.Destroy
005b890d +141 Project1.exe Vcl.Controls 8398 +39 TWinControl.Destroy
0067d36b +04b Project1.exe Vcl.Forms 3051 +3 TScrollingWinControl.Destroy
0067e470 +11c Project1.exe Vcl.Forms 3722 +32 TCustomForm.Destroy
004084fc +008 Project1.exe System 15524 +1 TObject.Free
0053c633 +05b Project1.exe System.Classes 15796 +10 TComponent.DestroyComponents
0067c135 +035 Project1.exe Vcl.Forms 2158 +9 DoneApplication
0044f3f1 +021 Project1.exe System.SysUtils 5633 +6 DoExitProc
0040a099 +065 Project1.exe System 23151 +44 @Halt0
00a9bade +066 Project1.exe Project1 38 +6 initialization
74e33378 +010 kernel32.dll BaseThreadInitThunkМожет это как-то связано с этой проблемой? Там тоже при уничтожении была ошибка. TsCommonData при уничтожении восстанавливает какие-то свойства родительского объекта. А свойство, в свою очередь, может быть другим уже уничтоженным объектом.
Проблема в обработке сообщения CM_MOUSELEAVE. Не сбрасывается в False значение SkinData.FMouseAbove. И проблема не только с TStringGrid. Для примера выкладываю тестовый проект. Для воспроизведения проблемы надо навести курсор на кнопку или листбокс, чтобы включился glow над ним. И нажать Ctrl+W для скрытия pagecontrol'а. Если glow был на TsBitBtn, то он скрывается, если на TsListBox – нет. При скрытии pagecontrol'а дочернему элементу под курсором приходит сообщение CM_MOUSELEAVE. Далее происходит его обработка:
TsBitBtn:
1. Когда пришло CM_MOUSELEAVE, SkinData.FMouseAbove=True.
2. После обработки сообщения SkinData.FMouseAbove=False. Соответственно, в процессе обработки скрывается glow.
TsListBox:
1. Когда пришло CM_MOUSELEAVE, SkinData.FMouseAbove=True.
2. После обработки сообщения SkinData.FMouseAbove=True. А должно быть по аналогии с первым случаем False.
При этом, если просто водить курсором над TsListBox, то поведение при CM_MOUSELEAVE полностью аналогично поведению TsBitBtn. Вероятно, в коде есть какое-то условие, которое связано с родительским контролом?
Всё это видно при дебаге тестового приложения. Думаю, проблему можно найти сравнивая код CM_MOUSELEAVE у TsBitBtn и другого контрола. Причём другой, похоже, может быть практически любой 😀 Проблему удалось воспроизвести на TsMemo, TsEdit, TsListBox, TsComboBox и т.д.
