Well that is a BAD thing. However, casting to (LPTSTR) to deal with some MS API routines that can not or do not have the arguments defined as (LPCTSTR) works just find AS LONG AS you know the API will not write to the string. Many API's have arguments that have double duties and thus can not be defined as (LPCTSTR). Tim Smith I'm going to patent thought. I have yet to see any prior art.

My article Enabling context help in a form view[^] may be of help. Roger Allen - Sonork 100.10016 If your dead and reading this, then you have no life!

That checkbox never worked for me.... I would modify .dsp to: LIB32=link.exe -lib # ADD BASE LIB32 /nologo # ADD LIB32 /nologo TargetPath=.\Release\My.lib from LINK32=link.exe # ADD BASE LINK32 /nologo /subsystem:windows /dll /machine:I386 # ADD LINK32 /nologo /subsystem:windows /dll /machine:I386

will1383 wrote: ...which IMO makes no sense at all to re-invent the wheel. They don't seem to mind so why should you? Let it be known (to the powers that be) that such a solution is non-standard and prone to problems. I worked on a project once where it was decided that a dialog's "X" button and the Cancel button would each do different things. If the dialog was actually doing something, rather than just accepting input from the user, it had both Close and Cancel buttons. I hate it when goofy standards are put in place, only to propagate through the annals of the projects. Changing them requires an act of Congress.:mad:

Okay, then there is several options you can do to really fix the CFileDialog. The following alternative uses MFC's CFileDialog (since that seems to be what you want to use), but you could just as easily use the method that it wraps, GetOpenFileName. First, create an instance of the CFileDialog. When you've done that, get the m_ofn member struct from the instance and perform the following. OR the Flags member of the OPENFILENAME structure with OFN_ENABLEHOOK. You might also want to OR it with OFN_NODEREFERENCELINKS while you're at it to keep users from making a shortcut to a location outside your limited scope. Set the lpfnHook to a HOOKPROC callback. From there, your options are many. In WM_INITDIALOG, you could simply remove the the "Up" button entirely based by getting the toolbar in which its contained (based, perhaps, on the window class for the toolbar which Spy++ can give you, which is ToolbarWindow32, or getting it based on the tooltip or some other identifier) or handling the message generated when you click the up button. Spy++ reports this as either WM_USER+300 (aka 1) or WM_USER+302 (aka 2) (both were posted as 1211 (based on aforementioned aliases). What those mean you'll have to dig-up. All the other messages were mostly painting and mouse messages - nothing that would seem to help. It's surprising that handling the click messages and returning true didn't help. Did you handle WM_LBUTTONUP? That directory change is triggered then and not during WM_LBUTTONDOWN. Just out of curiosity, how did you determine if the "Up" button was being clicked? -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----

:wtf: OOPS... there is something wrong... CreateProcess() should return immediataly, and if you want to wait for the created process you must use : WaitForSingleObject(pi.hProcess, WAIT_OBJECT_0)... ?

Ok, I did finally find it. Turned out that my global datasize number was being clobbered all the time, aka ending in a data size of 0 to be written. Thanks for all of your help! I REALLY appreciate it! Woo HOO!! Dan

As it turns out, when using the LoadIcon you must get the HINSTANCE of the dialog in the dll, not the application HINSTANCE. That fixed my problem. thanks for the help though! :)

ugh. Clearing out the memory isn't doing it either. Would make sense if the handle was bad or a pointer or two was bad, but I can't find any problems with them. It would help if Microsoft would actually give more error information instead of a BOOL being returned. That's utterly useless in this case. :~ I'm passing in the pointer to the function that makes this call and just setting the lvItemList.pszText to it. I tried copying over the text to a local pointer thinking that might be the problem, but that ain't it either. :( What else do I do? :((

Just create the edit control of a size that fits the number of lines that you wish to display. Then, make sure that the ES_AUTOVSCROLL style is set. Problem solved. You also may want to set a fixed-pitch font and handle the background color to make it appear like a console window.

Woo Hoo! I finally understand it! Turns out that I need to be using the RT_GROUP_ICON because I'm not using hardware-dependent icons. :) I was then able to try other resource types and successfully got the information I needed. Thanks Guys! I really appreciate the help! Dan

Yup, as long as thread B is making the call.

Yes that is true. I found a really weird case though. As it turns out, the FILE stream buffer is allocated in 4k segments. When you do an fread, the fread checks the size left in the buffer and puts as much as it can into that buffer and sets a flag saying the buffer is full. At that point a new buffer is allocated and fread continues along it's merry way. In my case I'm using fgetwc, which gets 2 characters (4 bytes). It checks to see if there is enough space in the buffer for the 2 characters, and if so puts it in. If there is not enough space (meaning there is only 2 bytes left in the buffer), it returns 2 chars worth of jargen, causing the application to bomb. Becuase it only occurs when there I am calling fgetwc and there is only 2 bytes left in the buffer, I am rarely seeing this case but am able to easily reproduce the problem. My solution, to not use fputwc and fgetwc anymore, but to use fwrite and fread. You can find this in the _FGETWC.C that came with VC++ 6.0

will1383 wrote: I just wanted to be sure there were no other tricks out there I didn't know about. Yeah! It's better being on the safe side! :) Rickard Andersson8 Here is my card, contact me later! UIN: 50302279 E-Mail: nikado@pc.nu Interests: C++, ADO, SQL, Winsock, 0s and 1s

I think you need to use the MFC thread functions within MFC, AfxBeginThread(). Unless theApp.RunDialog has a function signature of a worker thread, you might want to take a different approach. Define a worker thread with a signature like UINT MyControllingFunction( LPVOID pParam ); and use that as the first parameter to AfxBeginThread. Pass theApp as a second parameter and from inside your worker thread, call RunDialog. Here's a sample from MSDN using a CMyObject instead of theApp... UINT MyThreadProc( LPVOID pParam ) { CMyObject* pObject = (CMyObject*)pParam; if (pObject == NULL || !pObject->IsKindOf(RUNTIME_CLASS(CMyObject))) return 1; // if pObject is not valid // do something with 'pObject' return 0; // thread completed successfully } // inside a different function in the program . . . pNewObject = new CMyObject; AfxBeginThread(MyThreadProc, pNewObject); . . .

The debug DLL (MSVC60D.DLL) may be installed but not the non-debug DLL.

Pass NULL for the first parameter inplace of "cmd." Post an example of the command line you pass in as the second parameter "cmdline." Kuphryn