|
Not a solution, but a step. Is the error in your own code ? If so, try copying the #define into the top of your .cpp file and see if it compiles. If so, then it cannot see that file, for whatever reason. If not, the problem is somewhere else, and the error message is just not very helpful.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
I haven't tried this so I'm not sure it'll work, but try to define the _WIN32_WINNT macro as 0x0400 or later in stdafx right at the begining, before any other lines.
|
|
|
|
|
If you change something in stdafx.h you must recompile (manually) the file stdafx.cpp to update the precompiled header.
Robert-Antonio
"Love without sex is like a fish without antlers"
|
|
|
|
|
Hi all;
I am working on an SDI application and everything went fine until i tried to used some library to skin my application. I used the SkinMagic library and still everything is fine. The only problem is that i get a very ugly error each time i close my application (either by selecting the little X or by clicking the "Exit" button within my app).
The error reported is as follows:
The instruction at XXX referenced memory at YYYY. The memory could not be read. The debugger told me that it was an unhandled exception and pointed to a call to an assembly fx (i guess) called mov. It reported the error to be there.
Can somebody please help me out of this stuff. I really need to skin my application since it has to be nice-looking.
Ps. Anyway, if you know some cool way of skinning an application, could you please help me too.
Thank you;
Krugger.
Krugger
|
|
|
|
|
Sounds like you are closing your window, but neglecting to close down something the skin library requires you to shut down before your window handle is gone.
Check the skin library cocde for any explanaiton of tasks you must perform before your program has closed its main window. In your window's message handle, you can handle the WM_CLOSE message, and do the processing to shut down the skin library there.
|
|
|
|
|
hi
Kind of memory leak. chk the debug window to c the leaked memory segments and try to release those segments.
rgds ...mil10
|
|
|
|
|
hi
Kind of memory leak. chk the debug window to c the leaked memory segments and try to release those segments.
rgds ...mil10
|
|
|
|
|
I have a Batch file which run C-scripting commands. The firsy thing i does is to load a DLL dynamically.
This sets up a shared area for passing of data between this scripting function calss and a User Interface program (MFC C++).
The GUI program creates a Mutux for controlled access, this is stored in the shared area.
I have a problem, I can use the Mutux OK in the GUI application (WaitForSingleObject, ReleaseMutux etc. But in the DLL I wait forever for the Mutux, well 250 msec. The GUI is running with a timer ever 200 msec.
Are they a better way to have controlled access between the DLL and the GUI. Note the C-Script is calling functions in the DLL. Also the timer is causing some data not to be processed as already changed before Timer scheduled rouines to run.
grahamfff
|
|
|
|
|
What is Mutus? Are you saying mutex? 
I don't think you need to store your mutex to shared area. Just use named mutex for your case.
Hope this helps.
Sonork 100.41263:Anthony_Yio
Life is about experiencing ...
|
|
|
|
|
I am trying to write a simple plugin using C++ but all the examples that i found were written in C#.
Does anyone have a C++ plugin sample that I can use to start with? Thanx a lot 
|
|
|
|
|
|
|
Thousands of people use my program, and about every week a crash report is sent to me with the same details. Here's a picture showing the info from WinDbg: http://www.igx89.com/crash1.jpg[^]
(LogString is bound to an Edit Control using DDX_Text)
I can't figure out why that crash would be happening, and would greatly appreciate any help given to me.
|
|
|
|
|
ive had some problems concatnating cstrings in some programs... i never figured out y, but it happened very often, cause it was in a function used many times per second. The same code in another part of the program worked fine! The stupid part was that if i added some code in the same funtion, the problem disapeared! Seemed like a compiler error, maybe because of optimizations 
|
|
|
|
|
The second use of + on that line appears to have faulted - you haven't shown the disassembly of ATL::operator+, but if my copy of VS.NET has generated similar code, it looks like you've trashed the second argument, LogString. You probably have a wild write somewhere in your program.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
The only place where that variable is accessed is in the DDX call and in the function shown, so the variable should always be valid. I could probably work around the problem by using strcpy and strcat functions instead, but I'd rather discover the root of the problem so I don't have to worry about bugs like this popping up again in the future.
|
|
|
|
|
I assume LogString is a member of the CFLModManager class.
I don't think your problem is with a legitimate access; I think something else is corrupting the object. Possibilities I can think of are: you're using the CFLModManager object after it's been deleted (if you're using new/delete to manage the object), or from another thread or routine outside the scope of the function that declares the object (if it's a local variable), or that you have an unbounded ('wild') write somewhere which is overwriting the memory used by the LogString object.
The first two cases are relatively easy to check for. The last really requires examining every memory access in the program that could possibly coincide with the life-time of the dialog box. You can help yourself out a little by putting a data breakpoint on the LogString member and see when it changes. Specifically, it appears to be the m_pszData member that's been corrupted.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Yes, it's a member of the main dialog class, CFLModManager. I don't see how the first case would be possible; the second case might, I guess, but I just have one other thread, and it just communicates using SendMessage to the main thread's window. I'll try changing it to PostMessage (not sure if that'll do anything), and increasing a couple buffers that aren't CString's (I doubt they're overflowing, but just to be sure).
What makes this crash so hard to debug is that I can't duplicate the crash, and it rarely happens to my users; ~1 crash a week (auto-reported) out of 10,000+ downloads. Fortunately, because it's so rare, it won't be that big of deal if I can't fix it; I don't think it's happened to the same person more than once.
|
|
|
|
|
Is your Log() function called from its own thread or from multiple threads ?
One chance for the err can be :
In your code each time you concat CString the heap has to be locked/unlocked multiple times.If this is hapenning from multiple threads it again induces context switching.
Note:
CString is not supposed to be shared between threads.
It's not a bug, it's an undocumented feature.
suhredayan@omniquad.com
messenger :suhredayan@hotmail.com
|
|
|
|
|
Hi all,
My application needs to know if it's running through remote desktop, to optimize graphics and stuff for low bandwitdh connections.
Question:
How do i automatically detect that the user is running my app through remote desktop?
Thanks in advance!!
|
|
|
|
|
Maybe this function works:
GetSystemMetrics( SM_REMOTESESSION );
which returns a bool indicating wherever the user is using RD... havent been able to test it yet...
|
|
|
|
|
works, but the compiler refused to accept the SM_REMOTESESSION value, even including "winuser.h", where it is defined. So, i just passed the value 0x1000 
I know its a bad policy, but im not going to waste a lot of time with compiler sh$t.
|
|
|
|
|
Define WINVER to be 0x0500 before including any headers (typically in StdAfx.h), and ensure you're using a relatively recent Platform SDK (the headers included with VC6 don't have this definition).
You can consider this a 'safety guard' to stop you accidentally using a feature not supported on older systems.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
I think you have the right idea, but be careful, it just means it probably isn't supported on older verions (e.g., Windows Nt 4.0.) You could follow the suggestion to change your platform version and recompile, but I'm not sure if that means your app will fail to work on older platforms.  I haven't risked it.
"Fish and guests stink in three days." - Benjamin Franlkin
|
|
|
|
|
No problem! My app is only supposed to work on win2000+.
I know that in previous versions that might not work...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
