|
I found the answer.
StretchDIBits(
hDC, // hDC
10, // DestX
10, // DestY
(int) sizePrn.cx, // nDestWidth
(int) sizePrn.cy, // nDestHeight
0, // SrcX
0, // SrcY
sizeClient.cx, // wSrcWidth
sizeClient.cy, // wSrcHeight
lpDIBBits, // lpBits
&bmInfo, // lpBitsInfo
DIB_RGB_COLORS, // wUsage
SRCCOPY); // dwROP
Change sizePrn.cx, sizePrn.cy can resize the print out.
Kevin
|
|
|
|
|
I need to modify CxImage library function to include CArray as a parameter.
I have no clue how to include reference to afxtempl.h in CxImage project library.
I am basically asking how to add to current CxImage library.
I tried to use plain #include preprocessor directive but I get a error saying that I am trying to include stuff which is already included in window.h header.
Using VC 6.0 and MFC.
Thanks for your help.
Thanks for your help.
Vaclav
|
|
|
|
|
Vaclav wrote: I tried to use plain #include preprocessor directive but I get a error saying that I am trying to include stuff which is already included in window.h header.
If it says that, then it must be there already, surely ?
Why do you want to do this ? One way out would be to ditch CArray ( which is crap ) and use std::vector. I doubt that's already been included by windows.h 
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote: One way out would be to ditch CArray ( which is crap )
I see people say this all the time. Why is CArray "crap"?
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Because it's a quick and dirty array class designed to keep people going until the STL arrived. It was never a long term solution. Sure, it's a container, it will hold stuff. But when you go shopping for a hammer, do you buy the hammer you need today, or the one you can foresee needing in the future ? One day, you're going to want to do something that std::vector supports and CArray doesn't. Or, you'll need to create a container of objects in a non-MFC environment. Two good reasons to learn standard C++, and use vector.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
This isn't an argument describing why CArray is "crap". It's an explanation of why you think it exists.
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Do you disagree with my suggested reason ? I just now saw someone else advising someone not to use CMap, for the same reasons.
And I gave two reasons. Here's another. STL containers all use the same iterators, making it trivial to use data between, say, a list and an array. The MFC containers do not have this ability.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote: Do you disagree with my suggested reason ? I just now saw someone else advising someone not to use CMap, for the same reasons.
But you didn't give a reason that you think CArray (and I suppose all the other MFC collection classes) is "crap". Saying it's "crap" implies that it doesn't do the job it's intended to do, or is rife with bugs, thus making it unusable.
Christian Graus wrote: STL containers all use the same iterators, making it trivial to use data between, say, a list and an array. The MFC containers do not have this ability.
And I argue that you don't have the burden of managing iterators to traverse a CArray. Does that make the STL vector crap? No. It makes it different.
Your arguments sound more generally anti-MFC than anti-CArray. I haven't looked, but aren't the new MFC 7.0-8.0 collection classes wrappers for STL now. I heard CString is supposed to be.
I put it to you - CArray isn't "crap", it's just different. It's no less powerful in the hands of someone that knows what it can/can't do.
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: Saying it's "crap" implies that it doesn't do the job it's intended to do, or is rife with bugs, thus making it unusable.
You're right. And you'll note, I backtracked a little, as a result. CArray will do what it claims to do, it just does the bare minimum, in a platform dependent manner, when a far superior, cross platform alternative exists.
John Simmons / outlaw programmer wrote: And I argue that you don't have the burden of managing iterators to traverse a CArray.
How is one line of code a burden ? You can actually iterate through a vector without an iterator, BTW.
John Simmons / outlaw programmer wrote: Your arguments sound more generally anti-MFC than anti-CArray.
No, MFC was and is a very good windowing framework. It beats the hell out of Win32. But, it's a windowing framework. The containers it has are an afterthought, they are not well designed, and had the compiler been able to handle the STL at the time, they would never have existed.
John Simmons / outlaw programmer wrote: I haven't looked, but aren't the new MFC 7.0-8.0 collection classes wrappers for STL now. I heard CString is supposed to be.
I'm not sure. CString now is templated, I know that.
John Simmons / outlaw programmer wrote: It's no less powerful in the hands of someone that knows what it can/can't do.
Yes, I would agree. If you start with the assumption that you'll never need the power or flexibility of vector, if you were only going to use a CArray as a dumb, non cross container compatible lump of stuff, they would essentially both do the same thing. So long as you never coded without MFC.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I stopped trying to use CXImage. Instead, I use FreeImage. I find FreeImage easier to use/implement.
http://freeimage.sourceforge.net/[^]
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I leave you big ego guys for couple of days and look what happened.
Can you play nice?
Next time I won’t ask.
Are you happy?
PS CArray and CxImage works just fine for me, no thanks to you.
Vaclav
|
|
|
|
|
Hey, why don't you fuck off. We're having a nice pleasant discussion about it and you don't need to come in here acting like a fucking a**hole.
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I use LoadImage(...) load some icons from file, and draw on the view(SDI).I also draw some text on the view .I set the coordinates .the icons and the text can print preview .
the question is:
the icons can't print ,but the text can print correctly .why?How to resolve this question?
|
|
|
|
|
Post the code here. looks like a DDB issue. Should be using DIB if you ever want images to be printing on the printer.
|
|
|
|
|
this is part of my code:
the icon and the text can both display when I print preview.the text can print ,but the icon can't print.why?
void CMyView::OnDraw(CDC *pDC)
{
....
HIOCN hIcon;
CString iconPath("D:\\1.icon");
CString stronetwo("vc++");
hIcon=(HICON)LoadImage(NULL,iconPath,IMAGE_ICON,48,48,LR_LOADFROMFILE|LR_DEFAULTSIZE);
DrawIconEx(pDC->GetSafeHdc(), x-24, y+50, hIcon, 48, 48, 0, NULL, DI_NORMAL);
DestroyIcon(hIcon);
....
pDC->TextOut (x-35, y+110+linenum*20, stronetwo);
}
void CMyView::OnPrepareDC(CDC* pDC, CPrintInfo* pInfo)
{
// TODO: Add your specialized code here and/or call the base class
CScrollView::OnPrepareDC(pDC, pInfo);
pDC->SetMapMode(MM_ANISOTROPIC);
CSize size = CSize(800,560);
pDC->SetWindowExt(size);
int xLogPixPerInch = pDC->GetDeviceCaps(LOGPIXELSX);
int yLogPixPerInch = pDC->GetDeviceCaps(LOGPIXELSY);
long xExt = (long)size.cx * xLogPixPerInch/96;
long yExt = (long)size.cy * xLogPixPerInch/96;
pDC->SetViewportExt((int)xExt,(int)yExt);
}
BOOL CMyView::OnPreparePrinting(CPrintInfo* pInfo)
{
// default preparation
CWinApp *app = AfxGetApp();
app->GetPrinterDeviceDefaults(&pInfo->m_pPD->m_pd);
DEVMODE *dm;
dm = pInfo->m_pPD->GetDevMode();
ASSERT(dm!=NULL);
dm->dmPaperSize = 8;
return DoPreparePrinting(pInfo);
}
BOOL CMyView::OnPreparePrinting(CPrintInfo* pInfo)
{
// default preparation
CWinApp *app = AfxGetApp();
app->GetPrinterDeviceDefaults(&pInfo->m_pPD->m_pd);
DEVMODE *dm;
dm = pInfo->m_pPD->GetDevMode();
ASSERT(dm!=NULL);
dm->dmPaperSize = 8;
return DoPreparePrinting(pInfo);
}
|
|
|
|
|
I'm looking to upgrade to Visual C++ 2005 Standard and wanted to know if it includes the same optimizing compiler in the Pro edition ?
With VC++ 2003, the Standard edition did not initially come with the optimizing compiler, although this was later released for free as part of the VC++ Toolkit.
|
|
|
|
|
The Visual C++ 2005 Express Edition definately does so i'd take a pretty good guess that the Standard edition does as well.
<edit>Yup, it does...[^]</edit>
Gavin Taylor
w: http://www.gavspace.com -- modified at 19:52 Sunday 8th January, 2006
|
|
|
|
|
Hi,
i am using #using <mscorlib.dll> in VC++6.0,
but its giving fatal error C1021,
how can i use #using <mscorlib.dll> in #using <mscorlib.dll>++6.0.
Thanking you
|
|
|
|
|
No, you can't. VC6 does not support .NET.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
FYI, I am running Win 98 with Visual C++ 6.0.
I am writing a WIN32 Application that has 3 edit boxes with 3 static text controls. I want the user to be able to enter the keystroke "ALT-1" and be placed in edit in the first box, etc. I am creating all my windows in the WinMain function. Everything works ok when the window is displayed initially, but if I "ALT-TAB" to a different window or minimize the window then the "ALT-1" key sequence stops working. The same problem exists for the Menu shortcuts ("ALT+F" for example)
I looked at handling the WM_CREATE message but I am not sure that will really resolve my problem because it looks like WM_CREATE is handled even before WinMain is executed? I am pretty sure my problem is because I am creating all my windows in WinMain but I am unclear/uncertain what action I should take. I also don't know exactly what I should look for/search on at the MSDN website. I know there is something I am doing wrong I just don't know what it is....
Any ideas/suggesions are appreciated 
Thanks!
|
|
|
|
|
|
Mnemonics and hot keys are not the smae thing. You need to call RegisterHotKey() if you want ALT+1 to be seen by your applicaton even if it does not have focus.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
Thanks! So if I don't want ALT+1 to be used/see by my app when it does not have the focus what do I need to do? Should I be using an Accelerator Table? I thought accelerator tables were only for shorcut keys (keys that would correspond to a menu option (CTRL+O for Open) can they also be used for things other than menu options? I am confused by the terms shortcut keys, accelerators and Mnenmonics. Are they the same thing or are there differences?
Thanks for your help!
|
|
|
|
|
RobertW100 wrote: I am confused by the terms shortcut keys, accelerators and Mnenmonics. Are they the same thing or are there differences?
An accelerator is a keystroke or combination of keystrokes that generates a WM_COMMAND or WM_SYSCOMMAND message. Although accelerators typically generate commands that exist as menu items, they can also generate commands that have no equivalent menu items.
A mnemonic is a selected letter or digit in the label of a button or in the text of a static control. The system moves the input focus to the control associated with the mnemonic whenever the user either presses the key that corresponds to the mnemonic or presses this key and the ALT key in combination. Mnemonics provide a quick way for the user to move to a specified control by using the keyboard.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
Hi,
I want to transfer an array from an ActiveX Control using a method. I have figured out that I have to set up a UDT, but I'm unsure on how to do this. I am writing the ActiveX in MFC C++ .NET
If I have the following struct:
typedef struct testArgs {
int test1;
int test2;
BYTE * test3; // This is a array
} test;
How can I get this to so that it is accessible in say Visual Basic .NET.
Any help would be greatly appreciated.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
