Jump to content
Sign in to follow this  
weaponx

GUICtrlCreateGraphic

Recommended Posts

weaponx

When I create a graphic control in AutoIt, the window info tool shows it as a "Static" class. The MSDN doesn't show any drawing functions for the Static class.

Is it a standard control?

Can it be buffered to reduce flickering?

Can it be anti-aliased via DllCall or some other means?

Share this post


Link to post
Share on other sites
Valik

If I had to guess it's an owner-drawn static control. I've honestly never looked at that code, though. As for doing special stuff with it? Not without drawing it yourself. You're going to have to get your hands dirty with the Windows API drawing code if you want to do fancy stuff or to draw it in an off-screen buffer first.

Share this post


Link to post
Share on other sites
cppman

When I create a graphic control in AutoIt, the window info tool shows it as a "Static" class. The MSDN doesn't show any drawing functions for the Static class.

It is a static control. The drawing functions for a static control (and any other "control") compose the GDI (and GDI+) library. Remember, all "controls" are simply "windows" (in a sense).

You just get the handle of it, and draw in it using GDI functions.

#include <gdiplus.au3>
GUICreate("")
$ctrl = GUICtrlCreateGraphic(0, 0, 100, 100)
$hwnd = GUICtrlGetHandle($ctrl)
GUISetState()

_GDIPlus_Startup()
$dc = _GDIPlus_GraphicsCreateFromHWND($hwnd)
_GDIPlus_GraphicsSetSmoothingMode($dc, 2) ;sets anti-aliasing on

_GDIPlus_GraphicsClear($dc, 0xFFFF0000) ; clear it to RED
; then we can do drawings...
_GDIPlus_GraphicsDrawRect($dc, 5, 5, 25, 25)
_GDIPlus_GraphicsDrawLine($dc, 0, 0, 100, 100)

While(GUIGetMsg() <> -3)
    Sleep(10)
WEnd

_GDIPlus_GraphicsDispose($dc)
_GDIPlus_Shutdown()

For double-buffering (or just having a "backbuffer"), you would just need to create another DC (or bitmap) and do all of the rendering to that. Then, whenever you want to render the backbuffer, you simply BitBlt it.

Edited by cppman

Share this post


Link to post
Share on other sites
Valik

cppman, that code only works once. The moment the control is invalidated and requires re-painting, everything you drew in it with that GDI code is gone.

Share this post


Link to post
Share on other sites
weaponx

I am fully aware of double buffering and line smoothing via GDI. I was just wondering if it was possible to get a handle to the graphics object behind the scenes and call GdipSetSmoothingMode before calling GUICtrlSetGraphic($graphic,$GUI_GR_REFRESH).

If it is drawn with GDI internally it would be nice to have a smoothing or double buffering option available.

Share this post


Link to post
Share on other sites
cppman

cppman, that code only works once. The moment the control is invalidated and requires re-painting, everything you drew in it with that GDI code is gone.

:P That's because it was an example of how to draw to the "static" control using GDI+ (too lazy to implement double-buffering).

I am fully aware of double buffering and line smoothing via GDI. I was just wondering if it was possible to get a handle to the graphics object behind the scenes and call GdipSetSmoothingMode before calling GUICtrlSetGraphic($graphic,$GUI_GR_REFRESH).

If it is drawn with GDI internally it would be nice to have a smoothing or double buffering option available.

That object is the device context. So, why not just use GDI/GDI+ directly? I guess it would be better to have for consistency, but it is rather pointless when there are GDI+ functions all ready included with AutoIt. Edited by cppman

Share this post


Link to post
Share on other sites
Valik

cppman, but that isn't an example that's useful. Alright, you showed how to draw on the control. Hooray. It does no good, because drawing to the control is arguably is the easiest part. The hard part is taking over drawing of the control or drawing the area manually (without a control) during a paint handler. That requires GUIRegisterMsg() fun.

Share this post


Link to post
Share on other sites
cppman

cppman, but that isn't an example that's useful. Alright, you showed how to draw on the control. Hooray. It does no good, because drawing to the control is arguably is the easiest part. The hard part is taking over drawing of the control or drawing the area manually (without a control) during a paint handler. That requires GUIRegisterMsg() fun.

