Client area painting must occur in the main Windows thread. The problem is that the thread grabbing the frames is not the main Windows thread. So while it's drawing to the client area, any old windows message might come along and cause a crash as the two threads bump into each other. This is especially true when resizing - there are lots of "PAINT" messages hitting the dialog, and there's a good chance that PAINT handling is happening at the same time your other thread is drawing to the client area. Result is a crash. The solution is to have the main windows thread do the drawing. So you'll need a way to move the frames from the grabber thread to the windows thread, and signal your dialog that it's time to draw a new frame. You could try using a custom message, e.g. WM_USER+ ( see here: http://www.ucancode.net/Visual_C_MFC_Example/RegisterWindowMessage-WM_USER--VC-Example.htm[^] ). You can allocate a buffer to hold the frame and pass the pointer to that buffer as the LPARAM. The frame-grabber thread then just needs to PostMessage(...) to the Dialog. On the Dialog side, add the handler for the WM_USER+ message to draw the image pointed to by LPARAM. Don't forget to deallocate that buffer when done! This is just one example for moving information from some "outside" thread to the main windows thread. You can probably find many others. - Bob

Bob Ciora

Just pull out the useful part from the link. http://blogs.microsoft.c.il/blogs/alon/archive/2007/05/29/Native-Callback.aspx I genrally use method #4 because many of my callbacks are in the form of interface classes (e.g. "ICallback"). I create a "bridge" class (unmanaged class built in a managed dll) with an implementation of the unmanaged callback that marshals any parameters to the managed world, then calls a similar method on a gcroot'ed handle to a managed interface.

Bob Ciora

The segmentation fault is because the scanf statement is writing a new value to the POINTER hello, setting it to the value entered by the user. So if the user enters "4", hello is now a pointer to "address" 4. This will crash. Do this instead: int hello; printf("Hi, Enter any value > "); scanf("%d", &hello); switch(hello) { ... ... } Bob Ciora

I'm not sure what you're doing with phole, but it's being assigned the same value in every case of the switch statement. This is inefficient. Most of all, though, you don't need phole at all. In addition, you don't need tar_row and tar_col either. Your switch statement can simply increment or decrement hrow and/or hcol directly. When you're finished, just convert these values back into holeidx. You can stop here. This will solve your problem. Also... You can remove the switch statement altogether and use a lookup table. Translate the '1' through '9' values into an index into this table. Table entries would be simple structs holding the modification to the row and column variables. You only need special traps for the 'q' key. This table could be simplified even further by storing the modifier to holeidx. But this table would have to be built at run-time, since the value of size isn't known until then. Bob Ciora -- modified at 18:04 Friday 27th January, 2006

As cmk mentioned, you should list certain situations and scenarios. You mentioned that you've used different sync objects in the same situtation, and they all worked fine. What situation and which objects? Bob Ciora

How about the old standby, sscanf? There is also a wide-character version, swscanf. If you've eliminated the whitespace around the string-represented floating-point value, then the following will work:

// input: CString sData

float fValue;

// sscanf will return the number of items pulled out of the string
int nResult = sscanf((LPCTSTR)sData, "%f", &fValue);
if( nResult != 1 )
{
// Didn't find a floating-point value. Take corrective action...
}

Bob Ciora

I assume member is your STL list. What are the contents of the loop itself? Bob Ciora -- modified at 7:23 Tuesday 22nd November, 2005

Have you changed any of those 4 files in a while? This might be caused by those files having a bad date...a date that's in the future and causing them to always be "out of date" since they're always newer than the final executable. Maybe try opening each of them, adding and deleting a space, then saving them back to disk. Bob Ciora

Actually, in strictest terms, your test whiel( !pSomethingfound ) violates "decent" coding standards. Only booleans should be tested in this manner. A pointer should be explicitly tested against 0 (or NULL, if defined). Just my itty 2 cents ;) Bob Ciora

