Библиотека QCtrls.dll

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Программирование на языке Lua
Страницы: 1 2 След.
RSS
Библиотека QCtrls.dll
 
#1
12.02.2015 04:54:46
В связи с тем, что секция экспорта в библиотеке пользовательских контролов имеет открытый интерфейс, могу ли я, сделав к ней QLUA-бинд использовать её в своих программах на qlua?
 
 
#2
12.02.2015 05:41:34
Цитата
sam063rus пишет:
В связи с тем, что секция экспорта в библиотеке пользовательских контролов имеет открытый интерфейс, могу ли я, сделав к ней QLUA-бинд использовать её в своих программах на qlua?
нет, не можете.
 
 
#3
12.02.2015 05:47:45
ну тогда сделайте их доступными из QLUA сами. и сделайте уже нормальный бинд вашего qtable. пример того, как обходятся в CryEngine без метатаблиц Вам уже давали.
 
 
#4
12.02.2015 05:52:21
Цитата
sam063rus пишет:
ну тогда сделайте их доступными из QLUA сами. и сделайте уже нормальный бинд вашего qtable. пример того, как обходятся в CryEngine без метатаблиц Вам уже давали.
А что сейчас не устраивает в функциях работы с таблицами? Сразу повторюсь - завернуть эти функции в "класс" не сложно средствами самого Lua, тем более что пример как это можно сделать у нас есть.
Тот пример что Вы прислали - это просто пример реализации наследования от базового класса. Для этого надо сначала определить сам базовый класс, о чем я и просил Вас. Напишите в свободной форме что вы хотите получить.
 
 
#5
12.02.2015 05:52:22
да что CryEngine? таже vclua. там простой и понятный интерфейс без всяких врапперов (просто разработчики изначально потрудились, а не повесили всё на пользователей). насчёт её глючности - оставим за скобками. т.к. это ещё, как посмотреть.
 
 
#6
12.02.2015 05:54:09
я напишу вам, как-раз над этим работаю. просто если всё писать - потомы вы же меня и обвините в раскрытии своих секретов. потому что мои предложения некоторые УЖЕ у вас реализованы, но не раскрыты
 
 
#7
12.02.2015 06:03:11
Цитата
Michael Bulychev пишет:
завернуть эти функции в "класс" не сложно средствами самого Lua, тем более что пример как это можно сделать у нас есть.
вот в том-то и проблема: и таскать вместе с основным скриптом кучу врапперов. а если объектов будет окло 200-300 то, это я вообще молчу.
 
 
#8
12.02.2015 06:04:03
имеется ввиду классов, конечно, а не объектов
 
 
#9
12.02.2015 07:09:15
кстати, вот актуальный мини-срач по схожей теме: http://www.gamedev.ru/code/forum/?id=147765
так... для общего, как говорится.
 
 
#10
12.02.2015 07:12:50
Цитата
sam063rus пишет:
кстати, вот актуальный мини-срач по схожей теме: http://www.gamedev.ru/code/forum/?id=147765
так... для общего, как говорится.
Попробуйте донести основную мысль этой ветки. Ничего нового я там не обнаружил.
 
 
#11
12.02.2015 07:28:07
суть в том, чтоб скрывать в C++ коде реализацию класса, а в LUA - дёргать только функции, позволяющие создать объект, настроить его поля, вызвать некоторые методы. Ваша, в данном случае задача: реализовать развёрнутую в с++ структуру классов графических контролов, избавив пользователя от таскания многочисленных врапперов и метатаблиц в своих проектах. также, обеспечить корректное взаимодействие на уровне потоков. для этого у вас есть все ресурсы в отличии от нас - т.к. мы не знаем ни контекстов плагинов, ни других внутренних структур. Это только, что касается qctrls.dll. в остальных темах - у меня к вам другие вопросы. p.s. Нам не надо надо LUA или средствами C API проектировать/создавать/описывать новые классы - нам нужны простые функции доступа и коллбеки к ним. какие классы, какая структура/иерархия нам нужна - на том уровне, который мне доступен, постараюсь вам нарисовать. но вам это и самим должно быть хорошо известно - ведь они у вас уже есть - просто надо их больше сделать доступными на QLUA. Пока я вижу, что у вас более менее детально реализован класс qtable. НО!!! вы совершенно (прошу меня извинить конечно) наплевали на его биндинг, вы просто представили его, как некую dll, к которой можно с помощью опять же лишнего QLUA-враппера иметь доступ. А почему бы изначально не дать нам пользовать готовыми абстракциями на манер message() или, тот же самый combobox, если смотреть изнутри.
 
 
#12
12.02.2015 07:29:28
Цитата
Michael Bulychev пишет:
Ничего нового я там не обнаружил.
дык ничего нового-то и нет. надо просто сделать свою работу до конца и вам все наконец скажут спасибо.
 
 
#13
12.02.2015 07:52:50
то есть, если у нас уже есть в квике qtable нам, как трейдерам, проще было бы обращаться к нему, как-то вот так:

Код
local qtHandle = 0
 qtHandle = CreateEntityByName("QTABLE")

qtHandle.qtprop = {
Caption = "",
Rows = 2,
Col = 2
}
 
 
#14
12.02.2015 08:38:02
Цитата
sam063rus пишет:
то есть, если у нас уже есть в квике qtable нам, как трейдерам, проще было бы обращаться к нему, как-то вот так:
Код
 local qtHandle = 0
 qtHandle = CreateEntityByName("QTABLE")

qtHandle.qtprop = {
Caption = "",
Rows = 2,
Col = 2
}
Код
QTable = {}
QTable.property = {
                    x=0, 
                    y=0, 
                    width=100, 
                    height=100, 
                    caption ="QLua Table", 
           t_id=-1
                   }
QTable.mt = {} 
QTable.mt.__index = function(table, key)
  return QTable.property[key]
 end
QTable.mt.__newindex = function(table, key, value)
  QTable.property[key]=value -- или вызывать функцию для таблицы
 end 
...
 qt = QTable.new {Caption="New Table"}
Ну и далее в том же стиле...

Я просто хочу показать, что сделать ОО интефейс к существующим функциям задача не хитрая. Причем нет разницы где это делать - в скрипте на Lua или в qlua.dll. API для этого используется одно и тоже.
Вся проблема в том, что никто внятно не может рассказать какими объектами хочется оперировать, какими свойствами они должны обладать, какие интерфейсы предоставлять, как взаимодействовать друг с другом и т.п.
 
 
#15
12.02.2015 09:02:09
Цитата
нет разницы где это делать - в скрипте на Lua или в qlua.dll.
это для Вас, Михаил, нет разницы, а нам, как трейдерам - это принципиально. Нам весь этот "мусор" с метатаблицами в программах абсолютно не нужен. поэтому. имеет очень большой смысл спрятать вам от нас его в своей qlua.dll вместе с реализацией других методов.

Цитата
Вся проблема в том, что никто внятно не может рассказать какими объектами хочется оперировать
Будут вам и свойства и классы и интерфейсы - просто Вы просите меня написать вам по сути, иерархию vcl "в моём представлении". Чем я и занимаюсь. Но, как уже писал, Вы это можете сделать и сами. vclua или, если уж, как дефакто стандарт: дельфовая vcl. Можете обойтись и своей реализацией: qctrls.dll и qlist.dll (про qchart пока молчу, но это пока). все поля и методы и события - там в них всё у вас описано - так выведете же их наконец, наружу через qlua и дайте нам ими пользоваться, КАК УЖЕ НЕ РАЗ ПОВТОРЯЛ: БЕЗ МЕТАТАБЛИЦ.

p.s. насчёт интерфейсов: я вам их опишу в своём понимании.
 
 
#16
12.02.2015 10:41:13
Цитата
sam063rus пишет:
Цитата
нет разницы где это делать - в скрипте на Lua или в qlua.dll.
это для Вас, Михаил, нет разницы, а нам, как трейдерам - это принципиально. Нам весь этот "мусор" с метатаблицами в программах абсолютно не нужен. поэтому. имеет очень большой смысл спрятать вам от нас его в своей qlua.dll вместе с реализацией других методов.
Я позволю себе встрять и высказать своё мнение.

Чем более низкоуровневые средства мне доступны, тем больше возможностей для меня сделать на их основе собственные абстракции. Удобные, понятные и приятные именно мне.

