|
I suppose your guess is correct.
It doesn't look the simplest task for a newbie. I think he needs to go recursive.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
If i only have C and i want to draw a transparent line the only solution i can think of:
- create a memoryDC and a compatiblebitmap
- Draw the line on the memoryDC
- Create a region that occupies the drawed line only
- Set this region to the DC
- copy memoryDC to DC transparently using Alphablend()
For a few lines this could work, but when drawing 100-dreds of lines the overhead is just too much.
Is there any more clever approach?
Rozis
|
|
|
|
|
I don't know how
Rozis wrote: If i only have C
limits this but try using GDI+[^].
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
Code-o-mat wrote: I don't know how
Rozis wrote:
If i only have C
limits this but try using GDI+[^].
It does: C does not know about the concept of classes while GDI+ is a class oriented API. GDI+ has also a function interface but MS itself disencourages this...
If there are any people here who have experience with this function interface of GDI+, please give me a yell...
Rozis
|
|
|
|
|
I can also think of 2 alternatives but both include doing the line drawing manually. So you write the line draw algorithm yourself and use GetPixel and SetPixel to perform the blending. You use GetPixel to get the color of your "target", calculate a new COLORREF using this color and your line color and blending, then you use SetPixel to display the pixel. This method will surely be slow since Get/SetPixel are slugs. The other i can think of is using a device-independent bitmap as a kind of "backbuffer", you place your target image onto this bitmap, do the line drawing and blending manually by directly reading-writing the pixel data of the bitmap (i suggest a 32 bit bitmap for a better speed) and then when you are done drawing all those lines, blit this buffer to the screen. This should be faster.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
|
I assume you did not intend to target that post at me.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
I'll try to answer both...
Alphablend() has a parameter that determines a global transparency. Suppose I want 2 lines with different transparencies i must use Alphablend() 2 times. And drawing 2 times tranparently to the screen will change the original pixels (those that are not from the lines). In other words: I can copy the screen to the memoryDC, draw the line and alphablend it to the screen but then all pixels are changed. This is why a regionobject is required. So the solution of Rejeesh can not work.
The first suggestion of Code-o-mat is too slow. But his 2nd approach may have some opportunities. If i understand you well Code-o-mat essentially you say to me: manipulate the alpha-channel according to the line drawn... Thus if i could draw the line directly in the alpha-channel my problem would be solved. Unfortunally there's not such function... but maybe i can write one...
Maybe an approach can be: create a memoryDC, a 32-BPP bitmap and an addional 8-bit black and white bitmap. Draw the lines on the 8-bit bitmap (and also on the 32-bit bitmap) and finally merge the 8-bit image as an alpha-channel to the 32-bit bitmap. This means: no regions needed, no manual line draws and only one time comsuming operation (the merging of the alpha-channel. Sounds promissing!
Anyone any better ideas?
|
|
|
|
|
Your idea sounds interesting but the merging process might become slow with bigger images.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
Code-o-mat wrote: Your idea sounds interesting but the merging process might become slow with bigger images.
True, but my inital approach wasn't free either 
And maybe you din't realized that, but had to do all the things per line. So 100 lines was 100 buffers, 100 regions, ... Now it seems i have: 1 buffer, no regions, and one time consumer. And the good news is the time consumer has no mults or divides, just some bit shifting. I'm sure performance will be much better... bet it will have a performance like a graphic filter (like emboss for ex.).
I'll try this out in the next days - thanks for the ideas...
Rozis
|
|
|
|
|
Rozis wrote: but MS itself disencourages this...
Microsoft discourages C++, too, but don't let that stop you. 
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
Tim Craig wrote: Rozis wrote:
but MS itself disencourages this...
Microsoft discourages C++, too, but don't let that stop you.
Yep. It says: "Microsoft Windows GDI+ exposes a flat API that consists of about 600 functions, which are implemented in Gdiplus.dll and declared in Gdiplusflat.h. The functions in the GDI+ flat API are wrapped by a collection of about 40 C++ classes. It is recommended that you do not directly call the functions in the flat API. Whenever you make calls to GDI+, you should do so by calling the methods and functions provided by the C++ wrappers. Microsoft Product Support Services will not provide support for code that calls the flat API directly."
What i figure out of their documentation is that the complete GDI+ classes are internally handled by their 'flat API'. This probably means: the flat api will change without any notice.
Maybe the reason they discourages C++ is that they seem to be afraid of classes.
|
|
|
|
|
May be you will have to create 32bpp DIB section and make all your drawing on it. And finally use AlphaBlend() on target DC.
|
|
|
|
|
Hi
I'm trying to get some information about the windows that working in the background.
I'm using the GetWindowRect function and it's never show me information.
here is the relevant part of my code:
BOOL CALLBACK EnumChildProc(HWND hwnd, LPARAM lParam) {<br />
<br />
LPRECT lprect=NULL;<br />
cout << "hwnd_Child = " << hwnd << endl;<br />
SetWindowText(hwnd,NULL);<br />
if(GetWindowRect(hwnd,lprect))<br />
cout<< lprect->bottom<< endl;<br />
<br />
<br />
<br />
<br />
return TRUE;
}
it does change the window's text but doesn't go into the if. any idea why?
by the way how can i find the buttons inside the window?
thanks
Itay
|
|
|
|
|
Using this code : LPRECT lprect=NULL; You are sending a NULL pointer so that will cause GetWindowRect() to fail. Try the following instead:
RECT cRect;
if(GetWindowRect(hwnd, &cRect))
...
and on return cRect should contain the cx and cy values
|
|
|
|
|
Richard MacCutchan wrote:
RECT cRect;
if(GetWindowRect(hwnd, &cRect))
...
thanks. now it is working.
|
|
|
|
|
You can't get the rectangle of windows which do not belong to your own process. However, GetWindowText and SetWindowText do work between different processes. (in case you are enumerating windows of other processes also)
Additionally to what Richard MacCutchan said.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
modified on Tuesday, November 17, 2009 9:34 AM
|
|
|
|
|
Code-o-mat wrote: You can't get the rectangle of windows which do not belong to your own process.
Strange, this restriction is not noted in the MSDN documentation, but it is noted in the doc for Get/SetWindowText()!
|
|
|
|
|
I might be wrong but i think i once wanted to get the rectangle of such windows too and i couldn't get it to work so i googled around and found out that the reason was indeed that GetWindowRect can't cross processes.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
itay10 wrote: LPRECT lprect=NULL;
itay10 wrote: if(GetWindowRect(hwnd,lprect))
You cannot do this.
The pointer must hold the address of a valid struct.
change to:
RECT rect;
if(GetWindowRect(hwnd ,&rect))
BTW: why aren't you calling GetLastError?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
thanks all it worked!
CPallini wrote: BTW: why aren't you calling GetLastError?
I don't know, never tried. how can it help?
|
|
|
|
|
itay10 wrote: how can it help?
Seriously? Did you read the docs to see what it does? Since the condition in the if test evaluated to false, that would indicate that GetWindowRect() returned zero.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
i debugged it and i knew the returned value was zero, the question was why?
|
|
|
|
|
Calling GetLastError() would have likely told you why.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
itay10 wrote: CPallini wrote:
BTW: why aren't you calling GetLastError?
I don't know, never tried. how can it help?
Oh, don't worry about, it's a decorative function... 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