The documentation for CreateDirectory[^] does mention that it will only create the final directory in the specified path (c.f. the comments for ERROR_PATH_NOT_FOUND). There is a suggestion at the MSDN site to use the SHCreateDirectoryEx function. However, the documentation for this function would indicate that it won't work on earlier versions of Windows. The alternative is to parse your path string (for the '\\' or '/' characters) and create the intermediate directories as well. You can use CString to locate the first occurrence of the character, do a SetCurrentDirectory and, if that fails, CreateDirectory. Repeat this process until you've parsed all subdirectories in the path string. Bob Ciora

If you've copied the same code snippet and it works everywhere else, then ponder what's different. The "this" pointer you're passing...is "this" actually a window derivative? The error messsage suggests that this might be the problem, though, it doesn't state it with certainty. You may want to try a Debug build, linking MFC in a static library, and stepping directly into the CFileDialog code. If I couldn't figure the problem out by analysis, then this is what I'd do. Step through MFC until the error is generated. Bob Ciora

Further on the third point, you should have an option to display the Call Stack in a window (most likely View->Debug->Call Stack, or Alt-V,D,C). The current level will be highlighted. Trace down the call stack to the first routine that you recognize, and double-click there. This should pop up a window with your source code so that you can see where the offending call is being made. The nice thing about the call stack is that you can display different variables in the Watch Window, depending on where you are in the call stack. As you double-click to display a function at various levels in the Call Stack, Visual Studio reverts to that function's context, so you can display local variables. The Call Stack window also shows the parameters that are passed to functions, so you can see if something was sent that "broke" stuff. Bob Ciora

Try a semaphore if this is the desired behavior. Bob Ciora

As mentioned, the main is exiting before the thread can even execute. To wait for the thread to terminate, you can do a WaitForSingleObject(hThread, INFINITE);. This will wait for the thread handle to become "invalid," which occurs when the thread terminates. At that point, you should also do a CloseHandle(hThread); before exiting. Bob Ciora

You can use MoveWindow[^] any time after the base class' OnInitDialog has been called. Bob Ciora

Works as coded. Bob Ciora

Sorry, I'm at work right now and don't have much time to respond. You should consider using the OnUpdate... handlers to check and uncheck the items. These are called by MFC for each menu item just prior to displaying the menu. Here, you operate on a CCmdUI object for that menu item, telling it exactly how it should be displayed. So if you keep a flag indicating the checked state of "option," you can easily check/uncheck "option" and "another_option" based on that state. Examples would be something like this, using both the On... and OnUpdate... handlers:

BOOL m_bOptionSelected = FALSE; // should be member variable...

void OnOption() // called when Option selected
{
m_bOptionChecked = FALSE; // turn off check for this option

// ... all other processing for Option

}

void OnAnotherOption()
{
m_bOptionSelected = TRUE; // turn on check for "option"

// ... all other processing for AnotherOption

}

void OnUpdateOption(CCmdUI * pCmdUI)
{
// This line "checks" Option if the flag is marked, or clears the
// check if not.
pCmdUI->SetCheck( m_bOptionSelected ? BST_CHECKED :
BST_UNCHECKED);

pCmdUI->Enable(TRUE);

}

void OnUpdateAnotherOption(CCmdUI * pCmdUI)
{
// Reverse: "uncheck" AnotherOption if Option is checked, check
// it if not.
pCmdUI->SetCheck( m_bOptionSelected ? BST_UNCHECKED :
BST_CHECKED);

pCmdUI->Enable(TRUE);

}

Hope it helps. Bob Ciora

You'd have to include a sizeof(arg1) to account for the stack space used by arg1 and include it. Something like this:

char \* ArgPtr = (char \*)&arg1 - sizeof(arg1);
if( ArgPtr == (char \*)&arg2 )
{
    // Stack growing the other way...
    ArgPtr = (char \*)&arg1 + sizeof(arg1);
}

list = (va\_list)ArgPtr;

That oughta take into account whatever way the stack grows. Bob Ciora

If you can always eventually kill it when it returns from one of the library routines, you could always put up a "Shutting down..." type of banner just to let users know that the program isn't hung. Bob Ciora

Probably :p Depends on what's after the output string. If there is more room in the data space, then some poor unsuspecting variable will be stomped. But you won't see that until you need it. Bob Ciora