Nope, no parameters are set. I think the framework creates a new document within the call though so I guess somewhere in there, I'm doing something dodgy. I'll have another look tomorrow (if I get over this stupid tummy bug!). Success is 99% failure

Okay, I've been struggling with this problem for the best part of a week now. If I don't find a solution soon, my PC's going for a flying lesson :mad: I'm developing an MFC app, in VC++ 6.0 with the latest service patch applied, running on Windows NT. The program works fine in debug mode, but dies a horrible death in debug mode. "The instruction at "0x00918ec3" referenced memory at "0x00002301". The memory could not be "written". Here's what I've tried so far... 1) Message boxes to try and pinpoint where the crash is occurring. After a bit of trial and error, the crash appears to occur sometime after a call in the application part of the code 'MyApp.cpp' : 'if (!ProcessShellCommand(cmdInfo))'. The crash occurs after this call is made, but before it returns. The last part of my own code that is called (as far as I can tell) is 'OnInitialUpdate' which is within the view. Now as far as I can see, it looks like the crash isn't happening in any of my code. No doubt it's somthing I've done, I just can't see where I did it! 2) Having drawn a blank with my usual method of release-mode debugging, I turned to google. I've read most of the debugging tutorials here on codeproject now and thought this might herald an answer, but the crash address doesn't appear to be relevent to either the program itself or any of the .dlls it loads (I used dependancy walker to have a look at what it uses). Their base addresses seem to be in the range 0x5F400000 (MFC42.dll) to 0x780C0000 (MSVCP60.dll) - nowhere near "0x00918ec3"! Have I missed / mis-understood anything obvious? What should I try next? I'd appreciate any suggestions you may have - thanks very much in advance! Success is 99% failure

It's a bit dirty, but how about.. FILE* ofp = fopen("yourfile", "r"); if(ofp != NULL) { fclose(ofp); // File exists - go ahead and call Bitmap::FromFile } else { // File does NOT exist - warn the user } ..should work alright. Success is 99% failure

Hi there, I'm in the process of writing a multi-threaded webcrawler using VC++ 6 and MFC. I've got the basics down, but I can't help feeling like I'm going about it the wrong way. I've got a Doc/View set up and when the user chooses some options (base URL / how many threads to launch), the document launches the first thread. To do that, it sends a message (using postthreadmessage) to the worker. The worker then goes and downloads the first page, parses it for links and sends a message back to the document via the view as I wasn't able to send them directly to the document... As a side note, that process feels a little clunky. It seems logical that you'd probably not want to send messages direct to the document, but I couldn't see where else to do it; afterall, the document's storing all the links the workers download. ...anyway, once the document knows there's an idle worker, it gets all the links from the worker (calls a member function on it to retrieve the data - should be safe as the worker is idling now?) and adds them onto the (end of) master list. Since the document knows there's now a free worker, it pulls off the next link on the master link and launches the worker off again. Does this sound like a reasonable way of doing things? I'm not sure quite why, but it feels a little in-elegant, and I can't help feeling there's probably a better way of doing it? Any suggestions / comments would be most welcome! Cheers, Jon Success is 99% failure