Здравствуйте, vitz, Вы писали:
V>Граждане поможите!!!
V>В WinGDI имеется такая функция int SetROP2(HDC hdc,int mode), которая устанавливает режим смешивания ForeColor и BackColor при рисовани.
V>Конечно можно импортировать эту функцию, но тогда прийдется все, что нужно смешивать, рисовать через GDI.
V>Как устновить режим смешивания в Graphic ???
Graphics.SetCompositingMode(mode);
Graphics.SetCompositingQuality(quality);
Здравствуйте, mihailik, Вы писали:
V>>>Как устновить режим смешивания в Graphic ???
K_O>>Graphics.SetCompositingMode(mode); K_O>>Graphics.SetCompositingQuality(quality);
M>Но! Режим XOR не поддерживается. Для него нужно всё-таки использовать старый GDI. По-любому
Microsoft сознательно убрала растровые операции из GDI+, потому что эти операции зависят от формата представления данных (в данном случае — цвета пикселей), да и применяются к пикселям. А на платформе .NET от этих понятий решили отойти.
Microsoft® Windows® GDI+ is a class-based application programming interface (API) for C/C++ programmers. It enables applications to use graphics and formatted text on both the video display and the printer. Applications based on the Microsoft Win32® API do not access graphics hardware directly. Instead, GDI+ interacts with device drivers on behalf of applications. GDI+ is also supported by Microsoft Win64™.
Where Applicable
GDI+ can be used in all Windows-based applications. GDI+ is new technology that is included in Windows XP and the Windows Server 2003. It is required as a redistributable for applications that run on the Microsoft Windows NT® 4.0 SP6, Windows 2000, Windows 98, and Windows Millennium Edition (Windows Me) operating systems.
Developer Audience
The GDI+ C++ class-based interface is designed for use by C/C++ programmers. Familiarity with the Windows graphical user interface and message-driven architecture is required.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Microsoft сознательно убрала растровые операции из GDI+, потому что эти операции зависят от формата представления данных (в данном случае — цвета пикселей), да и применяются к пикселям.
Кстати, они, кажется, уже раскаиваются в этом. Вон что добавили в System.Drawing.Graphics в 1.2:
public void CopyPixels(Graphics source, int xSource, int ySource, int xDest, int yDest,
Size blockRegionSize, CopyPixelOperation rasterOp) {
...
int res = SafeNativeMethods.BitBlt(hhdc, xDest, yDest, w, h,
srcHdc != IntPtr.Zero ? new HandleRef(source, srcHdc) : hhdc, xSource, ySource, (int)rasterOp);
Purpose
Microsoft® Windows® GDI+ is a class-based application programming interface (API) for C/C++ programmers. It enables applications to use graphics and formatted text on both the video display and the printer. Applications based on the Microsoft Win32® API do not access graphics hardware directly. Instead, GDI+ interacts with device drivers on behalf of applications. GDI+ is also supported by Microsoft Win64™. Where Applicable
GDI+ can be used in all Windows-based applications. GDI+ is new technology that is included in Windows XP and the Windows Server 2003. It is required as a redistributable for applications that run on the Microsoft Windows NT® 4.0 SP6, Windows 2000, Windows 98, and Windows Millennium Edition (Windows Me) operating systems. Developer Audience
The GDI+ C++ class-based interface is designed for use by C/C++ programmers. Familiarity with the Windows graphical user interface and message-driven architecture is required.
Ага, "для С/С++ программистов"... и ни слова о .NET, к тому же.
Из этого, похоже, следовало было заключить, что .NET здесь ни при чем?
Тогда такой вопрос: почему столько лет все прекрасно обходились процедурным GDI, а вот с сейчас почему-то понадобилось создавать объектно-ориентированный интерфейс? И по времени это как-то совпало с выходом .NET
А дело в том, что при разработке .NET понадобилась графическая библиотека, аналог GDI для Win32. И вот, вместо того, чтобы запихивать процедурные вызовы GDI в классы-врапперы, в MS решили произвести рефакторинг сущесвующей графической подсистемы, убрать платформно-зависимые понятия и добавить новые возможности, для того, чтобы эту подсистему можно было использовать при программировании для .NET.
Здравствуйте, Kh_Oleg, Вы писали:
K_O>Тогда такой вопрос: почему столько лет все прекрасно обходились процедурным GDI, а вот с сейчас почему-то понадобилось создавать объектно-ориентированный интерфейс? И по времени это как-то совпало с выходом .NET
Здравствуйте, Kh_Oleg, Вы писали:
K_O>А дело в том, что при разработке .NET понадобилась графическая библиотека, аналог GDI для Win32. И вот, вместо того, чтобы запихивать процедурные вызовы GDI в классы-врапперы, в MS решили произвести рефакторинг сущесвующей графической подсистемы, убрать платформно-зависимые понятия и добавить новые возможности, для того, чтобы эту подсистему можно было использовать при программировании для .NET.
System.Drawing.Graphics — классы-врапперы над процедурными вызовами GDI+:
public void DrawLine(Pen pen, int x1, int y1, int x2, int y2) {
if(pen == null)
throw new ArgumentNullException("pen");
int status = SafeNativeMethods.GdipDrawLineI(new HandleRef(this, nativeGraphics),
new HandleRef(pen, pen.nativePen), x1, y1, x2, y2);
CheckErrorStatus(status);
}
Плюсовая обертка над GDI+ — такие же врапперы:
Status DrawLine(IN const Pen* pen,
IN INT x1,
IN INT y1,
IN INT x2,
IN INT y2)
{
return SetStatus(DllExports::GdipDrawLineI(nativeGraphics,
pen->nativePen,
x1,
y1,
x2,
y2));
}
Здравствуйте, Andir, Вы писали:
K_O>>GDI+ создавался для .NET. А поэтому там присутствуют те особенности, о которых сказано выше. A>Откуда дровишки то хоть расскажи ... а то я почему-то программил под GDI+, когда о .Net только слухи ходили.
Ниоткуда. Только собственные размышления, возможно неточные.
Я начал использовать GDI+ в 2002 году, поэтому за событиями, происходившими ранее следил не особо внимательно.
Судя по первым сообщениям на news.microsoft.com, GDI+ появился где-то году в 99 или 2000. А .NET разрабатывался с 1997 года.
Судя по всему, разработка .NET и GDI+ была начата примерно в одно время, а поскольку по своим масштабам эта библиотека значительно уступает .NET, потому и разработка была закончена раньше.
Насколько я понимаю, необходимость рефакторинга графической подсистемы Windows зрела очень давно. И GDI+ не был разработан исключительно для .NET, но с учетом .NET, с тем чтобы его можно было использовать в качестве графической библиотеки на новой платформе.
Здравствуйте, desperado_gmbh, Вы писали:
_>Здравствуйте, Kh_Oleg, Вы писали:
K_O>>Microsoft сознательно убрала растровые операции из GDI+, потому что эти операции зависят от формата представления данных (в данном случае — цвета пикселей), да и применяются к пикселям.
_>Кстати, они, кажется, уже раскаиваются в этом. Вон что добавили в System.Drawing.Graphics в 1.2:
public void CopyPixels(Graphics source, int xSource, int ySource, int xDest, int yDest,
Size blockRegionSize, CopyPixelOperation rasterOp) {
...
int res = SafeNativeMethods.BitBlt(hhdc, xDest, yDest, w, h,
srcHdc != IntPtr.Zero ? new HandleRef(source, srcHdc) : hhdc, xSource, ySource, (int)rasterOp);
Да, весьма любопытно. На longhorn.msdn.microsoft.com эти методы уже присутствуют, однако они там пока никак не описаны. Интересно будет узнать, почему MS решила вернуть понятие пикселей на уровень класса Graphics. И как это будет работать для устройств, которые не оперируют пикселями.
Здравствуйте, mihailik, Вы писали:
_>>public void CopyPixels(Graphics source M>А ты не знаешь, оно у них где-нибудь используется, или это для каких-нибудь грязных хаков оставили?
Еще нет. Но в winforms и так хватает BitBlt, PatBlt и прочих грязных хаков, заимпорченных напрямую. Вон тот же ControlPaint.CreateHBitmapColorMask.
Наверное, в каком-нибудь следующем MS Office и т.п. будут втихую использовать.
_>Но в winforms и так хватает BitBlt, PatBlt и прочих грязных хаков, заимпорченных напрямую. Вон тот же ControlPaint.CreateHBitmapColorMask.
ControlPaint это не грязный хак. Это вполне чистый и официальный хак.
