Здравствуйте, VladD2, Вы писали:

B>>Я уже добавил в интерфейс декорируемого свойства HUnitSize и VUnitSize.

VD>И что в них помещать?

VD>Давай представим реальную ситуацию. Вот у меня редактор кода который скролирует текст по строкам. Что я должен буду указать в эти свойства?

VUnitSize = высота строки (разве, это так сложно?)
HUnitSize = ширина символа (как в студии, хотя, в ворде я не понял, что это за величина)

А если не так, то как?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Badenweiler, Вы писали:

VD>Контрол должен измерять все в попугаях, а уж интерпретация этих попугаев — это проблема прикладного программиста.]

В попугаях? Что имеется ввиду под контролом? Декоратор? Т.е. попугаи == пиксели? Так кто должен скроллить окно? Декорируемый?
Есть вот такой enum:

enum ScrollValue
{
    Line, //Ну, это
    Page, //  понятно
    All //Проскролть до конца
}

Т.к. я выделил многое из декоратора, ему передается вот такой параметр и его интерпретирует именно он. А теперь, значит, нудно передавать его выше — декорируему. До этого декорируемый ничего не выполнял, а теперь — заставить его самогму скроллиться?

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

Здравствуйте, Badenweiler, Вы писали:

B>Здравствуйте, VladD2, Вы писали:

B>>>Я уже добавил в интерфейс декорируемого свойства HUnitSize и VUnitSize.

VD>>И что в них помещать?

VD>>Давай представим реальную ситуацию. Вот у меня редактор кода который скролирует текст по строкам. Что я должен буду указать в эти свойства?

B>VUnitSize = высота строки (разве, это так сложно?)
B>HUnitSize = ширина символа (как в студии, хотя, в ворде я не понял, что это за величина)

А зачем они?

B>А если не так, то как?

Есть два варианта работы со скролингом. Причем живут они параллельно и один другой не исключает.

1. Когда высота строк одинаковая. При этом можно определить сколько строк влезает в представлении (читай окне) и сколько строк есть в документе (тоже самое и по горизонтали). При этом можно задать эти два параметра (количество строк в представлении и сколько строк в документе (т.е. всего)) и получить скроллеры отражающие не только козицию но и приблизительный размер документа. Обрати внимание на то, что большинство скролбаров в виндовс имеют движок переменного размера. Его размер как раз и отражает отношение количества строк в документе к количеству строк в предствлении.
2. Когда строка имеет переменный размер. При этом скролинг ведется построчно, а точное количество строк влезающих в представление определить невоможно (оно варьируется от страницы к странице). При этом обычно или забивают на количество строк на странице, или указывают приблизительное их число и мучаются (так как при этом отображение движков сроллера получается не очень точным). Вот я, например, мучаюсь в Rsdn.Editio-е, так как строки могут быть разного размера.

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

Здравствуйте, Badenweiler, Вы писали:

B>В попугаях?

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

B> Что имеется ввиду под контролом?

Ну, скроллбар.

B> Декоратор? Т.е. попугаи == пиксели?

Не факт. Это просто не должно волновать скролбары. Им сказали что всего в документе Х попугаев, а в представление влезает У который меньше или равен Х.

B> Так кто должен скроллить окно? Декорируемый?

Нет. Скролировать должен прикладной код. Это не забота скролбаров. Они должны только отрабатывать мат.модель. Ну, то есть, выдавать текущую позицию, выдавать события вроде перелистывания страницы/строки и позволят изменить текущую позицию (как напрямую, так и эмуляцией событий скролирования).

B>А прикладной программист — это тот, что прикручивает декоратор себе к контролу? А как же изоляция? (см. выше)

Изоляция от чего?

Смотри... у меня есть модель документа и представление с его состоянием. Покрутка — это изменение состояния преставления. Мне нужно иметь возможность:
1. Отразить текущее состояние представления. Для этого я должен иметь возможность задать текущую верхнюю строку (строку условно) представления. Это должно отразиться на скроллере путем сдвижки его движка. Например, если строка равна 0, то движок должен оказаться в самом верху. Если же значение равно 50, а общее количество строк 100, то движок должен оказаться в середите. Ну, и так делее...
2. Я должен иметь возможность получения событий скролинга (перемещение на страницу в верх, перемещение на строку вниз, и т.п.).
3. Я должен иметь возможность сэмулировать скролинг. То есть мне нужны методы вроде PageDown(), LineUp() и т.п.

Собственно все. А логика работы такая. Когда я получаю событие PageDown я произвожу нужные рассчеты, изменяю состояние представления и отражаю его в скроллбаре. Когда мне нужно выполнить программный переход на страницу вниз я вызываю метод PageDown() который генерирует событие...

