|
Any help out there?
Thanks.
TomH
TomH
|
|
|
|
|
Hey all,
I need a little help with printing. I have it all ready to print and it print fines, but I coded it stupidly. I hard coded the coordinates of where the text is printed, so it only prints correctly on certain printers, on others it prints all messed up. So now I am trying to change it so that it works right with all printers. This is what I have done so far.
<br />
<br />
CPrintDialog dlg(FALSE); <br />
CDC dc; <br />
#if 0 <br />
if (dlg.DoModal() == IDCANCEL) <br />
return; <br />
dc.Attach(dlg.GetPrinterDC());<br />
#else <br />
PRINTDLG prtDlg; <br />
AfxGetApp()->GetPrinterDeviceDefaults(&prtDlg); <br />
dlg.m_pd.hDevMode = prtDlg.hDevMode; <br />
dlg.m_pd.hDevNames = prtDlg.hDevNames; <br />
dc.Attach(dlg.CreatePrinterDC());<br />
#endif <br />
dc.m_bPrinting = TRUE; <br />
<br />
<br />
CRect printArea;<br />
printArea.SetRect(printArea.left/2, printArea.top/2, dc.GetDeviceCaps(HORZRES), dc.GetDeviceCaps(VERTRES));<br />
<br />
CString str("Delayed Entry");<br />
dc.DrawText(str, printArea, DT_NOPREFIX | DT_WORDBREAK);<br />
<br />
When I try that out it compiles fine, but when I print it it doesn't work, can anyone help me out here?
Thanks
|
|
|
|
|
Eversman wrote:
...it doesn't work, can anyone help me out here?
What doesn't work? What is the code (not) doing? What are you wanting it to do? Be a little more specific instead of just "it doesn't work" and you'll get much more help.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Well it doesn't print, it prints the old stuff that I had hard coded in, but when I change it to the new way I just showed, it doesn't print, well maybe it does but it would be off the page when it printed.
I am not sure if I am using the GetDeviceCaps and that such correctly.
|
|
|
|
|
Eversman wrote:
CRect printArea;
printArea.SetRect(printArea.left/2, printArea.top/2, dc.GetDeviceCaps(HORZRES), dc.GetDeviceCaps(VERTRES));
This should raise a red flag. You have a variable printArea that has not been initialized/assigned a value, yet you are trying to use its left and top members. Is that intentional?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Well, I am using this example that I found in the printing section. This is what the tutorial has it as.
<br />
<br />
CRect rect;<br />
rect.left = (JRECT.Width() - size.cx)/2;<br />
rect.right = rect.left + size.cx;<br />
rect.top = (JRECT.Height() - size.cy)/2;<br />
rect.bottom = rect.top + size.cy;<br />
<br />
JDC.DrawText(str, &rect, DT_SINGLELINE);<br />
<br />
so I kinda modified it to fit what I already had. No where in the example that I see is that stuff initialized. But I need to initialize it to the printer page resolution right? So would I have to initialize it to HORZRES and VERTRES?
|
|
|
|
|
Eversman wrote:
No where in the example that I see is that stuff initialized.
You're kidding, right? Two-thirds of the lines you've shown are initializing variables. When DrawText() is called, rect has all the right numbers.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
During porting the VCF to osx I came across a distinction that Apples uses - the notion of a composited window, where a window is the popup window where all the child controls live. While I was debugging something on OSX I found that if a window was marked as being composited ALL the child controls used the same graphics device to paint on during their paint event.
So, while I don't know how Apple does this, I started to wonder about this on Win32. What would happen if you maintained a map of popup windows and bitmap hdc's such that for each popup window you had one in-memory bitmap DC that was the height/width of the popup window. When the window was resized so would the bitmap. Then, for all the child control drawing, they would draw onto a section of this main DC, and then just bitblt the relevant part back to the HDC passed in to the WM_PAINT.
This would give you:
- automatic double buffering without each control having to maintain a separate bitmap/memory dc
- the ability to draw "outside" the edges of your control, for example if you wanted a "glow" effect on the edges of your control this would make this possible.
- possibly more efficient transparency effects that because you are reusing the same DC to paint on.
I would be curious to hear what others think. Has this been done before? If so did it work very well? Am I totally out of my mind?
Cheers
Jim
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
|
|
|
|
|
Sounds interesting. The child controls would need to be either rewritten or subclasses to use the new DC as the WM_PAINT message doesn't include a DC. Other than that, I think it has potential. I guess you'd BitBlt() the memory DC to the screen when the parent processes the WM_PAINT message as the children are always drawn first.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
|
Yeah, I've seen that before too  . And it would be good if it worked, but as it says, some common controls check this parameter, not all. And Windows itself never sets the wParam parameter; the WM_PAINT documentation states that wParam is unused. I've always thought this lack of DC was a very bad oversight.
But still, it could be useful
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
You get a WM_PAINT so you call BeginPaint and get a PAINTSTRUCT which has a DC as its first field. This is where the drawing should occur.
|
|
|
|
|
Blake Miller wrote:
You get a WM_PAINT so you call BeginPaint and get a PAINTSTRUCT which has a DC as its first field. This is where the drawing should occur.
Yeah, but applications have no control over that. The DC is defined by Windows, and is not given in the WM_PAINT message.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi All,
I'm using a CListCtrl in a dialog, and I've noticed that when it has the focus, the tab key will not cause it to change the focus to the next control in the tab order. Does anyone know what's up w/ this?
Note that OnGetDlgCode() is returning DLGC_WANTALLKEYS because I want to capture the Enter key. When I remove DLGC_WANTALLKEYS, the tab key changes the focus like I'm expecting, but it's a problem because I need to capture the Enter key.
How can I have my cake, and eat it too?
Thanks!!!
|
|
|
|
|
Try to narrow the problem down a bit. Does it happen with all projects or just this one? If the latter, does it happen with all list controls or just one in particular?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Thanks for the reply! It was happening in every instance where my List Control was using my CListCtrl derived class that returned DLGC_WANTALLKEYS from OnGetDlgCode().
I came up a fix for it tho, which was to manually set the focus to the next window in the z-order (z-order == tab order).
Here's what my fix looked like:
BOOL CListCtrlEx::PreTranslateMessage(MSG* pMsg)
{
if( pMsg->message == WM_KEYDOWN && pMsg->wParam == VK_TAB )
{
CWnd * pNext = GetWindow(GW_HWNDNEXT);
CWnd * pFirst = pNext ? NULL : ( pNext = GetWindow(GW_HWNDFIRST) );
while(pNext)
{
DWORD dwStyle = pNext->GetStyle();
if( dwStyle & WS_TABSTOP
&& pNext->IsWindowVisible()
&& pNext->IsWindowEnabled()
&& pNext->GetSafeHwnd() != m_hWnd )
{
pNext->SetFocus();
return FALSE;
}
pNext = pNext->GetWindow(GW_HWNDNEXT);
if( pNext == NULL && pFirst == NULL )
{
pNext = pFirst = GetWindow(GW_HWNDFIRST);
}
}
}
return CListCtrl::PreTranslateMessage(pMsg);
}
|
|
|
|
|
i want to dynamically create a tabctrl and add tabs dynamically to it. Also teh controls rendered on each tab will be dynamically created. Any suggestion of how it can be achieved.
|
|
|
|
|
i am successfully able to create the tabcontrol using the cdialog extended class as tabs. what is the difference in "can do and cannot do" if a property sheet is used instead? Which of the two is better to use and why?
|
|
|
|
|
Hi all,
I have a uchar array containing values of either 0 or 255 (ie monochrome) and am trying to BitBlt it into a window using the memory DC buffering to avoid flicker (ie creating a compatible memory DC, selecting a bitmap then BitBlting it to the window DC). The window is of the same size/slightly smaller.
1) I first attempted to use CreateCompatibleBitmap route (which I thought would be simplest?), using SetBitmapBits etc. The result was that the image was displayed twice in the top 2 quarters of the window, with nothing in the bottom half.
2) I also went down the CreateBitmapIndirect route using a BITMAP structure I managed to display only the first part of the array, which stretched to fill the bitmap. It looks like each 8 bit pixel value is being used to fill 8 pixels in the display, but I can't find how to set it to use 8 bits per pixel, without having to create a DIB type structure? (Setting the 255 values to 1 results in the same effect, but where there were 8 white pixels there are now 1 white and 7 black)
I really could do with using the Bit Blt function to run the process as fast as possible - can anyone suggest a solution?
Any help greatly appreciated - thanks!
|
|
|
|
|
what's wrong with just using a monochrome DIB?
set up the BITMAPINFOHEADER and palette, put your pixels into the rows, top-down, with padding on the ends of the rows to ensure that they're a multiple of four bytes wide.
-c
Software | Cleek
|
|
|
|
|
I have a control that subclasses CButton and I need it to be _exactly_ 256x256 pixels...
How can I set the exact Size of a control? I've tried editing the .rc, but the measures are given in DLUs...
Thank you people!!
|
|
|
|
|
MoveWindow???
How do I print my voice mail?
|
|
|
|
|
Thanks for your reply!
I was meaning at design time, not at runtime... I've fixed it temporarily with on-the-fly resizing during initialization... But I'd like to know if there is a standard method...
|
|
|
|
|
we/you can't really make a button have fixed PIXEL size in the resource editor, the units are DLUs, Dialog Logic Units, and are proportional to some windows dohickey ( big font, small font, ... ).
the only way to do it, is to use MoveWindow in the the dialog initialization, but watch out for big font vs. small font settings.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Don't waste your time. Thinking about pixels at design time is a sure recipe for failure. The whole reason, and beauty, for having DLUs is so that pixels do not matter. Otherwise, the controls will work on one machine and one machine only...yours. On any other machine, the results will be less than desireable. Things like resolution, font size, display driver, etc. will wreak havoc on your application.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
