|
They all report DT_RASPRINTER.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Hey Code-o-mat,
As Richard pointed out display device contexts always support alpha blending! If the return value is SB_CONST_ALPHA then it means the alpha blending will be performed using hardware acceleration. In fact I don't think Microsoft will ever add hardware acceleration to GDI. With Windows8 Metro they are moving towards Direct2D[^] 
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks for the reply. I read that but my DC!s are (sometimes) for printers. However, to save on paper/ink money i am using a few "virtual" printers (like Cute PDF Writer) to print to files. Maybe these virtual drivers! DC will "function" as a screen DC rather than a printer DC when drawing onto, i will check that (with GetDeviceCaps + TECHNOLOGY) and report back what i have found.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Hey Code-o-mat,
Sorry about the late reply... I was out of the office today. One thing that I have learned over the years is that printer drivers often report incorrect capabilities. Generally there is not much that can be done about these edge cases. I've had similar experiences to yours when dealing with virtual device drivers.
Best Wishes,
-David Delaune
|
|
|
|
|
So i did some testing and all the virtual printer drivers say they are DT_RASPRINTER. None of them report to support AlphaBlend but by forcing them to use AlphaBlend anyways some of them succeed.
Another question came up, if a printer device reports blit support (RASTERCAPS -> RC_BITBLT), does that mean you can also blit from the device or only that you can blit to it?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Code-o-mat,
The author of the printer driver reports the device capabilities. And because everyone's cousin and grandma is a software engineer these days... using software is like a box of chocolates... you never know what your gonna get.
Code-o-mat wrote: Another question came up, if a printer device reports blit support (RASTERCAPS -> RC_BITBLT), does that mean you can also blit from the device or only that you can blit to it?
Bit-block transfers are suppose to be a two-way street. When you call BitBlt on a printer device context... the win32 subsystem performs some internal magic and then end up calling the printer drivers DrvBitBlt function[^]. If the device driver does not implement DrvBitBlt... it uses the default EngBitBlt function[^] (This is what the Gdi32 BitBlt uses via SYSCALL... it forwards to win32k.sys!NtGdiEngBitBlt)
Come to think of it... this is probably why some of the virtual printer drivers you are testing support alpha blending... the driver probably does not implement DrvAlphaBlend [^]so it ends up calling the EngAlphaBlend function[^].
Maybe you should consider giving your employer or users the option of using an open-source virtual printer such as Virtual Image Printer[^]. At least you would have some consistency.
I've been through similar battles with virtual USB, virtual serial and virtual printer drivers. I am very happy that Microsoft is forcing x64 device drivers to be signed. Unfortunately user-mode printer drivers are still a crapshoot.
Best Wishes,
-David Delaune
|
|
|
|
|
Guess i will just have to live with it.  Thanks. I tried blitting from the printer device (it reported it supports it) but all i get is blackness. This complicates my life a lot...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
actually in XP the GetDeviceCaps returns support for acceleration (3=SB_CONST_ALPHA|SB_PIXEL_ALPHA). In a remote desktop session on same computer the return value is zero. The odd thing is, in Windows 10 it also returns 0, odd because you would expect once it was supported it will stay supported.
|
|
|
|
|
Hi,
Sorry about the late reply. It's the Thanks Giving holiday here. It has also been 7 years since I wrote the above comment which appears to be completely correct.
arnoudmulder wrote: In a remote desktop session on same computer the return value is zero. The odd thing is, in Windows 10 it also returns 0, odd because you would expect once it was supported it will stay supported.
I believe that this CDC::GetDeviceCaps behavior over "Remote Desktop" is because your code is not using the physical hardware display driver. I believe over RDP you are actually using the "RDP Encoder Mirror Driver" object located at (%WinDir%\system32\drivers\rdpencdd.sys) which does not have hardware acceleration.
In other words... the return value from CDC::GetDeviceCaps is correct.
Best Wishes,
-David Delaune
|
|
|
|
|
Hi there,
I'm using VC++ 7.0 wherein I'm trying to launch an exe using CoCreateInstance.
I've the executable path, but don't want to run thru the entire process list to find out the process id.
So is there a way to get the process ID directly from an CoCreateInstance for an executable of type CLSCTX_LOCAL_SERVER?
thanks in advance.
regards,
Rajesh
|
|
|
|
|
|
The first link you provide, while interesting, has nothing to do with the question.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
If the local COM server is your code, then you could implement an interface that would tell you that.
However, in general, it's not possible -- by design.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
Hi,
We have a peculiar problem, our application label font changes to bold after we lock and unlock the workstation. This started happening after we changed to Visual Studio 2010. Does anyone have solution to this? I used SPY++ on a label to see what kind of messages that are sent but I don't see anything related to the fonts, below is the SPY++ log:
<00001> 00080608 S WM_NCPAINT hrgn:00000001
<00002> 00080608 R WM_NCPAINT
<00003> 00080608 S WM_ERASEBKGND hdc:2F010CAB
<00004> 00080608 R WM_ERASEBKGND fErased:True
<00005> 00080608 P WM_PAINT hdc:00000000
<00006> 00080608 S WM_NCPAINT hrgn:00000001
<00007> 00080608 R WM_NCPAINT
<00008> 00080608 S WM_ERASEBKGND hdc:5D010EE2
<00009> 00080608 R WM_ERASEBKGND fErased:True
<00010> 00080608 S WM_GETTEXTLENGTH
<00011> 00080608 R WM_GETTEXTLENGTH cch:3
<00012> 00080608 S WM_GETTEXTLENGTH
<00013> 00080608 R WM_GETTEXTLENGTH cch:3
<00014> 00080608 S WM_GETTEXT cchTextMax:8 lpszText:0012D9D0
<00015> 00080608 R WM_GETTEXT cchCopied:3 lpszText:0012E41C ("SKU")
Thank you so much for any help on this...
|
|
|
|
|
Is this label a simple CStatic or your own control or just some text written onto a the window using its client DC? In my experience when a font that was in use gets deleted the system starts using the System font which kind of looks like a bold font, are you sure it's the ffon't weight that changes for you and not the used font itself? Another thing that can cause this if windows for some reason runs out of free GDI resources.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
I have follow code :
typedef struct ItemData
{
LPCTSTR lpszString;
ItemData();
ItemData(LPCTSTR lpszStringInit);
virtual ~ItemData();
};
CMyControl::ItemData::ItemData(LPCTSTR lpszStringInit)
{
lpszString = lpszStringInit;
}
I'm not sure if 'lpszString = lpszStringInit' line is correct .... is it ?
Thank you.
|
|
|
|
|
I think its correct. Why you are not sure?
|
|
|
|
|
Am study a little bit the problem and I found that LPCSTR is const char* and I try it to modify with lpszString = lpszStringInit ... I'm wrong ?
|
|
|
|
|
I try also to modify LPCTSTR lpszString; data member to LPSTR lpszString; but I don't know how to copy an LPCTSTR to LPSTR ...
|
|
|
|
|
Is your code compiling?? and put a debug point at
Flaviu2 wrote: lpszString = lpszStringInit;
and see if the value is getting pased
Every new day is another chance to change your life.
|
|
|
|
|
In most of cases, but I meet a situation that in lpszString I have bugs ...
|
|
|
|
|
|
|
|
Syntactically it's correct. Semantically however... only you can say if it is.
What you are doing there is take a pointer to a string and copy it to another pointer. Now both pointers point to the same string. This may be ok, but what if the argument passed to this function was a temporary object and is deleted later? In that case the pointer lpszString in your class will be invalid! Or, even worse, if the string later gets changed somewhere, this will effect your ItemData struct as well! Do you want that?
Advice: Unless you are totally certain no one else but you will ever use this struct ItemData and potentially use it in the way described above, you should take precautions against that: instead of just copying the pointers, you should copy the entire string! Of course, if you do that you should also delete that string in your destructor. It should be roughly like this (didn't actually try it out):
CMyControl::ItemData::ItemData(LPCTSTR lpszStringInit)
{
if (lpszStringInit != 0 {
std::size_t length = _tcslen(lpszStringInit);
lpszString = new TCHAR[length+1];
_tcscpy(lpszString, lpszStringInit);
}
else {
lpszString = 0;
}
}
CMyControl::ItemData::~ItemData() {
delete [] lpszString;
}
Now you're sure your ItemData object contains it's own copy that cannot be changed or deleted from the outside, no matter who uses this struct. And you know this copy will be deleted exactly when the ItemData object gets deleted. so there will be no memory leaks caused by your struct.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
