|
Thanks but I don't want to use someone else's classes. I would rather learn how to do it myself. It's easy to use other people's hard work.
Also a lot of extra code for such a simple program as mine.
"Complexity breeds problems. Keep it simple." - Mark
|
|
|
|
|
See CImage::Save for save an image.
|
|
|
|
|
You could always look at how it's solved in CXImage. Do you really want to write and debug code which encodes gifs and jpegs? You seriously need a hobby man!
--
Mit viel Oktan und frei von Blei, eine Kraftstoff wie Benziiiiiiin!
|
|
|
|
|
Hello!
I've made simple MFC program. I sent it to my friend, and he told me that he is getting an error while executing. The message box says that the configuration is corrupted and reinstall of this app. might help (something like that). He tryied to run this app on 3 more computers always getting the same error.
Please help!
|
|
|
|
|
Sounds like you didn't give your friend the DLLs that your program needs to run.
|
|
|
|
|
But how to find out which dll's does he need, and where sholud he place it?
This program is a simple dialog, made with app wizard. With a press of a button I create modal window.
Can't anything be done while debugging/linking...some build options?
|
|
|
|
|
You can use a program called Depends[^] to see what DLLs your program is dependent upon. You might just want to change your project settings to statically link with the runtime and you might not have to distribute any DLLs at all.
|
|
|
|
|
There is a lot of dll's that application depends on. It is hard to check every machine before runnig a program on it.
I don't know if i'm getting it correct (this sattically link), but I've changed in project properties to "Use MFC in Static Library". It didn't worked.
|
|
|
|
|
Then I think that we will need a bit more information to be able to help.
|
|
|
|
|
|
What version of compiler you using? What kind of project is it? What is the error that you are getting?
|
|
|
|
|
Microsoft Visual Studio 2005
Version 8.0.50727.42 (RTM.050727-4200)
Microsoft .NET Framework
Version 2.0.50727
Installed Edition: Professional
Microsoft Visual C++ 2005 77626-009-0000007-41598
Microsoft Visual C++ 2005
Project:
Dialog window made with MFC Application Wizzard. I added only: 1 button to main window, create 1 dialog and call it as Modal window tih this botton.
|
|
|
|
|
As Christian pointed out, it is entirely possible that you need to give him the runtime libraries. For your version of VC it will be the msvc*80.dlls. There should only be a couple of them.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
|
|
|
|
|
If he has XP, it could be a problem related to a missing manifest file ? If you linked statically to MFC, it's probably the C run time that you're using and need to distribute. What version of VC are you using ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
I believe the problem is solved. I made the same project from the begining, now using Static Library. I don't know why it did't work last time. Maybe I should delete previous bild .exe file. Anyway... thans for your time and help.
|
|
|
|
|
Hi. I've this problem: A thread is waiting on a semaphore handle with WaitForSingleObject. Another threads closes the semaphora handle with CloseHandle. The problem is that the wait doesn't release the thread...the timeout is INFINITE, so it stays there. Is this possible? Is there any way to tell the wait family functions to return an error (or at least to return) if this situation occurs?
I would really apprecciate any hint about this problem.
Thanks in advance,
Federico
|
|
|
|
|
Only the Mutex has a condition that occurs when the handle is deleted. Other synchronization handles assume you are being a good citizen. The solution is to add a shutdown event and do a WaitForMultipleObjects .
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
If the semaphore handle is being Create/Open-ed once, then you should get an error condition from WaitForSingleObject(), like WAIT_ABANDONED. It certainly works this way for Events. This assumes that the handle is created in one thread, and directly passed to another, rather than one thread using CreateXXXX and the other using OpenXXXX.
Steve S
Developer for hire
|
|
|
|
|
This one is a first for me.
"The value of ESP was not properly saved across a function call"
It's happening on a timer callback function I have placed in a base class, and it only occurs when I declare the non-static member as virtual. Here is the code
void *CSpecialFx::thisPtr;
CSpecialFx::CSpecialFx()
{
thisPtr = this;
uTimerId = SetTimer(0,0,30,(TIMERPROC)StaticProc);
}
CSpecialFx::~CSpecialFx()
{
KillTimer(0,uTimerId);
}
VOID CALLBACK CSpecialFx::TimerProc(HWND hwnd,UINT uMsg,UINT_PTR idEvent,DWORD dwTime)
{
static int i = 0;
i++;
}
VOID CALLBACK CSpecialFx::StaticProc(HWND hwnd,UINT uMsg,UINT_PTR idEvent,DWORD dwTime)
{
CSpecialFx *tmp = (CSpecialFx*)thisPtr;
tmp->TimerProc(hwnd,uMsg,idEvent,dwTime);
}
The code runs for a few seconds, but it never steps into the virtual callback. The error also goes on to mention the calling conventions being a probable cause. What did I miss?
|
|
|
|
|
Can you show the class declaration? Which function is static? which is virtual? I can probably assume which is which but just to be sure.
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Sure
class CSpecialFx
{
public:
CSpecialFx();
virtual ~CSpecialFx();
protected:
virtual VOID CALLBACK TimerProc(HWND hwnd,UINT uMsg,UINT_PTR idEvent,DWORD dwTime);
private:
static VOID CALLBACK StaticProc(HWND hwnd,UINT uMsg,UINT_PTR idEvent,DWORD dwTime);
static void *thisPtr;
UINT uTimerId;
};
|
|
|
|
|
I think maybe I have solved it. The object was declared within the scope of a function, so I have a feeling it was goind out of scope. I declared it as static and it seems to be working fine.
|
|
|
|
|
In your destructor be sure to set the thisPtr to NULL, and in the StaticProc be sure to check for NULL. If you don't you could run into problems if you have multiple instances of your class active.
You may be right I may be crazy -- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
thanks for the heads up. I'm really bad when it comes to error checking, well bad or just plain lazy...
|
|
|
|
|
PJ Arends wrote: In your destructor be sure to set the thisPtr to NULL, and in the StaticProc be sure to check for NULL. If you don't you could run into problems if you have multiple instances of your class active.
He won't be able to have multiple instances of this object. What he has is a hacked-up singleton (which I don't think is what he wants).
I can't test this at the moment, but I believe if you pass SetTimer your member function as &CMyClass::MyTimerFunc it will avoid the need to make it static.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|