Была такая тема, но, видимо кто-то почистил. Делая компонент Menu для пакета Vbs, задумался на пользовательским редактором. Но столкнулся с ограничениями Core. Например, из компонента FormatStr в схему возвращается текст одной строкой. Очень не хватает событий мыши у "визуальных" элементов. Вот пример редактора Меню, но самому не хочется пользоваться таким скромным функционалом. Хотелось чтобы по нажатию кнопки текст вставлялся бы в позицию курсора, но метода Insert пока нет у hcTplMemo, а поместить контекстное меню нет событий от мыши на hcTplMemo.
code_14148.txt

к Memo добавлена точка doSetSelect

Вполне простой и универсальный редактор получается, по-крайней мере, для пакетов Windows и Vbs:
code_14153.txt

было бы конечно совсем классно реализовать редактор не на базе Memo, а на TreeView

Подумаю

сейчас такое не сделать ввиду отсутствия TreeView - просто мысль на будущее

Пытался сделать для секции инишника Edit dll-ку для отрисовки нативных контролов WSO в редакторе форм. Но силёнок не хватило. Но теоритически - можно и внешний редактор форм попытаться сделать.

Ещё одна мысль: может ли пакет Vbs перерасти в помощника HiAsm, каким сейчас являются Core элементы?

хороший вопрос. Думал по этому поводу и пришел пока к таким заключениям:
core элементы в текущем виде не являются удобными с точки зрения их расширяемости. Это значит, что действительно необходимо вводить дополнительное звено ввиде скрипта, который будет генерироваться автоматически после загрузки sha схемы в память(имеются ввиду те sha, которые являются плагинами к среде).

Каким требованиям должен удовлетворять скрипт?
1) для его работы должно хватать установленного в системе или скопированного откуда-то HiAsm
2) он должен поддерживать объявлением объектов окружения, чтобы дать доступ в скрипте к интерфейсным элементам среды и ее параметрам

Какие варианты возможны?
На вскидку: VBS или JS, Gentee, RTCG.
VBS или JS - имеют преимущество в том, что позволяют получить почти полный доступ к функционалу системы. Но не портируемы совершенно.
Gentee - компактный, компилируемый в память и так же имеет возможность обращаться к сервису системы. Портируемость теоритическая, систаксис не привычный.
RTCG(в разработке пока еще) - портируемость полная, синтаксис аналогичен FTCG, есть возможность интеграции элемента пакета с плагином среды в одном файле. Но не дает возможности обращаться к функциям ОС без их предварительного описания. Скорость работы ниже чем у всех остальных.

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

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

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

Dilma, Вам должно подойти для этих целей. http://www.hiasm.com/forum_serv.php?q=56&id=334

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

FBSL_ExecuteScriptBuffer
FBSL_ExecuteScriptFile
FBSL_GetReturnValue

раздел FBSL.DLL

я вот это имел ввиду

Это требование означает, что язык должен поддерживать возможность объявить свои собственные объекты, переменные и методы.

Dilma, можно ли на narod.ru положить вот это?