Как работать с канвасом на Си шарпе?
То есть на Делфи я писал Image1.Canvas.Rectangle(...) ili Line it d.
Как эти делается на C#

Например, вот так:




или примерно так:




Подробнее см. System.Drawing

Сделать графический объект и на нем уже рисовать.

> Как работать с канвасом на Си шарпе?
> То есть на Делфи я писал Image1.Canvas.Rectangle(...) ili
> Line it d.
> Как эти делается на C#

Есть только одна тонкость, graphics не всегда есть. То есть, если ты перегружаешь OnPaint, то ты graphics получаешь из параметров. Если же тебе
захотелось в произвольный момент времени порисовать на контроле, то
тебе надо сделать Control.CreateGraphics(), порисовать, а потом полученный graphics убить через Dispose (или просто воспрользоваться конструкцией using).

> То есть, если ты перегружаешь OnPaint, то ты graphics получаешь из параметров.

"Рисовать по OnPaint" было катастрофическим моветоном и на Делфи.
Это годилось лишь для простеньких примеров.

> [4] Курдль ©   (03.04.06 14:11)
> "Рисовать по OnPaint" было катастрофическим моветоном и
> на Делфи.

Сорри, а что тогда можно было делать в OnPaint как не рисовать? Или использование самого события OnPaint — моветон?

> Курдль ©   (03.04.06 14:11) [4]

Не вводите людей в заблуждение спорными утверждениями.

В чём именно моветон?
Как предлагается рисовать не простенькие примеры?

> Джо ©   (03.04.06 14:41) [5]
> Сорри, а что тогда можно было делать в OnPaint как не рисовать?


Выбросить его... из головы.


> DiamondShark ©   (03.04.06 15:42) [6]
> Как предлагается рисовать не простенькие примеры?

Создавать объекты графических классов и поверх них рисовать в тот момент, когда изображение Вам понадобится, а не "по OnPaint"! Даже такой простой контрол, как TImage в Delphi умеет восстанавливать зону перекрытия, отрисовывать скрытую часть изображения после ресайза, использовать двойную буфферизацию и т.п.

Так что это Вы, уважаемый DiamondShark не вводите людей в заблуждение!

> Курдль

Вы таки гоните любезнейший.

OnPaint в .NET - это обёртка сообщения WM_PAINT, OnPaintBackground - обёртка WM_ERASEBKGND. Эти сообщения посылаются ОС окну в тот момент, когда окно повредилось, к примеру, другим окном, или растянулось, и должно перерисоваться. Именно из параметров этих методов можно получить координаты "повреждённого" региона окна. В других случаях перерисовывать окно нет смысла.
То, что вы, очевидно, имеете в виду, относится к активно отрисовываемым компонентам типа графика загрузки процессора в TaskManager - в этом случае действительно можно обновлять окно по таймеру (например, вызывать Invalidate()), но отрисовку окна всё равно нужно выполнять не где-нибудь, а именно в OnPaint и OnPaintBackground.

А двойная буферизация и в .NET есть. См. флаги метода Control.SetStyle().

> [7] Курдль ©   (03.04.06 15:48)
> Создавать объекты графических классов и поверх них рисовать
> в тот момент, когда изображение Вам понадобится, а не "по
> OnPaint"!

Вот и хотелось бы узнать, каким образом предлагается узнавать тот самый момент "когда понадобится".

г. Курдль несет какуюто пургу
рисовать в ОнПаинт моветон, АДО для закомплексованных на Делфи, 1С ацтой потомучто МССКЛ использует и тд

> АДО для закомплексованных на Делфи,

Было и такое? Хм.

> Ломброзо ©   (03.04.06 18:40) [8]


Вы все правильно говорите. Абсолютно правильно. Если хотите потренироваться или поупражняться в программировании - так и делайте. Находите области отрисовки, перекрытия и т.п. вручную и рисуйте на них недостающие участки картинок и т.д.
Суть моего спитча в том, что графические контролы в Делфи и графические классы в С# умеют делать это сами. Поместите один раз, например, картинку на TImage и больше не надо будет заботиться о ее отображении, перерисовке, ресайзе и т.п! Именно это я имел ввиду.


