|
Yes, on screen DC it works perfectly. Always did.
|
|
|
|
|
I've seen that the BitBlt from the dc isn't going to work but using GDI+ to draw a PNG
on the printer dc isn't working? If not then it's a lame driver. It should at minimum
draw without blending/transparency.
|
|
|
|
|
Yes. There's something wrong between my GDI+ and printer. Problem is,
graphics.DrawImage() is void, does not return any values, so I can't check for errors. Is there a special GDI+ initialization for printer device, maybe?
All initialization I am doing is calling GdiplusStartup:
Gdiplus::GdiplusStartup(&m_gdiplusToken, &gdiplusStartupInput, NULL);
|
|
|
|
|
Graphics::DrawImage should return a Status enum == 0 (Gdiplus::Ok) on success.
GDI+ Initialization should be fine as you have it (that's what I'm using):
Gdiplus::GdiplusStartupInput StartupInput();
if (Gdiplus::Ok != Gdiplus::GdiplusStartup(&GdiPlusToken, &StartupInput, NULL))
{
...failed
}
You are using a Graphics object constructed using the printer DC right?
Mark
|
|
|
|
|
Yes, I am passing it a printer's DC.
P.S. Now I am trying to build an separate executable that uses GDI+ (I suspect the image might be not printed because of clipping or something else I don't control, although GDI functions work (wrongly)), and I can't even compile it. Gives me ton of compiler errors. The other project is a DLL, and it compiles fine. Same IDE, Visual Studio 2003. I am having a bad day.
|
|
|
|
|
Have some news. I was able to compile and build the code using GDI+ in a standalone app. It actually printed the image (the DLL using the same code is not printing), not the size I expected, but on a b/w printer it actually printed it with a shadow! On the color printer though, it still ignored background for all pixels with alpha (transparency) values greater than 0. It's still a big step forward. Now I am looking into why it's not working off the DLL, and why it's printing image of a diffferent size.
|
|
|
|
|
Cool
I forgot to mention - are you using StretchBlt or StretchDiBits anywhere still? You may want to
set the stretch mode properly if necessary and restore it after the stretch operation. I noticed
that in the code I've been testing from (although it made no difference in the problem).
To get a blend of more than one alpha-blend image you may need to do it all in a memory DC then
do one blt to the printer DC - I think GDI+ can handle that. I've been unable to get a blend on
a printer DC. The printer DCs behave write-only so any operations requiring reading colors
already there fail...
|
|
|
|
|
Mark, just want to let you know that I finally was able to print PNG with GDI+ correctly (that is, correct size). There's still a minor problem with shadows on color printers, but I can live with it. Apparently, the size of image that I have to pass to DrawImage() is different from that used in StretchDIBits() as destination coordinates. Looks like DGI+ does its own stretching. This is why my original code using GDI+ was returning successful code but did not print: the image was beyond the page size. Thank you for your help.
P.S. Where are you located (physically)?
|
|
|
|
|
Yuriy2003 wrote: just want to let you know that I finally was able to print PNG with GDI+ correctly (that is, correct size).
Good! Glad you got it working, at least for the most part
I'm in CA, USA.
Mark
p.s. Sorry I had to reply to a different message since this forum software fails when the message
heirarchy gets too deep.
|
|
|
|
|
Are you working/employed?
|
|
|
|
|
Yuriy2003 wrote: Are you working/employed?
Both, yes....self employed. You? Why?
|
|
|
|
|
No, I am just working.
Well, I see you post a lot of messages on this forum, so you must have some time for this. My company is hiring people right now, lots of interviews etc. I could recomment/refer you if you are interested, but we're in NJ.
|
|
|
|
|
Yuriy2003 wrote: No, I am just working.
Well, I see you post a lot of messages on this forum, so you must have some time for this. My company is hiring people right now, lots of interviews etc. I could recomment/refer you if you are interested, but we're in NJ.
Cool. I appreciate it. I don't necessarily have the time but I take the time.
I'm at my computer so many hours a day finishing a project I started 5 years ago so I always
have the same solution open on my monitors along with a little test application project
to test code I post in the forums. It's good for me to refresh on things I haven't used in a
long time plus I learn new stuff often so that makes it worth hanging out in the forum.
Otherwise I'm just grinding away at the same GDI/DirectX/Database/Socket code all day long!
Mark
|
|
|
|
|
Five years? What is this project doing?
|
|
|
|
|
Also, you could try BitBlt of the printer DC right to a screen/window DC - that'll show you what's
in the printer DC's bitmap
|
|
|
|
|
Well, I can see it in a debugger too.
|
|
|
|
|
What happens if you create a 32bpp bimap and blt the printer's bitmap to it.
Then you don't have to worry about the printer's bitmap format.
// hDC is printer's DC in this case
HDC hCaptureDC = CreateCompatibleDC(hDC);
// img structure contains width, height, etc. for the image
HBITMAP hCaptureBitmap = CreateBitmap(img->width, img->height, 1, 32, NULL);
HGDIOBJ h = SelectObject(hCaptureDC, hCaptureBitmap);
ret = BitBlt(hCaptureDC, 0, 0, img->width, img->height, hDC, x, y, SRCCOPY);
|
|
|
|
|
CreateCompatibleBitmap() is supposedly safer. This is why I am using it.
|
|
|
|
|
I don't know about safer - I know it's more efficient in certain situations.
For a single Blt it doesn't make much difference as far as I know.
|
|
|
|
|
Yuriy2003 wrote: Five years? What is this project doing?
Client/Server/Imaging/Database/Teleconferencing/Video/Audio/Hardware-interfacing
Oh, and UI
Still shouldn't have taken so long but specs changed, technology changed, and misc. other
excuses
Mark
|
|
|
|
|
Well, if this is what you do for living, I guess it sells quite well. Web-based? Are you doing it just yourself or with somebody?
|
|
|
|
|
Not web based. I've done all the coding and I have a partner who handles the business.
Mark
|
|
|
|
|
That's cool. At least you work for yourself, which is a fantastic thing. Good luck. If you happen to be in Princeton area, let me know, we'll have a drink.
|
|
|
|
|
Thanks! I may just be out to that end of the country in the upcoming months.
Take care,
Mark
|
|
|
|
|
I made a few futile attempts to get CMap working ... Basically, I need:
Key CString
Value CString
What I did... after readingthis articlewas:
1. Declaration:
CMap<cstring, lpctstr,="" cstring,="" lpctstr=""> m_Result;
2. Adding elements/association:
CString sKey;
CString sVal;
m_Result.SetAt((LPCTSTR) &sKey, (LPCTSTR) &sVal);
3. *trying to* access elements
CString csVal;
I tried:
csVal = m_Result[(LPCTSTR) &csKey];
I also tried:
bSuccess = m_Result.Lookup(csKey, csVal);
The problem is, csVal always returns "nothing" (i.e. an empty/blank string)...
4. I've already implemented HashKey
<br />
inline UINT AFXAPI HashKey(const CString& str)<br />
{<br />
...<br />
<br />
return nHash;
}<br />
<br />
<br />
inline UINT AFXAPI HashKey(CString& str)<br />
{<br />
...<br />
<br />
return nHash;
}<br />
MSDN
REF 1 CMap Lookup[^] REF 2 CMap[^]
REF 3 Sample download MFC Collection classes[^]
Code Project
humm... [^]
-- modified at 20:52 Friday 29th December, 2006
Norman Fung
|
|
|
|