>>What's in your clipboard? Someone's email address. How boring. Actually, it's not even true any more. Since responding to this posting, my clipboard content has changed to "What's in your clipboard?". Keith

Alan Thanks for your response. I'm still floundering a little. When you say to start with an array representing the unknown region I presume you mean one array element per (unknown) pixel? It's the next bit I'm having real trouble with. Trace out line segments at different angles. How many different angles? It's always possible to construct a line which passes through any two given points, so for every white image pixel and every pixel in the unknown area it will always be possible to construct a line, at some angle, which intersects both. It seems to me, therefore, that if you try enough angles then for any one white image pixel, every pixel in the unknown area will get some votes, with the pixels nearest to the white image pixel getting the most because a wider range of angles will result in a line which passes through them due to rounding errors. I suspect I may have misunderstood something in your explanation. Keith

Mark >>I'm thinking... If you are still thinking, stop. What my computer needed (apparently) was a good night's sleep. This morning I cannot reproduce the problem. The application works perfectly! Contrary or what? I've not even rebooted in the interim. At the end of the day I just shut the lid on my laptop and it hibernates. I fired it up briefly at home yesterday evening to check my emails (didn't even try to run the failing app) then this morning I started again, connected to the same office network environment as yesterday, and the problem has magically gone away. I guess we shall just have to put it down to one of those strange abberations that computers seem to have from time to time. If anyone has any theories I'd be interested to hear them but I suspect they will have to remain just that, theories. Keith

I think you're probably right that it's not CFileDialog's problem as such. Something else about the application is causing the problem. I'm pretty confident that if I created another dummy MDI app it would not exhibit the problem because I already have other real, not dummy, MDI apps which don't exhibit this behaviour. What I think I might do is take a copy of the failing application and start knocking bits out of it to see if I can find something which makes it work. If I don't get anywhere that way then I may try as you suggest, start with a brand new project then gradually add back in the functionality of my app. It's going to be a long haul, though. There's rather a lot of it. Keith

>>I'm thinking... I'm giving up for today so no rush. One more bit of information. File Save As exhibits same long delay before displaying dialog. Keith

Mark I was wrong. It doesn't hang forever. I decided to leave it whilst running a stop watch. After clicking File, Open there is (on my laptop) a 1 minute and 50 seconds delay before the standard open dialog appears. This is solidly repeatable. If I cancel the open-file dialog and then click File Open again then there is another 1:50 delay until the open-file dialog reappears. I pasted in your code snippet and that also takes nearly 2 minutes before the dialog appears so it's not the filters which are the problem. The identical code, pasted into another application, works without any delay. Keith

Thanks for the suggestion. I did follow up the link you posted but I think that situation is different. It was a crash, rather than a hang, and it occurred after the open-file dialog box was displayed. In my case the dialog is never displayed. It hangs before it gets to that point. Keith

Mark Salsbery wrote:

Does it timeout and eventually show or hang forever? Is it waiting for a reply from a network drive?

So far as I know it hangs forever - but forever is a long time :) I may just not have stuck around long enough. I don't think it's a network drive issue because I have two similar applications. One always hangs and the other always works. There is clearly a tangible difference between the two but I can't figure out what it is. Keith

I am trying to write some code to reconstruct a small irregular shaped "hole" in an image where the image data has been lost. My hope is that by analysing the surrounding image I can make an intelligent guesses as to what the missing part might look like. Using standard edge recognition techniques I have managed to identify strong contrast edges in the surrounding image. The next step is to identify which of these edge lines cross the hole and to extrapolate them across. The image at http://www.bracknellbridge.com/images/Thinned1.bmp[] shows where I'm at. The dark surround represents part of the image for which data is intact and the light grey centre is the area I am trying to reconstruct. The white line segment above and below the light grey area represents a high contrast edge. To the human eye it looks like this line probably crosses the light grey area. What I need is a general algorithm to recognise this situation and extrapolate the line across the hole. It has been suggested that the Hough transform might be the way to go but I'm struggling with how to apply this in a practical sense. Is the idea to consider every possible pair of points and calculate the parametric equation of the line passing through them, then see which values are most common? It sounds simple in theory but I can think of practical problems. If points A and B are on line 1 which is very close, but not identical, to line 2 which joins C and D how can I ensure they are interpreted as 2 votes for "nearly" the same line? How close is close enough? If anyone has some practical advice or ideas I should be very interested. A practical code example of the Hough transform would be especially useful. Keith

