|
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++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
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.
|
|
|
|
|
sw@thi wrote: i need to check whether a pointer is valid or not...
Why?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
New day, same old story 
|
|
|
|
|
sw@thi wrote: they also say that its not good practice to use these functions.
any particular reason!
"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
|
|
|
|
|
You should avoid IsBadReadPtr and IsBadWrite pointer like the plague. See here[^] and here[^]. If you get a bad pointer the best thing that you can do is ***NOT*** attempt to validate it and let the application crash so it can be debugged.
Steve
|
|
|
|
|
hello friends,
i trying to access properties of activeX control throught atl dialog, but unable to access, also unable to create a control variable of activeX control, which can be create in mfc.
thnx...
Rajesh
|
|
|
|
|
Have a look at the ActiveX Control Test Container tool which Microsoft ship with VC6. If you hunt around on the Web the source for it is available. It's ATL and does just about everything with ActiveX controls that you can imagine and some stuff that I still can't even after I read it.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I need to send some raw data from a packet sniffed by Ethereal. Someone knows how?
|
|
|
|
|
alofang wrote: I need to send some raw data from a packet sniffed by Ethereal. Someone knows how?
just convert that to char and send it TCP via socket!
"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
|
|
|
|
|
|
Does exist a simple way to change the background color of edit and button ctrls when has the focus? thanks VC6++
|
|
|
|
|
Take a look in SetBkColor ()
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Nelek wrote: Take a look in SetBkColor ()
it will not work.. you have to subclass
"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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