Совершенно необязательно, что мне нравится тот стиль, который кажется правильным Михаилу Булычеву или sam063rus.

Поэтому я никак не приветствую навязывание мне каких-то готовых классов с неизбежными ограничениями: на qpile мы уже писали.

Касаемо метатаблиц. Нам (мне) мусор с метатаблицами очень нужен.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
 
#17
12.02.2015 11:22:30
Цитата
s_mike@rambler.ru пишет:
я никак не приветствую навязывание мне каких-то готовых классов с неизбежными ограничениями:
нет проблем: пишите на ассемблере:)) полная свобода действий.

Цитата
s_mike@rambler.ru пишет:
на qpile мы уже писали.
я думаю, что с тупайлом сравнивать пусть даже и qlua - совсем неуместно.

p.s.
Цитата
s_mike@rambler.ru пишет:
с неизбежными ограничениями:
а вообще-то никто и не говорил про ограничения, а наоборот. к тому же qlua развивается именно по экстенсивной модели и ничто, что до этого работало не отбрасывается.

Цитата
s_mike@rambler.ru пишет:
Касаемо метатаблиц. Нам (мне) мусор с метатаблицами очень нужен.
да не волнуйтесь вы так - чтоб он исчез - потребовалось бы переписать саму LUA, что естественно делать никто не станет. Тут разговор о высокоуровневой надстройке к qlua и большей открытости её GUI.
 
 
#18
12.02.2015 11:36:44
s_mike

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

если превратить реализацию qlua в сплошные метатаблицы то, кто по вашему сможет ей пользоваться? для кого она? кто целевая аудитория? ответ: только роботорговцы, которые изначально опытней рядовых трейдеров и программисты.
напрашивается тогда вопрос: а кому это надо? мои предложения направлены на соблюдение интересов основной массы пользователей - трейдеров.
а если роботорговцы так хорошо разбираются то, что мешает им создать свою ТС и устанавливать свои правила? (извиняюсь если чем обидел)
 
 
#19
12.02.2015 15:48:25
Почему-то полностью согласен с sam063rus ,
за исключением его пристрастия  к слову "дерьмо".  
 
 
#20
12.02.2015 16:39:42
Цитата
Николай Камынин пишет:
за исключением его пристрастияк слову "дерьмо".
это ни к кому конкретно не относится. равно, как и я не призываю к тотальному отказу от LUA. просто всё хорошо к месту.
 
 
#21
13.02.2015 20:32:38
vclua использует исключительно везде метатаблицы.
Что будем с этим делать?
 
 
#22
14.02.2015 00:28:44
одно дело когда они "внутри" в C-библиотеке и другое дело когда "наружу" в виде всяких врапперов в коде LUA-скрипта.
 
 
#23
14.02.2015 07:28:27
Но ведь это исключительно ваше личное эстетическое восприятие, не более того.
Ни какого смыслового смысла это не дает: ни в смысле быстродействия, ни в смысле работы Луа кучи.
Соответственно если есть какой-то враппер, который делает желаемый вами интерфейс удовлетворяющий ваши эстетические чувства - то и пусть себе лежит. Просто не надо в него заглядывать, если если кто-то стесняется при виде метатаблиц. Ведь результат во всех смыслах - совершенно идентичен.
 
 
#24
14.02.2015 08:33:31
swerg,
я, конечно, понимаю, что Вы более опытный в метатаблицах, их метаметодах, а самое главное, как это всё реализовать (забиндить) на C++ или в том же Лазарусе. Но я не думаю, что таких большинство. Суть разговора в том, что вот у нас есть qctrls.dll и есть пример обёртки на QLUA, как с ней работать, вопрос: нахрена мне, как в первую очередь, трейдеру вся эти "танцы" когда я могу по примеру всё той же vclua в достаточно в простой форме обратиться к таблице, создать/отредактировать/удалить её. и мне даже не понадобиться вникать в то, как реализовано это, главное, чтоб оно БЫЛО реализовано. Или, другой пример, есть функция QLUA message, которая на самом деле combobox с жёстко заданными свойствами (это другой пример крайности). Другая выгода: т.к. это всё будет реализовано не нами, а разработчиками (у которых по определению больше информации) то, это отчасти упростит ранее выявленные проблемы с многопоточностью.
 
 
#25
14.02.2015 08:49:48
таким образом, разработчики, вместо того, чтоб добавлять в qlua вот эти вот, по сути, промежуточные функции:

