box_lib.obj - библиотека gui компонентов
-
Разве что самому нарисовать.
добавил документацию к PathShow и на svn (ревизия 2125)
Почему текст возле чекбокса пишется не по-центру, а снизу?
- Attachments
-
-
111.png (42.74 KiB)Viewed 6703 times
-
Из хаоса в космос
Про это я уже с год назад говорил Алексею, но видать у него руки не дошли исправить, либо не понял о чем я. Что-же буду исправлять сам.
Не думаю, что там что-то сложное.
Из хаоса в космос
Когда вот таких несложных задач пытаешься делать десяток сразу - они сразу перестают быть несложными.
Нужно пересобрать программу с измененным флагом положения текста.Leency wrote:Почему текст возле чекбокса пишется не по-центру, а снизу?
Вот где собака порылась.
Что за идиотская идея была ввести флаг положения текста у чекбоксов? Ну где реально может понадобиться выводить текст у чекбокса не по-центру?
Из хаоса в космос
SVN r.2249 поправил положение текста для checkbox и optionbox
Leency
Скорее всего положение текста было сделано таким еще первоначальным автором компонентов, так что не надо ругаться на Алексея.
Leency
Скорее всего положение текста было сделано таким еще первоначальным автором компонентов, так что не надо ругаться на Алексея.
Прошу прощения за офф-топ, однако, разве никто никогда не видел подписей под checkbox'ами в Win или Linux (Unix-подобных) системах?
Или я не прав?
Или я не прав?
Программист не тот, кто постоянно пишет КОД, а тот кто сможет понять чужой КОД!!!
В принципе, если ВСЁ по центру, то и ... с ним. Но если культурно, то есть для людей (л, УЗЕРОВ), то лучше с вариациями. Личное мнение.
Программист не тот, кто постоянно пишет КОД, а тот кто сможет понять чужой КОД!!!
Странно, когда делаешь, одновариантным - плохо, дескать не предусматриваешь другое видение, вот сделал, так, что бы каждый смог использовать компонент как ему будет интересно, как удобно.
Люди, чем больше возможностей - тем лучше, я же не ограничиваю вас в фантазии, в конце концов, хочется - можно обернуть компонент в что-то свое, это все достаточно легко делается. По поводу расположение чеков, изначально у автора была задумка в нижней позиции чека располагать текст, я только придерживался изначального варианта.
Люди, чем больше возможностей - тем лучше, я же не ограничиваю вас в фантазии, в конце концов, хочется - можно обернуть компонент в что-то свое, это все достаточно легко делается. По поводу расположение чеков, изначально у автора была задумка в нижней позиции чека располагать текст, я только придерживался изначального варианта.
Люди которые занимались написанием элементов для box_lib знают или догадываются о том что я сейчас скажу.
Нужно стандартизировать все элементы управления. Так будет возможно решить возникающие трудности при развитии библиотеки и добавлении новых компонентов. Предлагаю в начале структуры каждого элемента библиотеки сделать общую информацию для каждого элемента. Например можно сделать так:
Это позволит создать несколько общих функций, например:
element_draw - сейчас для рисования каждого элемента создается своя функция. Но можно будет сделать одну общую, которая в зависимости от значения element_id будет вызывать необходимую функцию для рисования элемента.
element_key - таже ситуация что и с функциями draw
element_move - чтобы можно было одной функцией менять расположение любого элемента
element_set_focus - ... установка фокуса на элемент
element_get_rect - ...
... - и т. д.
В итоге использование элементов прикладными программистами должно значительно облегчится, т. к. библиотека уже не будет экспортировать множество однотипных функций, а сама в зависимости от кода элемента будет определять что ей делать. Специфические функции для каждого элемента останутся.
В начале это будет новый branch, т. к. такие изменения сразу сделать нельзя, много всего нужно переписывать. Рано или поздно это нужно начинать Главный вопрос в том кто первый решится. Может быть будут предложения о том что еще нужно включить в общую часть структуры элемента?
Нужно стандартизировать все элементы управления. Так будет возможно решить возникающие трудности при развитии библиотеки и добавлении новых компонентов. Предлагаю в начале структуры каждого элемента библиотеки сделать общую информацию для каждого элемента. Например можно сделать так:
Code: Select all
element_id dd ?
left dw ?
top dw ?
width dw ?
height dw ?
; данные относящиеся к конкретному элементу,
; которые создает автор кода
element_draw - сейчас для рисования каждого элемента создается своя функция. Но можно будет сделать одну общую, которая в зависимости от значения element_id будет вызывать необходимую функцию для рисования элемента.
element_key - таже ситуация что и с функциями draw
element_move - чтобы можно было одной функцией менять расположение любого элемента
element_set_focus - ... установка фокуса на элемент
element_get_rect - ...
... - и т. д.
В итоге использование элементов прикладными программистами должно значительно облегчится, т. к. библиотека уже не будет экспортировать множество однотипных функций, а сама в зависимости от кода элемента будет определять что ей делать. Специфические функции для каждого элемента останутся.
В начале это будет новый branch, т. к. такие изменения сразу сделать нельзя, много всего нужно переписывать. Рано или поздно это нужно начинать Главный вопрос в том кто первый решится. Может быть будут предложения о том что еще нужно включить в общую часть структуры элемента?
Включить предлагаю поле "тип элемента" - со стандартным скином или программно-определенным. Это еще сильнее может упростить жизнь программисту. Если ему параллельно, какие цвета будут у контрола, или, что еще важнее, он хочет использовать системные цвета - то опция "стандартный скин" позволит ему не определять кучу параметров вручную. Только размеры контрола, изображение для dynamic button и надписи. Плюс это еще один маленький шажок к унификации интерфейса.
Who is online
Users browsing this forum: No registered users and 2 guests