Предлагаю вниманию альфа релиз компонента удаленного доступа к контролам низкого уровня, те от менеджера к контролу, а не от контрола к менеджеру. Те менеджера можно поместить в контейнер и из него иметь доступ к любому контролу верхнего уровня (по крайней мере, на уровне почти всех доступных методов WinControls). В архив входит необходимая версия Win.pas, которую надо заменить (сохранив предыдущую, на всякий случай, для отката). Функционал Win.pas не изменен (в сравнении со штатным с SVN), изменена только организация выдачи событий на новую, которая позволяет выдавать события удаленным менеджерам через стандартную очередь сообщений (предложения от andrestudio по синхронизации захвата событий тут не прокатывают, привязку к его контролам надо смотреть отдельно, но тк у меня их нет, я это сделать не смогу, да у него там и Win.pas свой собственный). В архиве два примера, один из них показывает удаленную и основную отрисовку на контексте формы, другой использует штатный пример из папки примеров, но в нем сокращено внешнее количество связей с контейнерами (вот, кстати, именно возросшее число связей в больших проектах меня и сподвигнуло к созданию компонента, тк надоело созерцать лес связей) за счет применения компонента (обновления c SVN приветствуются, тк я изменил обработчик сообщений в MST_UseEditCtrl, но со старым тоже должно работать, тк этот компонент не контрол). Это экспериментальный компонент, ничего не могу сказать про необходимость его использования и нужности его применения. Но компонент уже создан и там отрабатывались некоторые концепции удаленного доступа к событиям и методам классов, а также удаленная синхронизация событий к нескольким компонентам. Если данный компонента вас устроит, и вы увидите в нем надобность, то, возможно, после тестирования я его добавлю.

Внимание! В виду того, что разработка продолжилась дальше и затронула еще множество разных важных модулей, то по завершению разработки здесь будет выложена ссылка на патч для тестирования. После тестирования все это будет добавлено на SVN.

Ссылка на основной патч -- Patch_17-01-2023.zip

Ссылка на облачное хранилище актуальной версии патча -- Actual Patch
На всякий случай привожу ссылку на зеркало штатного SVN, мало ли что может случится -- SVN_Delphi

Редактировалось 37 раз(а), последний 2023-03-28 15:17:41

nesco, вот здесь https://forum.hiasm.com/post/310226 я что то так ничего вразумительного и не услышал. Впрочем вообще ничего не услышал.
По поводу RemoteAccessManager ничего сказать не могу кроме шедевра в win.pas

if Msg.message = US_KEYUP then
...

А что дальше то в этом кейсе продолжить нельзя было

p.s правда когда пишешь по ночам и не такие зигзаги выписывать можно...

Ты думаешь я не пробовал туда Case воткнуть, мне он тоже больше нравится, чем if? Но, увы, Case не поддерживает переменные (Error: Constant expression expected), а US_KEYUP не константа.

--- Добавлено в 2022-01-12 13:28:40


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

Редактировалось 7 раз(а), последний 2022-01-12 13:33:41

ну хорошо, чем WM_USER+??? не нравится

ну либо так должно проканать


понятно что ничего не понятно

Для этого достаточно в менеджере вести список присоединенных клиентов (Childrens[I]). А для этого когда клиент получает указатель менеджера, то передавать ему не кастомную record, заполняемую всеми требуемыми клиенту данными (обычно и так содержащимися в менеджере), а Self менеджера, у которого кроме прочего клиент может вызвать метод типа "RegisterClient(<Self клиента>)". Кроме того, благодаря этому менеджеры могут что-либо сообщать клиенту (поскольку имеют список клиентов и знают возможности клиентов). Например, компоненты-менеджеры BASS каналов сейчас никак не могут запросить у клиентов свойства канала (типа громкости) при его пересоздании (открытии нового файла).
Для компонентов таблиц я поэкспериментировал - тоже когда столкнулся с MST_UseEditCtrl: /post/288689.

Да я об этом тоже думал, но остановился на решении отдать назначение сообщений самой системе, пусть она сама решает, какой код отдать сейчас конкретному сообщению. И че все прикопались к этому Case?

Я тоже думал об этом решении, но все опять сведется принудительному циклу выдачи сообщений всем клиентам из списка. А зачем выдавать сообщение тому, кто в этом не нуждается, это если вести список всех клиентов? В моем же решении, я выдаю сообщение, и у кого есть обработчик, тот на него и среагирует, включая основной модуль, этим достигается синхронизация только с нужными клиентами. И все это делается на уровне системы.

