|
Well for that header to cause a rebuild of everything it'd have to be:
- included in everything, either directly or through another file
- modified
If the first is true it doesn't matter whether it has 1 or 100 classes, any change will cause a massive rebuild. Having said that though I'd advocate only having one class in a header file, it makes it easier to reduce dependencies if you do.
Cheers,
Ash
|
|
|
|
|
Hi!
Problem is: I removed the BIOS Battery. I forgot to set the correct date and time again.
|
|
|
|
|
Hi All
I am getting error CoInitialize has not been called.Code is here
void Ctest::OnCopyData()
{
::CoInitialize(NULL);
COleDataSource* pSource = CopyTextList();
if (!pSource)
return;
pSource->SetClipboard();
}
COleDataSource* Ctest::CopyTextFromList()
{
USES_CONVERSION;
CSharedFile sf(GMEM_MOVEABLE | GMEM_DDESHARE | GMEM_ZEROINIT);
CString str;
int nPos=m_test.GetItemCount();
for(int i=0;i<nPos;i++)
{
CString GetData=m_test.GetItemText(i,0);
str+=GetData;
str += _T("\r\n");
sf.Write(T2A(str.GetBuffer(1)), str.GetLength());
str.ReleaseBuffer();
}
char c = '\0';
sf.Write(&c, 1);
DWORD dwLen = (DWORD) sf.GetLength();
HGLOBAL hMem = sf.Detach();
if (!hMem)
return NULL;
hMem = ::GlobalReAlloc(hMem, dwLen, GMEM_MOVEABLE | GMEM_DDESHARE | GMEM_ZEROINIT);
if (!hMem)
return NULL;
COleDataSource* pSource = new COleDataSource();
pSource->CacheGlobalData(CF_TEXT, hMem);
return pSource;
}
Please help me
|
|
|
|
|
CoInitialize(NULL) does some stuff, so you better call it some time (100ms) before you need it to be finished.
Tip: you only need to call it one time per thread/app. Best in some startup code liek oninitdialog.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Try helping yourself. Here are some things to try:
- Find which line is causing the error
- When you've done that step through the code in a debugger and see if the function with CoInitialize() in is executed is before that
- Check that for every CoInitialize you've got a CoUninitialize
Cheers,
Ash
|
|
|
|
|
Are you aware CopyTextList is called, but you supplied code for CopyTextFromList?
Also you only need CoInitialize once. Do that in your start up routine (CWinApp::InitInstance if it's MFC)
|
|
|
|
|
It's unuseful to call CoInitialize each time you need to use some COM object; call CoInitialize only once somewhere in your startup code instead.
Be aware that each call to CoInitialize should be balanced with a call to CoUninitialize.
From the code snippet you posted, it seems that you wrote your application using MFC, then the best places where put the calls are inside CWinApp::InitInstance and CWinApp::ExitInstance.
|
|
|
|
|
Hi all.
My executable is suddenly disappearing after a number of hours running (variable). I have never seen this kind of behaviour before and I'm completely stumped.
What could cause my EXE to disappear discretely.
For info, I'm using XP 32 bit SP3. The app is a console app with a number of worker threads. There is no condition that would lead the program to exit cleanly (or at all for that matter).
Anyone seen anything similar?
Thanks.
|
|
|
|
|
one easy way to crash silently, even on a perfect system, is by creating a fatal condition that prohibits proper signaling; a recursion ending in a stack overflow would probably be one of those. I suggest you add some logging, and periodically log some major statistics such as working set, GDI object count, etc. Make sure to regularly close the log file, so it is available after the next crash!
|
|
|
|
|
Many thanks for that. It does look like a stack corruption, but I'm not sure why or how to check / fix.
I used application verifier which seems to be quite good. It told me:
"the stack was corrupted when asychronous I/O was pending"
Could this cause my silent crash?
I'll try and post the full xml log from appverifier a bit later.
|
|
|
|
|
maybe you are getting the next chunk of I/O data before you're finished dealing with the previous one, so your asynchronous handler (probably the receiver) is breaking in to itself sometimes (or even always). Check your code to see if that is possible, maybe add a nestinglevel counter, in pseudo-code:
int nestingLevel=0;
void myIOhandler(...) {
nestingLevel++;
if (nestingLevel>5) {
log("warning: myIOhandler is being reentered; nestingLevel="+nestingLevel);
}
...
nestingLevel--;
}
|
|
|
|
|
Thanks for that. I think it put me on the right track, although I was unable to check for the nesting because I didn't know where to put the increments / decrements.
I have a listening thread which listens for an RX event and reads (overlapped) the data.
Other threads can issue overlapped writes to the same port, whose access is protected with a critical section.
However, I suspect that my problem my come from the fact that I'm using the same event handle for all the instances of overlapped reads / writes.
I could be wrong about this, my understanding of overlapped I/O is limited :s
Does this make sense?
|
|
|
|
|
The problem seems to be resolved.
I am concluding that the multiple use of the same event handle in overlapped I/O caused stack corruption and the process would crash silently. A week of testing after correcting the overlapped I/O has shown that the application is now stable.
Thanks for all the help 
|
|
|
|
|
i guess your threads are eating up the stack so it ends.
-> To DO: debug at most your thread terminations for leaking memory. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Hi All
I have download some example code from net.When i try to complie this code then i getting error this.
error PRJ0019: A tool returned an error code from "Performing Custom Build Step"
|
|
|
|
|
open up the project's properties, look at the custom build steps and see what it's trying to do.
|
|
|
|
|
There is normal setting
Performing Custom Build Step nothing special setting there.Please give me more tips.
|
|
|
|
|
See here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Hi,
I want to confine mouse movement. Let's say I want to confine mouse movement to x-direction (so only horizontal movement is possible) when pressing a certain button. This should work globally. What I mean with that is, that I want to use this in any windows program. Let's take MS Paint as an example: When my program runs and I press the certain button, the movement of the mouse should be restricted to horizontal movement. So when drawing a straight horizontal line should be the result.
My research so far led me to ClipCursor, but ClipCursor seems to only affect the mousecursor, not the raw data. So returning to the example of MS Paint the following happens:
The cursor moves on the horizontal line, but the mouse data received by paint is different: So if you move the mouse slightly in y-direction this still affects the line drawn, also the mouse cursor itself does not indicate that (stays on the straight line). So the result is not a straight line as expected.
Does anybody know how to solve that problem ? (as ClipCursor does not confine the raw data sent to an application, it seems to be the wrong routine for doing that)
Thanks in advance.
|
|
|
|
|
HHOOK WINAPI SetWindowsHookEx(
__in int idHook,
__in HOOKPROC lpfn,
__in HINSTANCE hMod,
__in DWORD dwThreadId
);
http://msdn.microsoft.com/en-us/library/ms644990(VS.85).aspx[^]
and then look at: WH_MOUSE or WH_MOUSE_LL to get what you need. WH_MOUSE_LL gives a little bit more information, but may not be needed in your application.
|
|
|
|
|
Thanks for the answer. I could use one more hint. To modify the mouse data with let's say WH_MOUSE_LL I have to use my own custom CallBack function and modify the POINT pt of the MSLLHOOKSTRUCT pointed to by lParam, which has been passed to the CallBack function, right? Or did I get something wrong about how to restrict the movement correctly?
|
|
|
|
|
If i remember correctly yes that would be how you would restrict the movement.
|
|
|
|
|
Additionally to what elchupathingy said, you might also try to globally hook[^] GetCursorPos[^].
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Selectively injecting a DLL and hooking the functions you need is IMO the better solution. More complicated than using SetWindowHookEx, but will not have the overhead and annoying problems that are associated with global hooks...IE getting the mouse stuck on your horizontal plane, which I think is not what is to happen.
|
|
|
|
|
Wouldn't he still need to use a hook to modify the mouse-input messages? I mean, the coords "encoded" in the message params probably come from somewhere else than GetCursorPos, do they not? Wouldn't btw selectively injecting the DLL instead of trying this globally with every process make it less "global"?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
