|
I am reading Petzold's book on Win32 and I am at the chapter concerning printing. He gives an example which is supposed to find out the current version of windows you are running and then call EnumPrinters(). I can't compile this code I get the error: error C2440: '=' : cannot convert from 'void *' to 'struct _PRINTER_INFO_5A *'
Conversion from 'void*' to pointer to non-'void' requires an explicit cast.
By casting it to pInfo5 = (PRINTER_INFO_5*) malloc(dwNeeded); it compiles but then the program crashes when I try to print...it is the 5th parameter of EnumPrinters which is causing the problem. My question is what code changes do I need to make to this into C++ using new and delete and in general what would be a better way of writing this function? (Modifications in the code would by much appreciated)
HDC GetPrinterDC (void)
{
DWORD dwNeeded, dwReturned ;
HDC hdc ;
PRINTER_INFO_4 * pinfo4 ;
PRINTER_INFO_5 * pinfo5 ;
if (GetVersion () & 0x80000000)
{
EnumPrinters (PRINTER_ENUM_DEFAULT, NULL, 5, NULL,
0, &dwNeeded, &dwReturned) ;
pinfo5 = malloc (dwNeeded) ;
EnumPrinters (PRINTER_ENUM_DEFAULT, NULL, 5, (PBYTE) pinfo5,
dwNeeded, &dwNeeded, &dwReturned) ;
hdc = CreateDC (NULL, pinfo5->pPrinterName, NULL, NULL) ;
free (pinfo5) ;
}
else
{
EnumPrinters (PRINTER_ENUM_LOCAL, NULL, 4, NULL,
0, &dwNeeded, &dwReturned) ;
pinfo4 = malloc (dwNeeded) ;
EnumPrinters (PRINTER_ENUM_LOCAL, NULL, 4, (PBYTE) pinfo4,
dwNeeded, &dwNeeded, &dwReturned) ;
hdc = CreateDC (NULL, pinfo4->pPrinterName, NULL, NULL) ;
free (pinfo4) ;
}
return hdc ;
}
|
|
|
|
|
With the casting changes, the code works perfectly on my XP system. The code should work. Also, there is no reason to change the code to use new/delete. It will only complicate the code and gain you nothing.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
The cast is necessary because of stricter type rules in C++. C allows implicit conversion to and from void*, while C++ only allows implicit conversion to void*. Therefore you need to cast the void* returned by malloc.
Not sure about the crash, your code (well, the NT branch at least) works fine for me.
--Mike--
I'm bored... Episode I bored.
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Does the crash have anything with me not having a printer actually connected to my computer? In debug mode dwNeeded had a value of zero and I guess this is what causes the crash on the second call to EnumPrinters a value I suppose will increase once I attach a printer. And is this the proper way to cast it?:
pinfo4 = (PRINTER_INFO_4*) malloc (dwNeeded);
Thanks for all the help so far.
|
|
|
|
|
Yeah. His code lacks the test for dwNeeded returning 0. If that is the case, there is really no need to even do a malloc and the second enum call. Just return a NULL HDC and be done with it. Of course, all calling programs should test for NULL HDC.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I'm looking for a library that I could use to write a small program that only sends e-mails (no reading). Can anyone suggest one?
Thanks!
|
|
|
|
|
|
|
I have an application who splits the window in two, similar to windows explorer. I need to print the contents of the right side, but I can only capture printing messages on the left window.... I was thinking of cathing the messages in one window and sending them to the other. Is this a good idea or is there a better way ?
Thank you
Nelson Gonçalves
|
|
|
|
|
Hi.
I am having problems "painting" a Picture Control on a MODELESS dialog. My dialog (called GraphicsParams) has a picture control that calls CColorDialog and allows the user to select a color. The picture control (color swatch) is then painted with the color selected.
My problem is that my picture control is not updated with the current color in OnInitDialog(). Further more, I experience the weird side in my GraphicsParams dialog:
1) place another window (dialog) object over my Color Swatch client area
keeping it over my Color Swatch
2) Set focus back to my GraphicsParams dialog -- don't move
3) Without moving either dialogs, toggle focus between the two
** the color swatch resorts back to the default (black) color.
Would you know what is going on and what I need to do?
Thanks.
Johnny
Here is what I have now:
//////////////////////////////////////////////////////
// CGraphicsParameters dialog -- .H
class CGraphicsParameters : public CDialog
{
// Other stuff left out for brevety
private:
// use to display colors as a sample swatch on the dialog
COLORREF m_ModelColor;
CRect m_ModelColorSwatch;
// Construction
public:
// use to display colors as a sample swatch on the dialog
void SetModelColorSwatch(COLORREF rgbColor);
}
//////////////////////////////////////////////////////
// CGraphicsParameters dialog -- .CPP
BOOL CGraphicsParameters::OnInitDialog()
{
CDialog::OnInitDialog();
// other dialog initialization goes here
// Initialize the color swatch rectangles - for later painting
// Calculate true location of the color swatch
// Get a pointer to CWnd
CWnd* pModelColor = GetDlgItem(IDC_MODEL_COLOR);
// Find its location on screen
pModelColor->GetWindowRect(&m_ModelColorSwatch);
// Store client coordinates
ScreenToClient(&m_ModelColorSwatch);
m_ModelColorSwatch.DeflateRect(2, 2, 1, 1); // for the sunken control setting
SetModelColorSwatch(m_ModelColor);
return TRUE;
}
void CGraphicsParameters::OnPaint()
{
SetModelColorSwatch(m_ModelColor);
CDialog::OnPaint();
}
// callback function for changing the model color - uses MFC common color dialog
void CGraphicsParameters::OnModelColor()
{
CColorDialog dlg(m_ModelColor, CC_FULLOPEN);
if (dlg.DoModal() == IDOK)
{
m_ModelColor = dlg.GetColor();
SetModelColorSwatch(m_ModelColor);
}
}
// update the color swatch with the RGB color value
void CGraphicsParameters::SetModelColorSwatch(COLORREF rgbColor)
{
CBrush swatch;
swatch.CreateSolidBrush(rgbColor);
CClientDC dc(this);
dc.FillRect(&m_ModelColorSwatch, &swatch);
}
|
|
|
|
|
I have seen the sample code for my use. But I forgot to save it. Now I cannot remember its location.
The code implements a list control, almost as the same as in VC6 under Options -> Paths -> Paths:. The user can create a new item by clicking the rectangle with a star, and delete it with the red cross. He can also move an item up and down with the other Up- and Down arrows.
Who can plz help me to find it? Thanks!
|
|
|
|
|
|
Hey,
does anyone know what message is being sent when the mousepointer is over a tab in a tabcontrol? My problem is that the things I have drawn inside a tab is flickering when I move the mouse over the tabs. Might be some message painting the tabs yellow in WinXP? When I switch the tablayout to buttons the problem disappears...
Cheers
|
|
|
|
|
I writing my menu by LoadMenuIndirect function. I saw my menu with Debug mode but I dont' see it with Release mode ! Why ?
|
|
|
|
|
How are these right hand corner notifications are launched by msn or McAfee or others to name a few?
|
|
|
|
|
|
Hi, this may be a stupid question, but could someone please tell me how to start a help file (which is in html format by the way), from MFC? I've tried both WinExec and CreateProcess, but neither work. Secondly, if the help file gets big enough to where i can make a .chm out of it, could i use the same method?
|
|
|
|
|
For compled help files (.chm) use the function HtmlHelp(
HWND hwndCaller,
LPCSTR pszFile,
UINT uCommand,
DWORD dwData) ;
It's really easy to use. I personally wouldn't use pure .html files - .chm is more user-friendly, providing easy navigation.
Btw: That function is declared in htmlhelp.h, and you need to link to htmlhelp.lib to get it work.
|
|
|
|
|
|
One thing you may have to consider is that you will have to heavily customize certain parts of tyour app if you want the help to be fully integrated, such as having a "Help" button on a dialog, context sensitive help etc.
You will need to override
virtual void CWinApp::WinHelp( DWORD dwData, UINT nCmd = HELP_CONTEXT );
as well as some of the other help messages
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
|
|
|
|
|
Hi, I am writing a modal dialog app without any MFC. I am painting the window
myself by handling the WM_PAINT messages (using a dc in mem to draw to and then using BitBlt).
The problem is when the dialog is moved very rapidly around the screen it
sometimes stops being drawn correctly. The dialog is then drawn as garbage like parts of the desktop, or is drawn only partially correctly.
Am I allowed to draw to areas of the dc in mem that will later be "covered" by edit boxes or static bitmaps (defined in the dialog resource)? Is this
the problem?
Here's the relevant code in the dialog proc:
case WM_PAINT:<br />
{<br />
BeginPaint(hWnd, &ps);<br />
Paint(hWnd, &ps);<br />
EndPaint(hWnd, &ps);<br />
break;<br />
<br />
<br />
}<br />
<br />
case WM_ERASEBKGND:<br />
return (LRESULT)1;
<br />
<br />
case WM_CTLCOLOREDIT:<br />
{<br />
SetBkMode((HDC)wParam,TRANSPARENT);<br />
SetBkColor((HDC)wParam,RGB(192,192,192));<br />
SetTextColor((HDC)wParam,RGB(0,0,0));<br />
return (BOOL)Back; <br />
}
Code for painting:
static void Paint(HWND hWnd, LPPAINTSTRUCT lpPS)<br />
{<br />
RECT rc;<br />
HDC hdcMem;<br />
HBITMAP hbmMem, hbmOld;<br />
HBRUSH hbrBkGnd;<br />
<br />
<br />
GetClientRect(hWnd, &rc);<br />
<br />
<br />
hdcMem = CreateCompatibleDC(lpPS->hdc);<br />
<br />
<br />
hbmMem = CreateCompatibleBitmap(lpPS->hdc,<br />
rc.right-rc.left,<br />
rc.bottom-rc.top);<br />
<br />
<br />
hbmOld =(HBITMAP)SelectObject(hdcMem, hbmMem);<br />
<br />
<br />
hbrBkGnd = CreateSolidBrush(GetSysColor(COLOR_WINDOW));<br />
FillRect(hdcMem, &rc, hbrBkGnd);<br />
DeleteObject(hbrBkGnd);<br />
<br />
<br />
<br />
<br />
<br />
SetBkMode(hdcMem, TRANSPARENT);<br />
<br />
<br />
HPEN MyPen;<br />
HBRUSH MyBrush;<br />
<br />
MyPen=CreatePen(PS_SOLID,1,RGB(96,96,96));
MyBrush = CreateSolidBrush(RGB(96,96,96));<br />
SelectObject(hdcMem,MyPen);<br />
SelectObject(hdcMem,MyBrush);<br />
<br />
Rectangle(hdcMem,0,0,600,600);<br />
<br />
MyPen=CreatePen(PS_SOLID,1,RGB(0,0,0));
MyBrush = CreateSolidBrush(RGB(192,192,192));<br />
SelectObject(hdcMem,MyPen);
SelectObject(hdcMem,MyBrush);<br />
<br />
Rectangle(hdcMem,5,5+17,546,385+17);
<br />
MyPen=CreatePen(PS_SOLID,1,RGB(192,0,0));<br />
MyBrush=CreateSolidBrush(RGB(192,0,0));<br />
SelectObject(hdcMem,MyPen);<br />
SelectObject(hdcMem,MyBrush);<br />
<br />
Rectangle(hdcMem,10+xBuggy*40,10+(9-yBuggy)*40,20+xBuggy*40,20+(9-yBuggy)*40);
<br />
MyPen=CreatePen(PS_SOLID,1,RGB(0,0,0));
SelectObject(hdcMem,MyPen);
<br />
int xPos=15;<br />
int yPos=15;<br />
<br />
while(xPos<=570)
{<br />
MoveToEx (hdcMem, xPos, 15+17, 0);<br />
LineTo (hdcMem, xPos, 375+17);<br />
xPos=xPos+40;<br />
}<br />
<br />
<br />
while(yPos<=400)
{<br />
MoveToEx (hdcMem, 15,yPos+17, 0);<br />
LineTo (hdcMem, 535, yPos+17);<br />
yPos=yPos+40;<br />
}<br />
<br />
<br />
<br />
<br />
DeleteObject(MyPen);<br />
DeleteObject(MyBrush);<br />
<br />
<br />
<br />
BitBlt(lpPS->hdc, <br />
rc.left, rc.top,<br />
rc.right-rc.left, rc.bottom-rc.top,<br />
hdcMem,<br />
0, 0,<br />
SRCCOPY);<br />
<br />
<br />
SelectObject(hdcMem, hbmOld);<br />
DeleteObject(hbmMem);<br />
DeleteDC(hdcMem);<br />
<br />
}
|
|
|
|
|
Hi
I am writing a program to process multiple independent datas. This program is very processing intensive. So i am wondering if multi threading would help to reduce the amount of processing time.
I have doubts over it because I have only one processor. So wouldn't the time taken for the processing to be the same in multithreading case (or even more due to addition overhead)?? If it helps to cut down the time taken, how does it do it with only one processor?? Can someone please enlighten me ??
Thank you very much for the kind attention !!
|
|
|
|
|
boon kian wrote:
So wouldn't the time taken for the processing to be the same
Maybe, but your App stays responsive.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
boon kian wrote:
So i am wondering if multi threading would help to reduce the amount of processing time.
Not using a single CPU. Quite the opposite; the overhead will make the processing slower.
If the process is e.g. I/O bound the percieved speed of the application might benefit greatly from multithreading, but the total CPU time used will always be greater for a multithreading program than a singlethreded program (even if by such a small amount of time that one wouldn't even bother to try measure it).
|
|
|
|
|
I agree with the above posts, but there are some things you may want to consider...
First, the user usually despises apps that appear "frozen" and unresponsive. If you go calling a time-consuming data reduction function from the main UI thread, your app will appear to "hang" during processing. If you don't pump update messages and redraw the screen, the user can slide another window over your app, and your app will just appear blank and dead.
However, don't go off spawning 20 threads to process your stuff either! I would definately consider putting the data reduction algorithms in a seperate "worker" thread, and pumping progress messages from within it. Although you won't gain any speed (or may actually lose some), it is most likely in the best interest of the user.
This will keep your UI happy and responsive, and the world will be a better place 
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