В результате, я вообще переписал ему обработчик.

--- Добавлено в 2022-01-12 15:08:43


Я столкнулся с понятием "как надо" в результате танцев с бубнами вокруг OnPaint, его надо строго инициализировать как в основном модуле и только один раз при подключении точек, если точка подключена, больше инициализировать контекст отрисовки ни в коем случае нельзя. Вот я туда и ввел переменную уже проведенной инициализации -- а проверка назначения OnPaint через Assigned, выдавала, что точка занята, а на самом деле инициализацию контекста никто не проводил.

--- Добавлено в 2022-01-12 15:18:48


В менеджерах нижнего уровня можно перехватить класс самого клиента и управлять его параметрами напрямую, кстати, это у меня и реализовано. Можно ли такое замутить для менеджеров верхнего уровня, тут надо подумать.

Редактировалось 4 раз(а), последний 2022-01-12 15:18:48

Без проблем. Вместо RegisterClient() в менеджере предлагаешь RegisterMsgListener() - кто хочет, тот и подключается. Кстати, те мои эксперименты как раз для обработки сообщений и делались. С возможностью запретить дальнейшую обработку сообщения как менеджером, так и следующими клиентами.

Тема эта интересная, но не потребует ли это сейчас переделку всех менеджеров, что очень не хотелось бы?

--- Добавлено в 2022-01-12 17:10:45

Посмотрел твой код (я его и раньше смотрел, но благополучно отложил на полочку и забыл, каюсь). Но это немного не то, что хотелось бы. А вот насчет твоего волнения насчет AttachProc, то я тоже столкнулся с такой дилеммой -- а почему, собственно, AttachProc, почему не _onMessage? В результате чего благополучно переписал обработчик hiMST_UseEditCtrl на применение _onMessage. Единственное преимущество AttachProc, это то, что можно прицепить несколько обработчиков.

Редактировалось 2 раз(а), последний 2022-01-12 17:13:49

nesco, с типизированными константами прокатило
Что по мне так хотя бы начать с того что уже давно нужно сделать по человечески
1) Добавить моржу для контейнеров
2) Anchors для контролов
3) События начала и окончания изменения размера

Не, не прокатило, вроде как константа, а для Case оказалось, что нет. Плюнул и сделал константы на базе WM_APP, мелкие именно эту группу рекомендуют использовать для неизвестных заранее сообщений, и если что-то хотите приколупать к заранее неизвестному коду, где уже может использоваться WM_USER. WM_USER уже используется у нас многими модулями, а вот WM_APP нигде.

Ни хрена не понял, но очень интересно. Вот только в KOL лезть не будем. У тебя какие-либо более интересные объяснения есть по пунктам. И если это затрагивает Win, то можно попытаться добавить, пока, правда, не очень понятно что. Короче, нужны хоть какие-то наработки, что бы понять, что делать, и как это может повлиять на то, что уже у нас есть.

Редактировалось 2 раз(а), последний 2022-01-12 18:38:44

В Synchronize используется. Дай поиск по файлам. Предлагаю список своих сообщений WM_APP держать в Share.pas с комментариями где используется и для чего. Тогда не надо будет искать.

Если не замахиваться на общий класс-предок для всех менеджеров - то нет. Начать можно только в MTStrTbl и ее клиентах (которым надо).

Редактировалось 1 раз(а), последний 2022-01-12 19:10:08

Согласен. У меня тоже кое где используется.
Для маржи в KOL всё есть, остальное в win.pas
Нормальный Anchors будет только после пункта №3, мне тоже придётся всё переделать.

Во, хорошо, что подсказали. Дал смещение на 1000, на всякий случай. Перевел все в Share, и для Synchronize туда же.

Что это вообще за зверь? На что он вообще похож? Где на него можно посмотреть подробнее?

А что вообще должен делать этот пункт, на что он должен реагировать и как?

Редактировалось 4 раз(а), последний 2022-01-12 20:09:51

nesco, мне уже нечего добавить, к Вам как достучатся до небес!
Мне это нафиг не нужно, у меня всё встроено
Margin это то что уже со времён KOL для HiAsmhttps://forum.hiasm.com/topic/68003
Пункт №3

Остальное гугл.

p.s У Галкова пиктограммы на кнопках рисоваться не будут никогда нормально потому как он когда то Рихтора прочитал, ну надо же почему тогда они у Кладова рисуются Вот в этом весь и HiAsm/

Так ты сам-то сделал хоть какой-то Anchors или только в проекте?