Здравствуйте, VladD2, Вы писали:

B>>В попугаях?
VD>Ну, в неких абстрактных еденицах. Это и не пиксели и не строки... это нечто с чем удобно работать коду взаимодействующему со скроллерами.
Ну себя-то скроллы в экранных единицах измеряют (пикселях). Ну да ладно.

B>>попугаи == пиксели?
VD>Не факт. Это просто не должно волновать скролбары.
Ну да, сейчас так оно есть

VD>Скролировать должен прикладной код. Это не забота скролбаров.
Да я просто подумал, что скроллы должны ловить такие события (MouseWheel, Up, Down, PageUp, PageDown,..) и сами скроллить окно. Ну а раз так — тогда понятно.

Здравствуйте, VladD2, Вы писали:

VD>Есть два варианта работы со скролингом. Причем живут они параллельно и один другой не исключает.
VD>1. Когда высота строк одинаковая.
VD>2. Когда строка имеет переменный размер.
Вот об этом я и говорил

Автор: Badenweiler
Дата: 21.10.05

Значит, есть второй вариант. А я от мучений избавлен?

Здравствуйте, Badenweiler, Вы писали:

VD>>1. Когда высота строк одинаковая.
VD>>2. Когда строка имеет переменный размер.
B>Вот об этом я и говорил

Автор: Badenweiler
Дата: 21.10.05

B>Значит, есть второй вариант. А я от мучений избавлен?

Не понял.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Badenweiler, Вы писали:

VD>>>1. Когда высота строк одинаковая.
VD>>>2. Когда строка имеет переменный размер.
B>>Вот об этом я и говорил

Автор: Badenweiler
Дата: 21.10.05

B>>Значит, есть второй вариант. А я от мучений избавлен?

VD>Не понял.

Вот так:

interface IScrollableControl
{
    long HSizeOf(long pos);
    long VSizeOf(long pos);
}

Гду pos — номер строки.
Этот метод возвращает размеры этой самой строки

Здравствуйте, daredevilcs, Вы писали:

Кто-нибудь это использует? Как скорость отрисовки? Я тут почитал топик, вроде используется GDI+, а он не очень шустрый. Если контролов много, скажем штук 50, это всё не превращается в большой мигающий тормоз?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, daredevilcs, Вы писали:

A>Кто-нибудь это использует?
Меня и самого когда-то это очень интересовало

A>Как скорость отрисовки? Я тут почитал топик, вроде используется GDI+, а он не очень шустрый. Если контролов много, скажем штук 50, это всё не превращается в большой мигающий тормоз?
Эх, лениво, конечно, но на неделе попробую.

Здравствуйте, VladD2, Вы писали:

V>>А зачем все это, если не секрет?
V>>Для того, чтобы отобразить скролл-бары без создания отдельных окошек для них надо просто выставить стили окна WS_VSCROLL, WS_HSCROLL, при этом само окно выделит необходимое место в неклиентской части окна.

VD>К сожалению, не на всех платформах поддерживаются все возможности скролбаров. К тому же рисованные скролбары будут очень удобны.

Ясен. Я о многоплатформенности GUI на дотнет тоже думал и экспериментировал (есть кое-какие наработки, если интересно — велкам). Единственно приемлимый способ выходит — это собственная windows-less библиотека контролов, которая умеет использовать некий нативный windows как банальный canvas. Иначе же получаются кучи роперов на каждый интересный контрол.

Кстати, windowsless либа с т.з. моего ИМХО должна дать приличное ускорение рендеринга сложных форм на дотнет, ибо сейчас там такааааая жопа происходит при обработке всяких WM_PAINT... В общем, как выяснилось, GUI в дотнет тормозит не из-за характера самого дотнета, а от способа реализации кишков Windows.Forms...

Здравствуйте, Badenweiler, Вы писали:

A>>Как скорость отрисовки? Я тут почитал топик, вроде используется GDI+, а он не очень шустрый. Если контролов много, скажем штук 50, это всё не превращается в большой мигающий тормоз?
B>Эх, лениво, конечно, но на неделе попробую.

Попробовал. Кнопки в количестве 48 штук "выглядят" вполне комфортно. Отрисовка занимает у меня 265 мс (Celeron-Willamette 1.7Ghz). Многие остальные контролы ненамного сложнее кнопок, так что, можно сказать, что ситуация несовсем плачевна.
Пробовал множить тулбары: штук двадцать с общим количеством кнопок более 300 — это же время уходит только на отрисовку каждого (тулбара) — но их отрисовка непроста, да и в таком количестве они не часто нужны.

И про дизайн-тайм — там настоящее слайдшоу