могли бы изначально вписать враппер "quik_table_wrapper" в QLUA, а мы, как пользователи, получили бы удобный, ещё один НАТИВНЫЙ класс в QLUA.
 
 
#26
14.02.2015 08:56:35
и так с остальными контролами. потому как если разработчики решат вдруг добавить парочку деклассированных то, это выльется в штук 20 функций для работы с этими "деклассированными контролами" и их описаний в хелпе. в итоге, справка по QLUA, равно как и код на QLUA будет стремиться к роману "Война и мир" по объёму.
 
 
#27
14.02.2015 09:16:31
С другой стороны, имея AllocTable, можно воспользоваться полу-хакерским методом и создать вместо таблицы какую-нибудь тоже НАТИВНУЮ кнопку или вообще другой контрол средствами Windows API, которая будет работать в окне квика. Потому что, эта функция по сути, скорей всего возвращает хендл окна. Насчёт этого, могу, конечно, ошибаться, потому как об истинной реализации могу только догадываться, читая между строк примеры в хелпе QLUA. Но, честно говоря, не хотелось бы до этого опускаться.
 
 
#28
14.02.2015 09:19:45
Цитата
sam063rus пишет:
С другой стороны, имея AllocTable, можно воспользоваться полу-хакерским методом и создать вместо таблицы какую-нибудь тоже НАТИВНУЮ кнопку или вообще другой контрол средствами Windows API, которая будет работать в окне квика.
под "средствами Windows API" имелось ввиду, конечно, состряпать dll, аналог vclua.
 
 
#29
14.02.2015 16:04:01
В одной русской сказке, под названием "по щучьему велению" сидел Иван на печи и мечтал

В другом классическом произведении есть тост "Хочу чтобы Все"
---------------------------------------------
мечтать оно конечно не вредно, но и бесполезно.
-------------------------------
"С одной стороны....С другой стороны" -ничего не напоминает ?
( типа песню из одного классического фильма)
 
 
#30
14.02.2015 16:40:54
я так понимаю. это всё лирика с Вашей стороны...
 
 
#31
14.02.2015 16:42:57
лучше б, что-нибудь по делу написал.
 
 
#32
17.02.2015 11:59:05
Цитата
Michael Bulychev пишет:
Тот пример что Вы прислали - это просто пример реализации наследования от базового класса. Для этого надо сначала определить сам базовый класс, о чем я и просил Вас. Напишите в свободной форме что вы хотите получить.
Например, так:

Код
QControls = class(TComponent) //что такое tcomponent - см. в Delphi VCL

и пошло
...
и поехало
...
end;
Отсюда, имеем: QControls - базовый класс для всех визуальных контролов, которые нам так сильно нужны. Либо, давайте нам хендл окна вкладок квика, относительно которого мы будем отталкиваться, строя сами окна-контролы.
Далее, каждый скрипт имеет базовым: класс QScript

Код
QScript = class(QObject or QPlugin)

пока думаю над этим
...
end;
Сейчас же, Вы заставляете нас, по сути, писать свою реализацию vcl (не путать с qvclua или vclua), хотя просто могли сделать её общедоступной. Чтоб нам стабильно использовать ту "vclua", которая гуляет в интернете - надо переписать дельфовую или лазаровскую vcl (lcl). Что весьма нетривиально, т.к. придётся отказываться от многих корневых классов и переписывать их, т.к. они заточены на взаимодействие с приложением и от него они отталкиваются, а не с плагином.
 
 
#33
17.02.2015 12:10:43
Цитата
sam063rus пишет:
хендл окна вкладок квика, относительно которого мы будем отталкиваться, строя сами окна-контролы.
а активная вкладка в данном случае - будет аналогом для нас "QForm" - контейнера для наших контролов
 
 
#34
17.02.2015 12:21:41
немного дополним:

Код
 QScript = class(QObject or QPlugin)

пока думаю над этим
...

