PHP DM Gate v0.9 » ошибка OnEndEditLVItem в модуле mckCtrls

QAZ (09.06.14 13:12) [0]

в конце процедуры
TKOLListView.SetupLast
присутствует код

if (lvoEditLabel in Options) and not Assigned( OnEndEditLVItem ) then
begin
//(SL as TFormStringList).OnAdd := nil;
SL.Add( Prefix + AName + '.OnEndEditLVItem := nil;' );
//if KF <> nil then
// (SL as TFormStringList).OnAdd := KF.DoFlushFormCompact;
end;

я не знаю по какой логике вообще работает MSK, но происходит следующее
в коде формы используется событие OnEndEditLVItem, визуально с кодом и тд
в файле Unit1_1.ini МСК сначала генерирует строку
Result.ХХХ.OnEndEditLVItem := Result.ХХХEndEditLVItem;
тобишь присваивает обработчик, а потом через пару строк прочих присваиваний листвиеву впендюривает
Result.ХХХ.OnEndEditLVItem := nil
"благодаря" указанному выше участку кода, в итоге обработчик в КОЛ (WndProcEndLabelEdit) срабатывает, но в событие в форме непередается, в итоге еще и утечки памяти образуются

полное коментирование данного участка решает проблему, побочных эффектов не замечено
опять же повторю - не разбирался в технике работы МСК (нафига присваивать nil когда можно просто вообще ничего не писать), но возможно косяк происходит при использовании директивы UNICODE_CTRLS, проверить не могу, ибо слишком большой откат назад нужно делать

<Цитата>
QAZ (09.06.14 13:41) [1]

не понял...
яж в ветку КОЛ писал, переместите

<Цитата>
Vladimir Kladov © (14.06.14 12:35) [2]

Сайт kolmck.net сейчас недоступен для изменений.
Исправленная версия MCK по адресу http://sourceforge.net/projects/keyobjectslibrary/files/

Либо, заменить в файле mckCtrls.pas строку 7961 (и до конца процедуры TKOLListView.SetupLast):
if (lvoEditLabel in Options) and (TMethod(fOnEndEditLVItem).Code = nil) then
begin
//(SL as TFormStringList).OnAdd := nil;
SL.Add( Prefix + AName + '.OnEndEditLVItem := nil;' );
//if KF <> nil then
// (SL as TFormStringList).OnAdd := KF.DoFlushFormCompact;
end;

<Цитата>
QAZ (15.06.14 18:01) [3]

ясно-понятно
еще в догонку, при использовании UNICODE_CTRLS и запуске из под среды (дельфи7) fastMM детектирует утечки памяти после закрытия приложения
при прямом запуске - все нормально, также не было проблем до включения UNICODE_CTRLS
буквально запуск и сразу закрытие программы, без доп действий
также стоит PAS_VERSION
пример

402C9C [system.pas][FlacU][@GetMem][2439]
403DD0 [system.pas][System][@ObjSetup][8109]
40C27F [KOL.pas][KOL][TObj.Create][16063]
410986 [KOL.pas][KOL][TMenu.FillMenuItems][22989]
4085F5 [fastMM4.pas][FastMM4][UpdateHeaderAndFooterCheckSums][6341]
409603 [fastMM4.pas][FastMM4][DebugGetMem][6867]
409638 [fastMM4.pas][FastMM4][DebugGetMem][6881]
402C9C [system.pas][FlacU][@GetMem][2439]
40C28E [KOL.pas][KOL][TObj.Create][16064]
40FE61 [KOL.pas][KOL][NewMenu][22989]
4436F3 [Unit1_1.inc][Unit1][NewForm1][118]

4097FE [fastMM4.pas][FastMM4][DebugReallocMem][6990]
402CEF [system.pas][FlacU][@ReallocMem][2526]
40C5BC [KOL.pas][KOL][TList.SetCapacity][16525]
40C668 [KOL.pas][KOL][TList.Add][16611]
40C82A [KOL.pas][KOL][TList.Insert][17083]
40C423 [KOL.pas][KOL][TObj.Add2AutoFreeEx][16274]
41E11C [delphicommctrl.inc][KOL][TControl.ProvideUniqueEvents][273]
41E1FC [delphicommctrl.inc][KOL][TControl.Set_TOnEvent][419]
445073 [Unit1_1.inc][Unit1][NewForm1][333]
464DBE [MY33OH_2.inc][MY33OH][MY33OH][5]
76C0338A [BaseThreadInitThunk]

402C9C [system.pas][FlacU][@GetMem][2439]
403DD0 [system.pas][System][@ObjSetup][8109]
40C27F [KOL.pas][KOL][TObj.Create][16063]
40CAB5 [KOL.pas][KOL][_NewGraphicTool][17684]
40CC2D [KOL.pas][KOL][NewFont][17799]
40C862 [KOL.pas][KOL][TList.Insert][17085]
40CD2F [KOL.pas][KOL][TGraphicTool.Assign][17905]
4114FB [KOL.pas][KOL][_NewWindowed][22989]
411821 [KOL.pas][KOL][_NewControl][22989]
41276D [KOL.pas][KOL][NewEditbox][22989]
444718 [Unit1_1.inc][Unit1][NewForm1][260]

402C9C [system.pas][FlacU][@GetMem][2439]
403DD0 [system.pas][System][@ObjSetup][8109]
4159D7 [KOL.pas][KOL][TControl.CreateParented][22989]
4113F3 [KOL.pas][KOL][_NewWindowed][22989]
411821 [KOL.pas][KOL][_NewControl][22989]
41276D [KOL.pas][KOL][NewEditbox][22989]
444718 [Unit1_1.inc][Unit1][NewForm1][260]
464DBE [MY33OH_2.inc][MY33OH][MY33OH][5]
76C0338A [BaseThreadInitThunk]
77459F72 [Unknown function at RtlInitializeExceptionChain]
77459F45 [Unknown function at RtlInitializeExceptionChain]

<Цитата>
Vladimir Kladov © (15.06.14 23:23) [4]

Ничего не могу сказать про FastMM, единственное, что можно проверить напрямую: поставить в сомнительном объекте вывод сообщения в деструкторе. Будет понятно, уничтожается ли объект. В моем тестовом проекте добавление UNICODE_CTRLS ничего не меняет для деструктора ListView: ShowMessage('LV destroyed') продолжает срабатывать.

<Цитата>
QAZ (16.06.14 17:03) [5]

FastMM когда программный косяк пишет конкретно номер строки в коде где что то создалось, а потом не освободилось и дамп памяти
в данном случае идет какой-то бред
да и у WideString внешний менеджер памяти из oleaut32.dll, потому UNICODE_CTRLS вполне могут быть при чем

в принципе глюки при работе из под IDE не смертельны, но возможно за ними скрывается какой-то хитрый баг
потому и предупреждаю

<Цитата>
QAZ (01.07.14 10:59) [6]

> QAZ (16.06.14 17:03) [5]

не, видимо UNICODE_CTRLS не при чем
нашёл тупейший баг у себя - обращение к итему несозданного Тлиста
прикол в том, что винда 7 напрочь игнорирует (возможно благодаря овер 150 обнов безопасности) подобные ошибки, а при тесте на висте или ХР, прога сразу крашица
получается что если из под ИДЕ fastMM детектит утечки, то ошибки реально есть

<Цитата>