|
did you get it?
Suggestion to the members:
prefix your main thread subject with [SOLVED] if it is solved.
chandu.
|
|
|
|
|
did not get a chance to try it. got tangled in something else. Thanks.
|
|
|
|
|
Adding that line did not work. Still dies the same thing. Thanks.
memDC.SelectObject(pBmp);
dc.BitBlt(5, 5, 2*w, 2*h, &memDC, 0, 0, SRCCOPY);
bPrintingOK = (dc.EndPage() > 0); // end page
//}
|
|
|
|
|
umm...isn't 7,7 at the upper left of the paper?
I don't see any calculations involving inches - pixels=per-inch,
paper dimensions, etc.....do you do that somewhere else?
Is the bitmap already scaled to the printer resolution?
"// LoadImage does the trick here, it creates a DIB section"
Wrong. There's no DIB section involved here.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Thanks Mark! I don't do anything else in my program. Just call the function giving the .bmp filename. also most of the code I've taken from internet so don't understand very well as I am using CDC for very first time. I'll look into it as soon as I get a chance as I got completely tangled in another task.I really appreciate your help! Thanks!
Shilpa.
|
|
|
|
|
Hello everyone,
When do we need to add code,
#define INC_OLE2
in our code? I can not find related information from MSDN.
thanks in advance,
George
|
|
|
|
|
It governs whether ole2.h is included when you #include windows.h. If you include ole2.h yourself you don't need this define.
Also, if NOGDI is not set and INC_OLE1 is not set, ole2.h is included, regardless of the setting of INC_OLE2, if WIN32_LEAN_AND_MEAN is also not defined.
A few other Windows headers will set INC_OLE2 before including windows.h themselves; whether this has an effect will depend on the order you include the headers, if you do so yourself.
The Windows headers are highly configurable and that configuration is barely documented and very complicated. I generally don't bother defining any configuration options and include windows.h, unless I'm using ATL or MFC in which case I'll include MFC or ATL headers as appropriate.
The aim is to reduce compile times by omitting unused features. However, if you're using precompiled headers it will generally only reduce the time to compile the PCH file.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Thanks Mike!
Are there any additional functions we could use if we use ole2.h other than ole1.h? Are there any compatibility issues? For example, in some situation we could only use ole2.h and can not use ole1.h?
BTW: I am developing COM in Visual Studio 2005.
regards,
George
|
|
|
|
|
Um, OLE 2.0 is now 15 years old! It was introduced with Word for Windows 6.0 in 1993 if I remember correctly. OLE 1.0 was based on Dynamic Data Exchange (DDE). OLE 2.0 is based on COM. There is no reason at all to use OLE 1.0 in a new application.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Thanks for your comment, Mike!
have a good weekend,
George
|
|
|
|
|
Hi,
I'm using VC++6.
In my application I'm using Imgman32.dll for image processing.
I'm cropping a black and white image.
But the cropped image is 16 color.
How do i change it to black and white?
Thanks & Regards,
sanju.
|
|
|
|
|
sanjutvm wrote: I'm cropping a black and white image.
But the cropped image is 16 color.
How do i change it to black and white?
change every pixel image to black , if pixel is not eqal to RGB(255,255,255)
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Or, for each pixel, take its RGB color, convert that color to 8-bit grayscale.
If the grayscale value is closer to black, write a black pixel. Closer to white,
write a white pixel. You can decide the black/white threshold.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi, I will soon be working on some work which will be in the Windows xp embedded operating system. I'm wondering if applications I code for the standard windows envrionment(such as in MFC) are compatible with the embedded version, also are there any important factors when programming for the Windows xp embedded OS?
Thanks
-- modified at 9:47 Thursday 11th October, 2007
|
|
|
|
|
Programming for XPe is the same as for XP as long as the creator of the XPe image has included those OS elements needed to support your applications. For example, if you program for .NET and the image creator does not include the .NET framework in the OS build, your program won't run because its OS support is missing. You need to talk to whomever is making your XPe OS and find out what will be provided. XPe is not like CE where parts of the API are different. Programming for XPe all depends on what is included in the OS build.
Judy
|
|
|
|
|
Thanks. It's good to know.
|
|
|
|
|
i need to check whether a pointer is valid or not ie., whether its NULL or Bad Ptr.
I've searched the net and found these functions IsBadReadPtr or IsBadWritePtr, but they also say that its not good practice to use these functions.
Can anyone please tell me are there any alternatives for these function? if there are no alternatives then what are the problems that i might face if i use these function??
Thanks for any help.
|
|
|
|
|
From where is this pointer coming from ?? In general, when playing with pointers, the thing you have to pay attention to is to initialize them to NULL. Then, you can simply check if the pointer is NULL or not using if (pPointer)
I don't see why you need to check for bad pointers...
|
|
|
|
|
Thanks for your reply. here is why i think i need to check for bad ptr:
theres this function in a class that would return a pointer. something like this
CMyWnd *GetMyWnd(){ return m_myWnd};
now when this object is destroyed m_myWnd is delete and the pointer is set to NULL, but after the object is destroyed in someother function somewhere this function is again called then GetMyWnd retunrs a CMyWnd* with a junk value. when this pointer is set to NULL in the destructor, it should return NULL but it doesnt, it returns something like 0xcdcdcdcd in the calling function say we do something like this
GetMyWnd()->SetSomeFunc(); // the application crashes here, in VS2005 where as in 2003 it works fine.
this happens because the pointer that GetMyWnd returns is not a valid pointer and once it tries to acces any member of CMyWnd the application crashes.
i've changed the above statement to something like this:
CMyWnd *pWnd = GetMyWnd(); // i also tried CMyWnd *pWnd = NULL; pWnd = GetMyWnd();
if(pWnd)
{
pWnd->SetSomeFunc();
}
to see what GetMyWnd returns. It returns a Junk value, and the if condition is evaluated to true and it enters inside and crashes. this is the reason that i thought i should check for NULL as well as Bad Ptr.
how do i solve this?? is there anyother way??
|
|
|
|
|
sw@thi wrote: now when this object is destroyed m_myWnd is delete and the pointer is set to NULL, but after the object is destroyed in someother function somewhere this function is again called then GetMyWnd retunrs a CMyWnd* with a junk value. when this pointer is set to NULL in the destructor, it should return NULL but it doesnt, it returns something like 0xcdcdcdcd in the calling function say we do something like this
You know what your real problem is - you say so. Fix the real problem instead of trying to use a function to cover up the error. cdcdcdcd is a value that indicates an uninitialized variable. It appears that your GetMyWnd function is not maintaining the value of m_myWnd. Figure out why
Judy
|
|
|
|
|
IsBadReadPtr / IsBadWritePtr are as good as it gets on Win32 I'm afraid. You shouldn't run into too much trouble as long as your app is doing 'ordinary' things with memory i.e. no mucking around with non-paged pool or using exception filters to allocate virtual memory. I wouldn't try using them against anything you expect to be allocated on the stack either as compiler optimisations might change behaviour between Debug and Release builds.
That leaves you with IsBadReadPtr / IsBadWritePtr are fine for Heap memory you allocate yourself i.e. new and delete.
I use a special class to check pointer parameters like this when they are passed. The template class has assignment from and cast to operators for the original pointer type. The cast calls the relevant check function whenever it is used. The checking classes are removed in the Release build for performance by the use of a macro. so
void SomeFunc( CNullPointerCheck<char*> pszData )
which checks pszData for NULL on every call in Debug, becomes
void SomeFunc( char* pszData )
with zero overhead in Release builds. It gets written as
void SomeFunc( _PC_NP(char*) pszData )
which makes it clear this is a Parameter Check for Null Pointer
Other classes check for Readable and Writable memory of a certain size at the target of the pointer using the IsBadReadPtr/IsBadWritePtr functions so
void SomeFunc( _PC_WP(char*, 40) pszData )
for example checks for at least 40 characters of writable memory.
I'll post the whole lot as an article some day when I'm happy with the error reporting system.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
You should avoid IsBadReadPtr and IsBadWrite pointer like the plague. See here[^] and here[^]. These functions may be "as it gets on Win32", but they fall well short of good enough.
Steve
|
|
|
|
|
Very interesting. It would seems that you should only use IsBad*Ptr if you can gaurentee 2 things.
1 You're not intentionally passing in exotic memory types like guard page addresses.
2 If anything goes wrong the app will stop because the result of the call will always be acted on.
If you're writing the Win32 API you can't make these gaurentees so you shouldn't use the functions. In my case I use them in a framework where I can gaurentee both things so I feel reasonably justified in making this limited use.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I’ve actually fallen victim to a stack guard-page corruption caused by the numerous calls to IsBadReadPtr and IsBadWritePtr in MFC. It wasn’t at all obvious that the memory page in question was on the stack and not the heap (it took ages to even discover that the guard page on the stack was corrupted); after all every local variable is on the stack and many such variables are passed “through” MFC. It took many weeks to debug the issue. Anyway, what’s the point of a function succeeding if it’s called with some random pointer and thus can’t access the data it needs to do its job? Don’t validate memory, crash! Then the source of the problem is staring you in the face instead of some problem far removed from the actual source.
Steve
|
|
|
|
|
I'll look forward to that article. We are not doing anything special with that ptr. just check for that pointer and then if its valid then call one more member from that ptr.
i gave a full explanation in reply to cedric moonen's message above yours. Thanks for your reply.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
