|
Get the DirectX SDK and look thru some of the samples. http://www.microsoft.com/windows/directx/default.aspx
|
|
|
|
|
How can I delete files from my Visual C++ program?
Christian
|
|
|
|
|
int remove( const char *path );
|
|
|
|
|
|
Press Del in the Project window file list.
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
Neville Franks wrote:
Press Del in the Project window file list.
hahahaha
The World is getting smaller and so are the people.
|
|
|
|
|
Would you please tell me how to store, retrieve and display .bmp file using sql server 2000 and vc++ 6.0?
Thanks a lot!!!
|
|
|
|
|
I'm encountering a strange problem in multithreaded code (I can hear the groans now  ). In a nutshell, my app is MDI where each document has a CListView attached. Each CListView spawns two threads. The first thread monitors a file and, when the file changes, reads the changes and adds the change records to a list. The second thread is signalled by the first thread when the list changes and updates the ListView with the new data.
As part of the shutdown sequence for the program I signal a stop event monitored by each thread which, when signalled, causes the thread to terminate. The stop event is manual reset. Then I wait upon each thread handle to be sure the thread has in fact terminated. Because the work in each thread is inside a loop not directly controlled by the WaitForXObject(s) call there's another boolean variable used to signal the thread, at each iteration of the loop, if I want it to return to the WaitForXObject(s) call. The thread that sets that variable sleeps for a couple of timeslices to be sure the threads see the change. (It makes no difference in the outcome if the thread that sets the variable sleeps 10 ms or 10 seconds).
It all works perfectly if I let it run to completion, ie
file changes
monitor thread notices changes and creates change records, adds them to list
update thread is signalled and copies new records into the view
but if I try to exit the app while the update thread is still processing change records the app hangs about half the time in a call to CListCtrl::InsertItem. I can let it sit there for an hour and nothing happens (and 0% CPU for the app). Breaking under the debugger when it's hung reveals the update thread is waiting for CListCtrl::InsertItem to return.
The thread procedure gets the this pointer to the CListView as the LPVOID parameter. Examining the code for CListCtrl::InsertItem reveals it's a simple wrapper around a ::SendMessage call using the HWND of the CListCtrl embedded in the view (ie, not using the MFC temporary CWnd mechanism. This explains why it works most of the time (no cross thread problems with CWnd's)).
When I break using the debugger during the hang I can see that the CListView is still valid and the embedded CListCtrl is also still valid (both have valid HWND's which Spy++ can see). So I can't imagine why it's hanging in the InsertItem call. Since the InsertItem call uses ::SendMessage rather than ::PostMessage it's not message pump related.
Any ideas? Any experience with hangs in CListCtrl::InsertItem?
Rob Manderson
http://www.mindprobes.net
"I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer"
"Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
|
|
|
|
|
Rob Manderson wrote:
Since the InsertItem call uses ::SendMessage rather than ::PostMessage it's not message pump related.
Are you sure? SendMessage waits for the window procedure to complete, if you no longer have a GUI thread it isn't going to be processed.
You could ensure your update threads exit before your main application thread, or use PostMessage instead. I think I would go for the first option.
Ryan.
|
|
|
|
|
SendMessage does a direct call to the WinProc whereas PostMessage adds a message to the message queue and waits for normal message pumping.
The main application thread is still running when the stop event is signalled.
Rob Manderson
http://www.mindprobes.net
"I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer"
"Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
|
|
|
|
|
I think you've deadlocked.
According to your description, you set the event object to signal that the update thread should shut down, then wait for the update thread to quit. While waiting, the UI thread is blocked.
I assume that the update thread looks something like:
while ( WAIT_TIMEOUT == WaitForSingleObject( hUpdateQuitEvent, 0 ) )
{
m_pList->InsertItem( );
}If the UI thread runs at point A, sets the event and then waits on the thread handle before the update thread continues to the next line, the UI thread is blocked while the update thread calls SendMessage.
SendMessage does indeed do a direct call, if and only if the thread calling SendMessage is the same one that created the window. Otherwise, SendMessage adds a message to the window's thread's message queue (which takes priority over posted messages) and blocks until either the windows procedure returns or until it calls ReplyMessage. The sent message is processed the next time a message is retrieved by the window's thread (within GetMessage - a sent message does not cause this APIs to return).
I recommend getting rid of your update thread completely, as it appears to be an unnecessary complication, and posting a custom message in the WM_USER range (with PostMessage) to your UI thread from the monitor thread, where you would have signalled your update thread. That message will then be processed next time your UI thread is idle. You should then be able to shut down the monitor thread with impunity.
|
|
|
|
|
Mike Dimmick wrote:
SendMessage does indeed do a direct call, if and only if the thread calling SendMessage is the same one that created the window. Otherwise, SendMessage adds a message to the window's thread's message queue (which takes priority over posted messages) and blocks until either the windows procedure returns or until it calls ReplyMessage.
Ah ha!!! I didn't know that
In the light of your comment (and the other replies to my question) I'm rethinking the strategy to eliminate the UpdateThread. Alas performance suffers a little but I'll live with that in return for increased robustness.
Rob Manderson
http://www.mindprobes.net
"I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer"
"Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
|
|
|
|
|
Rob Manderson wrote:
Ah ha!!! I didn't know that
In that case, I recommend chapter 26 (Window Messaging) of Jeffrey Richter's Programming Applications for Windows, Fourth Edition. Heck, I recommend the whole book. 
Chapter 26 goes into great detail about what's available with window messages, how they're processed, and how you can process them. I use window messages for a large part of my interthread synchronisation and communication.
This book should very much be considered the counterpart to Petzold's Programming Windows - Petzold teaches UI, controls and graphics, while Richter teaches threads, processes, jobs, memory, synchronisation, scheduling, DLLs, exception handling, window messages and input.
|
|
|
|
|
If I've read this correctly you are (indirectly) calling SendMessage() from a worker thread to act on a window that lives in the main app thread. If so you are asking for trouble, because it is very easy to get into a deadlock situation. This can happen because the main thread is processing some windows request, and your sendmessage has to wait until tht finishes and these actions beat on each other. It is late here on Oz and this isn't sounding too good. 
To do this sort of thing across threads I always use PostMessage(). If the worker thread has to wait until the message has been processed then I use an event which I wait on in the worker thread. The app thread will signal the event when it has done whatever I've requested of it.
Another approach for this specific bit of code might be a publish-subscribe approach, where the worker threads publishes the information to say an STL vector, and the app thread checks this from time to time and pulls stuff which is waiting. But I'm probably heading off the track and off to bed.
Hope I've been of help.
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
Yup, you and Mike have both been of help, if only to convince me to drop the two thread approach and use the PostMessage mechanism instead 
Rob Manderson
http://www.mindprobes.net
"I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer"
"Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
|
|
|
|
|
Threads have their place, and are especially usefull when there are some serious background processing requirements. In ED (see sig) I use threads for Find/Repalce in Files, Source Database updates etc. and they make for a much better user experience. However getting your design and implementation 100% correct so you can't get into a deadlock situation can be quite difficult. And of course there may also be synchronization issues. MFC makes multithreading which interacts with GUI components more difficult because CWnd maps aren't accessible across threads.
I wouldn't give up on your multithreading, but maybe it can be simplified down to a single thread. And make sure you never call anything that calls any function that can block, like SendMessage().
As an aside I use a technique similar to what you describe to end threads, however the technique that Peter Hancock uses in "An exception safe OO thread-pool framework" is quite neat. See: http://www.codeproject.com/threads/threadlibrary.asp[^] Peter forces the thread to throw an exception and then shut itself down (or something like that). Worth a look. Also the thread pool itself is very good.
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
My bet is that the thread does InsertItem. This calls the wrapper function which calls SendMessage(). This needs to be processed in the UI thread, which is waiting for the thread to terminate. You need to check if its terminated, if not, pump any messages in the queue locally and then check again until the thread terminates correctly.
Roger Allen - Sonork 100.10016
If your dead and reading this, then you have no life!
|
|
|
|
|
Hello everyone,
in my application i have one main toolbar & each button has a toolbar associated with it (Drop-down toolbar). on click of a button int the drop-down toolbar i want that image to come on top on the main toolbar. i dont know how to do this....can anybody help me?
thanx
|
|
|
|
|
Hi !
I'm wondering if it's possible to put a template class in a vector.
Let me explain :
I have a class which is a template, for instance
template <class t="">
class JSObjectList
{
...
};
In my app, I'd like to have a vector of elements of this class, which would look like this (I guess) :
std::vector<jsobjectlist<t> >
If I try to do something like this, the compiler is complaining about many things....so before trying to understand each error, I'd like to know if what I'm trying to do is allowed in C++ !
Thanks !
Jerome
|
|
|
|
|
It's allowed.
std::vector< JSObjectList< int > > However, there are a number of constraints your type will have to satisfy to be usable with vector. An exact list is hard because it depends on what you're trying to do with it - C++ only instantiates the functions you use, so you only need satisfy the constraints of the functions you're using.
At minimum, your template class JSObjectList needs to expose a copy constructor, and an assignment operator.
|
|
|
|
|
Is anyone who knows how to add a button (toolbar) to the Microsoft Outlook Express. I know there are some aplications which add extra buttons to OE. The second question is how to call a function when an email arrvies?
Please help
|
|
|
|
|
When I compile my project, I have a strange error:
Error spawning cl.exe
Creating browse info file...
Error spawning bscmake.exe
CabCal.exe - 1 error(s), 31 warning(s)
I never had this before  !! I just changed some lines and now, it gives me this error !!!
Somebody knows what happens here ???? 
Thanks
|
|
|
|
|
If there is no problem with your code, then try restarting the machine ( i guess you must have done that by now) if still that didnt solve that problem then you need to check out the microsoft side, its a know bug.
The World is getting smaller and so are the people.
|
|
|
|
|
Hum, really strange problem: now that works fine.... and I didn't restart my machine
And I didn't change anything 
|
|
|
|
|
Hi!
I have a problem. I will connect to rman with visual c++ 6. the code is
sConnect.Format("%s/%s@%s",sUser,sPW,sDB);
char *pConnect = new char[sConnect.GetLength()+1];
strcpy(pConnect, sConnect);
nError = _spawnlp(_P_WAIT, "rman", "rman", "target",pConnect, NULL);
It works. But now I want to write commands to the rman console but it don't work. My code is
sConfigure.Format("Configure default device type to %s;",sTyp);
char *pConfigure = new char[sConfigure.GetLength()+1];
strcpy(pConfigure, sConfigure);
nError = _spawnlp(_P_WAIT, pConfigure, NULL);
The programm don't wrie the command "configure default device type to disk" in the console.
Can somebody help me how I can write commands in the rman console?
Thx!!!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