> Джо ©   (03.04.06 18:41) [9]
> Вот и хотелось бы узнать, каким образом предлагается узнавать
> тот самый момент "когда понадобится".

Смотрите предыдущее предложение. Момент "когда понадобится" Вы определите согласно бизнес-правилам Вашего приложения. Например, по нажатию на кнопку "Показать график" приложение отрисует этот график на канве компонента TImage. И больше не надо заботиться о его перекрытии другим окном, сохранении изображения при изменении размера и т.п.
Если Вы сомневаетесь в моих скудных знаниях(а они и вправду не профессорские) в программировании графики, можете глянуть на прогу, которую я делал ради забавы год назад на C#: http://www.kurdl.h15.ru/pages/land/lanlend.htm (скриншот 50 КБ)
Можете также поиграться с демонстрационной программой, которую я делал пару лет назад для одного заказчика на Делфи. Это эскиз компонента отображения диаграмы Гантта, где есть и табличные элементы, и графические. Все можно двигать, скроллировать, схлопывать и т.п.
http://kurdl.h15.ru/pages/land/Gantt.rar (550 КБ)


> Джо ©   (03.04.06 19:09) [11]
> Было и такое? Хм.

Нет. Я как-то обидел г-на Polevi © заявлением, что понятие "текущая запись в наборе данных" является проблемой лишь для закомплексованных на Делфийской концепции ДатаСэта товарищей. Остальных разработчиков ADO.NET подобная проблема не сильно огорчает :)

> Суть моего спитча в том, что графические контролы в Делфи
> и графические классы в С# умеют делать это сами. Поместите
> один раз, например, картинку на TImage и больше не надо
> будет заботиться о ее отображении, перерисовке, ресайзе
> и т.п! Именно это я имел ввиду.


Это все конечно хорошо, если речь идет о статическом изображении, что на практике встречается редко. Обычно требуется интерактив. А он реализуется через кантролы, а на каждом кантроле создавать картинку ради того, что бы его прорисовать - это очень накладно как по проц времени, так и по объему памяти. Гораздо легче рисовать его в онпаинт.

> Гораздо легче рисовать его в онпаинт.


Нет. Нет! И еще раз НЕТ!!!
Вы знаете, сколько раз вызовется OnPaint при увеличении формы при помощи "захвата мышкой"?

> Курдль ©   (04.04.06 11:44) [14]

Уважаемый, не стучите ложкой. Попробуйте лучше написать аналог Label с WordWrap=true и TextAlign=MiddleCenter.

> DiamondShark ©   (04.04.06 12:01) [15]
> Уважаемый, не стучите ложкой. Попробуйте лучше написать аналог Label с WordWrap=true и TextAlign=MiddleCenter.

Я написал и нечто посложнее этого. В принципе, Ваше задание никак не относится к OnPaint. Однако, я понял тайную задумку - чтобы в дизайн-тайме при изменении размеров текст позиционировался по центру и предложение переносилось по словам. Согласен. Такие простые задачи можно делать на OnPaint. Но такие задачи, как правило, решены!

А теперь Вы представьте спектрограмму вычисляемую не одну секунду (или любой другой график, требующий сложных математических вычислений).
Так вот, что удобнее, один раз нарисовать его на графическом объекте или пересчитывать каждый раз по OnPaint?

> Нет. Нет! И еще раз НЕТ!!!
> Вы знаете, сколько раз вызовется OnPaint при увеличении
> формы при помощи "захвата мышкой"?

Знаю.
Но вообще-то обычно помогает:

> Algol   (04.04.06 12:11) [17]
> this.SetStyle(ControlStyles.ResizeRedraw, false);


Это может противоречить стилю, выбранному пользователем.
Я не могу понять, зачем делать вручную то, что любезно предоставляется Вам средой разработки в виде графических контролов либо классов? (За исключением случаев, когда это действительно нужно См. DiamondShark ©   (04.04.06 12:01) [15])?

> Я не могу понять, зачем делать вручную то, что любезно предоставляется
> Вам средой разработки в виде графических контролов либо
> классов?


Может я чего-то не понимаю, но я не вижу разницы в рисовании на канве битмапа и рисовании в онпаинт...У меня код получается идентичный...
За исключением того, что битмап требует лишних ресурсов...

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