What is so difficult about that? If you are worried about clipping (and aren't double-buffering), setup a virtual viewport (or something similar). Otherwise, it is just drawing to the main window in the rectangle where you would normally have the control.

Also, that example was referring to this:

The MSDN doesn't show any drawing functions for the Static class.

GDI/GDI+ are the drawing functions for the "static" window class. Edited by cppman

Share this post


Link to post
Share on other sites
Valik

That example was referring to this:

GDI/GDI+ are the drawing functions for the "static" window class.

Errr, that's a really perverted way of looking at things. I can't technically argue that because those functions are the Windows drawing functions - full stop. Qualifying them as being for the "static window class" is a gross misstatement of what they are.

Share this post


Link to post
Share on other sites
cppman

Errr, that's a really perverted way of looking at things. I can't technically argue that because those functions are the Windows drawing functions - full stop. Qualifying them as being for the "static window class" is a gross misstatement of what they are.

That is what they were meant to do, however. Not specifically the "static window class" but any window class in general.

Share this post


Link to post
Share on other sites
Valik

cppman, a word of advice? Back off now. You're quite simply wrong. GDI isn't for drawing on Windows. In fact, quite the opposite. It's for drawing on a device independent object so that all drawing behavior is the same regardless of the destination, be that a window, a printer, or some other output device.

Maybe you know all that but your wording doesn't convey that. Your wording is binding drawing and windows in a way that simply does not exist.

Share this post


Link to post
Share on other sites
cppman

cppman, a word of advice? Back off now. You're quite simply wrong. GDI isn't for drawing on Windows. In fact, quite the opposite. It's for drawing on a device independent object so that all drawing behavior is the same regardless of the destination, be that a window, a printer, or some other output device.

Maybe you know all that but your wording doesn't convey that. Your wording is binding drawing and windows in a way that simply does not exist.

To be honest, I wasn't aware of some of that. But be that as it may, GDI is still used to draw to windows.

Share this post


Link to post
Share on other sites
Valik

To be honest, I wasn't aware of some of that. But be that as it may, GDI is still used to draw to windows.

No. It's used to draw to a device context. Period. Something else then comes along and uses the device context to display the graphics in a way suitable for that device.

Share this post


Link to post
Share on other sites
cppman

No. It's used to draw to a device context. Period. Something else then comes along and uses the device context to display the graphics in a way suitable for that device.

Yes, that is true; however, I'd have to say that Microsoft's top priority with GDI was to render the Window's GUI environment. With that said, GDI was made specifically to render Windows' desktop environment (which would include "drawing to" windows). Edited by cppman

Share this post


Link to post
Share on other sites
Valik

Yes, that is true; however, I'd have to say that Microsoft's top priority with GDI was to render the Window's GUI environment. With that said, GDI was made specifically to render Windows' desktop environment (which would include "drawing to" windows).

You really don't know when to give up a point, do you? You really should have stopped the first time I said you should drop it. You're laboring a point that you can't make and it's becoming increasingly clear that you're one of those annoying programmers who can't differentiate between an interface and the implementation itself. You know that windows use DC's to store the drawing data therefore you assert that DC's are for drawing to windows. That would be like asserting that array's are for implementing vector's just because a common implementation of a vector is with an array. However, in reality, it's just an inconsequential implementation detail that doesn't matter 99% of the time.

Share this post


Link to post
Share on other sites
cppman

You really don't know when to give up a point, do you? You really should have stopped the first time I said you should drop it. You're laboring a point that you can't make and it's becoming increasingly clear that you're one of those annoying programmers who can't differentiate between an interface and the implementation itself. You know that windows use DC's to store the drawing data therefore you assert that DC's are for drawing to windows. That would be like asserting that array's are for implementing vector's just because a common implementation of a vector is with an array. However, in reality, it's just an inconsequential implementation detail that doesn't matter 99% of the time.

So, with that logic, the rendering of the Windows desktop environment is a recurring phenomenon due to drawing to a DC(surface) associated with a data structure which had no intention of being rendered in the first place? "The Graphics Device Interface (GDI) is one of the three core components or "subsystems", together with the kernel and the Windows API, for the user interface of Microsoft Windows." With that, I'd have to say GDI was developed with the intention of using it to render the Windows desktop environment. GDI would never have been created it if was only to be used for printers; however, if it were only to be used for Windows, it would have still been created.

The same thing happened with DirectX. First, it was intended for the development of games, and now it is being used to render the Windows Vista desktop environment.

Share this post


Link to post
Share on other sites
Valik

So, with that logic, the rendering of the Windows desktop environment is a recurring phenomenon due to drawing to a DC(surface) associated with a data structure which had no intention of being rendered in the first place? "The Graphics Device Interface (GDI) is one of the three core components or "subsystems", together with the kernel and the Windows API, for the user interface of Microsoft Windows." With that, I'd have to say GDI was developed with the intention of using it to render the Windows desktop environment. GDI would never have been created it if was only to be used for printers; however, if it were only to be used for Windows, it would have still been created.

The same thing happened with DirectX. First, it was intended for the development of games, and now it is being used to render the Windows Vista desktop environment.

Drop it, alright? You said something stupid, I called you on it, you learned something in the process yet you're still trying to argue a point you can't win. Just shut up already. You were wrong. Continuing to flaunt your ignorance to justify your original point is fruitless. That's what this boils down to, ignorance. You don't know enough about what you're talking about to be talking about it but unfortunately it's not stopping you from talking about it. You're also trying to misinterpret things I've said - I'm not going to speculate on why that is. The best thing you can do in response to this subject is not respond at all.

Share this post


Link to post
Share on other sites
cppman

Drop it, alright? You said something stupid, I called you on it, you learned something in the process yet you're still trying to argue a point you can't win. Just shut up already. You were wrong. Continuing to flaunt your ignorance to justify your original point is fruitless. That's what this boils down to, ignorance. You don't know enough about what you're talking about to be talking about it but unfortunately it's not stopping you from talking about it. You're also trying to misinterpret things I've said - I'm not going to speculate on why that is. The best thing you can do in response to this subject is not respond at all.

Yeah... yeah... The usual, "everybody is stupid and I'm a genius" reply.

My original point was simply that you use GDI to draw to a window(, and apparently you proved me wrong?).

Share this post


Link to post
Share on other sites
BrettF

Yeah... yeah... The usual, "everybody is stupid and I'm a genius" reply.

My original point was simply that you use GDI to draw to a window(, and apparently you proved me wrong?).

I would have taken the hints by now... :P

Share this post


Link to post
Share on other sites
Valik

Yeah... yeah... The usual, "everybody is stupid and I'm a genius" reply.

Maybe next time you'll think before you try to put words in my mouth. Enjoy your 3 day ban.

My original point was simply that you use GDI to draw to a window(, and apparently you proved me wrong?).

Your assertion is only true by proxy and that is the point you fail to grasp.

Anyway, thread locked. I'm tired of arguing with an idiot who chooses to word things in stupid ways and refuses to be corrected on them.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×