class(QException)//взаимодействет, по крайней мере с функцией pcall LUAVM

...

 end;
 
 
#35
17.02.2015 13:32:08
полагаю, всем нас...ть
 
 
#36
24.05.2015 18:41:39
Цитата
Michael Bulychev пишет:
Вся проблема в том, что никто внятно не может рассказать какими объектами хочется оперировать, какими свойствами они должны обладать, какие интерфейсы предоставлять, как взаимодействовать друг с другом и т.п.
Михаил, Вы почему-то бытро успокоились и забросили тему... :)))

Вы так просили, чтоб Вам всё объяснили, а в ответ - тишина...
Ну ладно, не устраивает класс QScript и описанное далее то, хоть сделайте базовым класс QForm - так хоть можно будет на вполне законных основаниях от чего-то отталкиваться. Объясню, а то опять начнётся "троллинг": мне (нам) нужен этот класс для того, чтоб назначить его "родительским" и иметь возможность "ляпать" на него свои контролы, которые будут выглядеть вполне нативными и будут привязаны через него к отображению на вкладках квика, а не как сейчас (как отдельное приложение). Сделать это для Вас - не составит уймы времени, а польза будет большой.
Кроме того, Вам явно задавали вопрос: почему Вы прячете "хендл" окна от таблиц - на что ты Вы опять уклонились от ответов. Я просил это для того, что если уж нет возможности привязаться к вкладке квика то, хотя бы иметь возможность создать свой контрол на базе таблицы (созданной стандартными средствами QLUA QTable).

Прошу детально (не ограничиваясь парой фраз) уже наконец объясниться.

---------------------------------
(to "всяким роботорговцам-умникам, тролльте у себя в "песочнице" и не засоряйте тему")
 
 
#37
25.05.2015 12:36:28
Добрый день.
Какой хендл Вы хотите получить? Дочернего окна или непосредственно таблицы?
И что потом Вы собираетесь с ним делать?
 
 
#38
25.05.2015 13:37:20
есть функция winAPI: CreateWindow с помощью которой я планирую создать базовый оконный класс. У ней есть параметр:
HWND hWndParent, // дескриптор родительского или окна владельца

Цитата
Michael Bulychev пишет:
или непосредственно таблицы?
раз в квике в QLUA "окном в квик" является регистрация таблицы (например, QTable) - то, стало быть её хендл

Цитата
Michael Bulychev пишет:
И что потом Вы собираетесь с ним делать?
как уже много раз писал до этого (в разных вариациях) - Михаил, мне (нам) нужен базовый оконный класс, который будет иметь возможность однозначной ассоциации с вкладкой квика и благодаря которому можно будет в случае чего переносить "окошки" моих контролов на другие вкладки (привязывать). То есть, если Вы реализуете вышеописанное то, у пользователей появится возможность писать как бы нативные контролы. т.е. по сути - дочерние окна квика.

я, конечно понимаю, что для вас, (как для программиста, по определению обладающего большей информацией о квике и о том, как это можно было правильно реализовать и уж тем более спросить на форуме) многое описанное выше кажется абсурдным. НО!!!
мы всего лишь пользователи и нас тоже можно понять. и к тому же, спустя километры "писанины" - процесс - так и не сдвинулся с места.
 
 
#39
25.05.2015 13:44:18
подытожив вышесказанное, Михаил, прошу:
  • Вы просили ответить, какой класс сделать базовым. - Сделайте базовым любой оконный класс, например QTable с параметрами описанными выше. И мы сможем писать полноценные контролы в квике на QLUA
  • либо, если Вы знаете более правильный и элегантный способ, как это сделать - приведите код (базового класса) на Delphi или VC++
 
 
#40
25.05.2015 13:48:16
Если я правильно понял, то пока речь идет только о возможности управлять закладками и перемещать окно на нужную?
 
 
#41
25.05.2015 13:49:10
в общем пользователям нужна возможность создавать в квике дочерние окна.

