|
|
<blockquote class="FQ"><div class="FQA">vikas amin wrote:</div>what is windows service ,
How can i create my own serv</blockquote>
http://www.commsoft.com/services.html
Good Site to read about Services!!
Suriya
|
|
|
|
|
Hi,
I need to print the SDI dialog and found the following code
http://www.codeproject.com/printing/prntscreen.asp
The code worked fine but the print out image is a
kind of small.
Does anyone know how to change the setting to print
the bitmap image a bit larger if possible?
Thanks,
Kevin
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
