Ничего в глаза не бросается из-за чего вылетает ошибка при

тыканьи мышкой в ячейку грида на 64 битах D11? На 32 работает
Не знаю как подступиться
procedure TdxInplaceEdit.DefaultHandler(var Message);
begin
if not IsEditClass then
case TMessage(Message).Msg of
// TODO: test + non Edit
WM_LBUTTONDOWN, WM_RBUTTONDOWN, WM_MBUTTONDOWN:
if not (csDesigning in ComponentState) and (GetFocus <> Handle){not Focused} then
Windows.SetFocus(Handle);
end;
// if IsEditClass and (csDestroying in ComponentState) then Exit;
inherited;
end;

ну для начала проверь типы (их объявление) это dx какой версии?

вообще для x64 можно потеребонькать встроенный менеджер памяти чтоб он возвращал указатели уже за пределами 4Гб. пихнуть что нибудь типа x = 6; var l: array of Pointer; i: Integer; begin SetLength(l, 1024 * 1024); for i := Low(l) to High(l) do GetMem(l[i], 1024 * x); в инициализацию самого первого юнита. тогда ошибки распределения памяти будут сразу видны rangecheckerror‘aми. а не рандомными крешами ну и стандартно проверять места места с кастом указателей и маскированием Integer( Cardinal( Longint( Longword( Long( итд

а стек та где?

Спасибо. Что-то глюканула. Похоже это оно. Ща разберусь with Params do begin System.Move(S[1], WinClassName[0], Length(S)); WinClassName[Length(S)] := #0; end;

fastmm4 и так это делает. Первая попавшая под руку аллокация $7FF4FDB3BD40

Оказалось хуже, чем думала. Редактором ячейки может быть разный класс RichEdit ('RICHEDIT', 'RICHEDIT20W', 'RICHEDIT50W' или какой-то другой), который берется из разных dll ('Riched32.dll', 'Riched20.dll', 'Msftedit.dll') Вроде все перепробовала для 64, либо ломается, либо ничего не вводит. Ну надо же было именно это поле потянуть, придумщики - капец

Ну кто так пишет! То longint, то integer, то правильный LPARAM. Исправила на него все и заработало procedure TdxInplaceTextEdit.Deselect; begin // SendMessage(Handle, EM_SETSEL, $7FFFFFFF, Longint($FFFFFFFF)); SendMessage(Handle, EM_SETSEL, $7FFFFFFF, LPARAM($FFFFFFFF)); end; procedure TdxInplaceTextEdit.SetSelTextBuf(Buffer: PChar); begin // SendMessage(Handle, EM_REPLACESEL, 0, LongInt(Buffer)); SendMessage(Handle, EM_REPLACESEL, 0, LPARAM(Buffer)); end;

Как-то был эпизод в "карьере" - пришлось один из проектов с "предысторией" переводить с D7 на D10. С DevExpress-ом было больнее всего. 2-3 недели активной ... с написанием собственных утилит только для того, чтобы скомпилилось и не крашилось при открытии основных форм. Проект только форм несколько тысяч, а тимлид на вопрос может это уже не все нужно ответил, что ни кто из ныне здравствующих не понимает что уже не актуально в проекте и что можно выкинуть (не портировать). Итого: DevExpress это конечно круто, но с массой своих "особенностей".

Я версию dx7 привела к тому, что она заработала на D11. Поэтому формы править не пришлось, иначе бы на них погибла)

А потом как с этим жить планируете при появлении новых версий DevExpress? Всю жизнь на dx7 (пусть даже на поправленных) грустно как-то.

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

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

править чужое, а потом таскать его с собой? чтото пошло не так

Не у всех есть возможность и знания писать все свое, кому то придется таскать чужое :)

Тут сейчас люди проконсультировать просили меня по поводу портирования ихнего софта, у них в проекте тот самый devexpress везде понатыкан где надо и где не надо. Че с ними делать хрен его знает, смотреть надо.

Так давно появились CX, будто специальное не совместимое издевательство над народом) Тут не знаешь, что через полгода будет. На какую операционку кинут. А мне ещё два сервиса перевести на 64 бита и один немаленький проект, которые тоже пока на D7

если хватает, почему нет

1. Там попа будет еще и в том, что не все типы, контролы, наименования пропертей, обработчиков и много чего еще дожили там до текущего момента в принципе. 2. Единственный вариант который я посчитал для себя приемлемым - это писать свою утилиту, которая хранила вложенные "иерархические" шаблоны замен в JSON-е, перебирала все pas и dfm и правила их с учетом кучи доп. параметров. Все это на регулярках. Принцип: нашли затык - добавили в JSON новый шаблон(ы) - потенциально созданный шаблон поправил кучу аналогичных моментов. и т.д. итерационно. 3. Если/когда удалось из 4 букв (А,Ж,О,П) выложить слово СЧАСТЬЕ - т.е. проект даже скомпилился, то начинается следующий интересный не автоматизируемый этап - понять что хотели написать разрабы предыдущих N поколений и добиться, что бы как минимум формы не крашились и не уходили в AV при открытии. 4. Отдавать тестерам и ...

Одно из модных нововведений заметила в разных компонентах: стали вместо свойства множества типа options бить на отдельные булеан свойства. Веселуха такое править, хорошо, если из dfm можно убрать и ифдефами обложить

Понятно. Ну ещё можно попробовать изобразить затычку из стандартных компонентов. Посмотрим вобщем