насколько я понял - только так можно обеспечить привязку к вкладкам.
 
 
#42
25.05.2015 13:50:54
sam063rus,почему вы свои пожелания постоянно выдаёте за требования масс? Как правило они слишком "с подвыпердотом" и подобные обращения от других не встречал...Возможно я чего-то не знаю, и мне отвечать не надо.
 
 
#43
25.05.2015 14:04:32
Цитата
сергей пишет:
sam063rus ,почему вы свои пожелания постоянно выдаёте за требования масс? Как правило они слишком "с подвыпердотом" и подобные обращения от других не встречал...Возможно я чего-то не знаю, и мне отвечать не надо.
возможно Вам пора перестать засорять мои топики своими суждениями. Или Ваша задача "убить" любую мою тему?
 
 
#44
26.05.2015 20:05:51
Michael Bulychev,

Вы так и не ответили на вопрос #39 https://forum.quik.ru/messages/forum10/message4923/topic143/#message4923

Суть описанного выше - как и комментировалось до этого в следующем:
Вы создаёте класс-контейнер (аналог формы в Delphi), имеющий свою оконную функцию, зарегистрированный класс, которые пользователь потом сможет назначить "родительским" и наследовать от него свои контролы.

Почему это не можем сделать за Вас - мы (пользователи)? Ответ: потому что, также хотелось бы иметь возможность полной привязки к вкладкам квика, переназначать их, сохранять местоположение в файле info.wnd, как это делается со штатными окнами. То есть, по сути, нужен MDI-оконный базовый класс. (если можно так выразиться)
 
 
#45
27.05.2015 05:12:05
Пожелание такого рода у нас есть и мы думаем над их реализцией.
Сохранение в wnd-файл таких окон скорее всего сделать не получится по разным причинам.
 
 
#46
27.05.2015 12:15:07
Цитата
Michael Bulychev пишет:
Сохранение в wnd-файл таких окон скорее всего сделать не получится по разным причинам.
согласен - это нелегко.
 
 
#47
27.05.2015 13:04:29
в качестве альтернативы технической реализации - можно предложить создать в классе контекста скрипта - список окон с параметрами размера и положения. Далее, сохранить параметры из него в info.wnd. Потом, при старте скрипта - восстанавливать эти параметры. А чтоб гарантированно знать, что именно (какие окна и параметры) сохранять - пользователю можно подсунуть в скрипте какую-нибудь новую функцию (чтоб он сам заполнил эти параметры, по кр. мере названия пользовательских окон).

Но, как говорится, вам виднее.
 
 
#48
13.06.2015 06:54:45
Цитата
Michael Bulychev пишет:
Пожелание такого рода у нас есть и мы думаем над их реализцией.
а пока Вы думаете над их реализацией - было бы неплохо уже с чего-то начать: к примеру, если бы Вы сделали функцию в QLUA, возвращающую хендл текущей вкладки - то это бы избавило от массы проблем.
функцию можно назвать например так: getActiveTabbed(). В качестве результата - можно возвращать либо таблицу с дополнительной информацией (например, название вкладки, хендл её окна и т. п.) либо же просто хендл.
Хранить параметры и доставать их можно через стандартный механизм хранения таких вещей, как: LightUserData.

Сделать это для Вас - не составит великого труда (займёт не больше часа), а пользы будет действительно много. НО!!! Только не надо нам тут подсовывать, какой-то не Windows-описатель, как это сделано у Вас с QTable. Нам нужна возможность полноценной привязки к вкладке и возможность "перепрыгивать" с вкладки на вкладку.
 
 
#49
13.06.2015 09:47:23
Цитата
sam063rus пишет:
если бы Вы сделали функцию в QLUA, возвращающую хендл текущей вкладки - то это бы избавило от массы проблем.
При отсутствии возможности задавать положение окна на конкретной вкладке польза от такой функции будет сомнительной.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#50
13.06.2015 12:11:37
Цитата
Старатель пишет:
При отсутствии возможности задавать положение окна на конкретной вкладке польза от такой функции будет сомнительной.
положение окна, его размер, обработка событий - всё это уже делается элементарно с помощью winAPI. Кроме того, можно также сделать, чтоб это всё запоминалось бо как info.wnd - это не панацея и никто не запрещает пользователям создавать/хранить свои настройки окон для своих скриптов в своих файлах.
 
 
Страницы: 1 2 След.
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2025,
ARQA Technologies
Наверх