I have an MFC, multi-document template application, built using Visual Studio 6, which has been working for a long time now. Recently I moved to a new development machine and now my application hangs whenever I click the File menu and choose Open. I have run it in debug mode and traced into the MFC code. The point of failure is in DlgFile.cpp(part of Microsoft's MFC source) at line 108 where it calls ::GetOpenFileName(&m_ofn). It goes in there never to return. I spotted that the m_ofn structure points at a hook function _AfxCommDlgProc so I set a break point in that. The dialog receives the following windows messages before the application hangs: WM_SETFONT, WM_INITDLG, WM_SHOWWINDOW, WM_WINDOWPOSCHANGING, WM_NCCALCSIZE, WM_CHILDACTIVATE, WM_WINDOWPOSCHANGED then WM_SIZE. The WM_SIZE message is processed OK and AfxCommDlgProc then exits back to code for which source is unavailable. My dialog never receives another message. As a control I then tried exactly the same experiment on another MFC application of mine - one which doesn't fail. It acts exactly the same except that the WM_SIZE message is followed (after a short but noticable delay) by a WM_SETREDRAW after which the Open File dialog box appears. If I let the failing application hang then click on Debug, Break, the call stack is singularly uninformative: NTDLL! 7c90eb94() USER32! 7e4195f9() USER32! 7e4196a8() BROWSEUI! 75f8afc9() BROWSEUI! 75f8b591() SHLWAPI! 77f69588() NTDLL! 7c927545() NTDLL! 7c927583() NTDLL! 7c927645() NTDLL! 7c92761c() KERNEL32! 7c80b683() I am at my wits end. I am using the standard MFC file open mechanism with no undue cleverness. I can see no tangible difference between the failing application and a different application which works, apart from the file types it's looking for. Has anyone any sensible suggestions what to try next? Keith

I think pockets were bigger in those days too. My "Pocket" Oxford measures 6"x3" by about 2 inches thick. Keith

Simon Stevens wrote:

From the article: Computer manufacturer Dell recently even tried to trademark the term "cloud computing", although its application was refused.

Presumably the Met. Office* had a prior claim? Keith * Lest I be accused of the same buzz phrase/parochial word fondness I criticise elsewhere, that's standard UK speak for the Meteorological Office

I do now understand that this is the case but it's a striking example of how some folks seem to go around inventing new words, willy-nilly. I have a suspicion that in many cases it's because they think it sounds trendy, rather than through any actual need. Incidentally, I'm not overly fond of the word "methodology" either. It doesn't feature in my (admittedly aging) Pocket Oxford Dictionary. What's wrong with real words like "technique" or, if you want to be a bit grander, "philosophy"? I realise that I am an old and reactionary dinosaur and that my rants against the inevitable evolution of the English language are in vain, but it keeps me happy on a damp Tuesday morning. Keith

The following quote from the recent article about Microsoft Visual Studio 2010 had the whole office in stitches: "We'll include in the [VSTS] box an Excel workbook for teams that are leveraging, say, the Scrum process so they can get burndown from their project." I'm sorry. Is this some language very similar to, but subtly different from, English or have I accidentally stumbled into a parallel universe? Here in the UK we have this theory that we invented English but not one person in my office had the slightest notion what this author was on about. Discussions as to whether burning down the project is a good or bad idea are ongoing. Keith