По сути ты будешь делать то же самое - система узнает какой проге принадлежит окно и отдаст ей управление, программа будет уже по своим описателям искать что это за координата, что там - кнопка или чекбокс и будет уже обслуживать его...Сообщение от Zet9
А теперь умнож объем кода обработчика каждой программы на количество окон... что мы имеем? для 10 окон у нас будет 10 блоков обработки, у каждого окна все равно будет табличка с координатами элементов - тот же самый описатель... и тут уже 2кб, как ты говорил - не отделаешься. Так зачем же изобретать очередное колесо?
Если будет скоростной режим переключения страниц, как ты думаешь - кто будет использовать "тормозной"? Стоит ли на него заморачиваться при его несостоятельности?
там же где будут хранить программы свои обработчики вызовов от графподсистемы. Да, я думал, я подумал, еще лет 10 назад, когда графическую либу с подобными возможностями делал.
Описатели будут храниться в коде программы или в сегменте данных - как угодно, зачем его хранить с графподсистемой вместе?
только ты не забывай, то при динамическом построении окна ты тратишься еще и на код прорисовки, а при взаимодействии с окном - еще и на код опроса. т.е. уже дважды не экономно используешь память.
И поддержка элементов управления со стороны программы усложнит и увеличит по времени написание программ, когда проще было бы создать описатель со свойствами нужных элементов и адресами обработчиков. И еще - мы теряем унификацию интерфейса - все будут делать как им проще и удобнее, не факт, что быстрее и оптимальнее. И представь - в памяти 3 программы и каждая будет содержать в себе по полноценной библиотеке интерфейса - зачем такие накладные расходы?
А полноценная графическая либа с выводом окон, текста в них, спрайтов, поддержкой мыши, с парой шрифтов и пр. у тебя все равно займет порядка 5-7 кб, не меньше... обработчик описателей - по сравнению с этой либой не много займет, т.к. во всю использует имеющуюся либу, и состоит всего лишь из цикла выборки кода объекта и передачи данных соответствующей процедуре прорисовки из графлибы.
---------- Post added at 13:49 ---------- Previous post was at 13:36 ----------
Я тебе за здравие - ты за упокой...
Т.е. если надо прочитать файл - то это надолго и можно положить в долгий ящик, что касается реализации интерфейса - то при почтовых ящиках и циклах ожидания мы получим дикий тормоз при рисовании окон и текста, выполнении каких-либо действий через системные библиотеки... тем более что почтовый ящик всего на одно сообщение...
Как я понимаю, менеджер задач будет раздавать задачам время кратное 1 период инта (на стандартной машине иного не придумать наверное), соответственно, если прога положила в почтовый ящик запрос на действие (любое) и ушла в цикл ожидания, то система обработает сообщение по приходу прерывания? или будет какой-то вызов для передачи управления?
Ответить с цитированием