Thanks for your reply. It was found in a part of our app that allows the user to select a number of files in an explorer-type window, and then perform an action on them. The edit control is used as the user may wish to type the paths instead of picking them. The intention is not that the user then looks through the unmanagable list. I don't really see that it is that unusual to have an app do that kind of thing. Anyway, I now know that it is not something we are doing wrong, or can do differently (apart from use an different method of letting the users see what they've picked of course), so that will suffice for now.

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
"A problem well defined is a problem half-solved" – John Dewey

Hi, [I have posted this already on the C/C++/MFC forum, but have since found that it is a Windows thing rather than a C/C++/MFC thing, so have re-posted it here.] I have a very strange problem with single-line edit controls in Windows 7 and Windows 2008 Server, where once the number of characters exceeds a certain number, the contents become invisible. The text is still there, and can be copied, edited etc, but it is just not shown. Deleting characters makes it re-appear. I have reproduced this in a new MFC project, using Visual Studio 2010, just by making a dialog app which has a single-line edit control on its dialog. I have also reproduced it in a new WFC app with a single-line edit control. I have found that the exact number of characters required to make the text disappear depends on the text. For instance, filling the control with the letter 'i', it takes 16379 chars to become invisible, but for the letter 'W' it takes 3275. For '_', it takes 5459. I wondered if it was the size in pixels that caused the problem, and found (using GetTextExtent on the edit control's DC) that for the letter 'i' the width was 65516 pixels, 'W' was 45850 pixels, and for '_' was 43672 pixels, so I can't see any relationship there. (I am building the app in Visual Studio 2010 on Vista, though that doesn't make any difference, as an old version of our app built in VS2005 behaves the same in Win7). Does anyone have any ideas of what is going on? Paul.

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
"A problem well defined is a problem half-solved" – John Dewey

Hi, I have a very strange problem with edit controls in Windows 7 (Ultimate), where once the number of characters exceeds a certain number, the contents become invisible. The text is still there, and can be copied, edited etc, but it is just not shown. Deleting characters makes it re-appear. I have reproduced this in a new MFC project, using Visual Studio 2010, just by making a dialog app which has a single-line edit control on its dialog. I have found that the exact number of characters required to make the text disappear depends on the text. For instance, filling the control with the letter 'i', it takes 16379 chars to become invisible, but for the letter 'W' it takes 3275. For '_', it takes 5459. I wondered if it was the size in pixels that caused the problem, and found (using GetTextExtent on the edit control's DC) that for the letter 'i' the width was 65516 pixels, 'W' was 45850 pixels, and for '_' was 43672 pixels, so I can't see any relationship there. (I am building the app in Visual Studio 2010 on Vista, though that doesn't make any difference, as an old version of our app built in VS2005 behaves the same in Win7). Does anyone have any ideas of what is going on? Paul.

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
"A problem well defined is a problem half-solved" – John Dewey

Hi, I have an application that uses CHtmlEditCtrl for some WYSIWYG HTML editing. All is good, except that I need to add some custom protocols to the Hyperlink editor dialog. I have tried a couple of ways of doing this, but have some up against problem with each. The things tried are: 1. Open our own dialog in place of the in-built: ok if adding a new link, but when editing a link don't get the default behaviours of selecting the whole link text if caret is in middle of link, and can't get the existing URL to edit. 2. Catch the creation of the dialog with a hook, so I can fiddle with its controls: no good - the hook doesn't get entered on creation of the dialog I would prefer option 1 if I can: a. get it to select the whole link text (may not be required, but better if it can) b. retrieve the URL of the selected link Does anyone have any ideas? Has anyone managed to successfully intercept the Hyperlink dialog in any way? Thanks, Paul.

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

Hi, By default, when using Ctrl+Tab or the Window menu to switch between windows in a standard MDI app, it leaves the window list in its current order. The behaviour in Visual Studio (ignoring the popup which lists the windows) always puts the current window at the top of the list of windows. This then allows easy toggling between two top windows using Ctrl+Tab, as the previous window is then made the second in the list, so you don't have to cycle through all the open windows to get back to the one you started from. I am trying to replicate the VS behaviour in an MFC MDI app, but can't find a way of re-ordering the window list. Has anyone else managed to do this? Paul.

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

Many thanks for the info. It gives us some other things to play with, though given that we're only in practice looking at two or three alternative servers, I think for now we'll probably just ask the user to choose which one to use the first time they need it!

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

Thanks for your reply. This makes perfect sense - I hadn't taken into account the time for a machine to pull it's finger out and get around to responding! I had another couple of thoughts though: Given that all I want to do is to offer a user a reasonably sensible default server share to use for storing 'local-ish' cached data, from a list of admin-configured possibilities, what about either finding out where the server is geographically, and seeing which is closest to the client, or even finding out the server's time zone, and using the one with the smallest offset from the client? Not sure if either of these are possible or feasible. Any ideas?

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

Does anyone have any ideas on how to detect from a UNC share how remote (or fast) it is, i.e. is it on LAN or WAN etc? I need to be able to look at a list of UNCs and determine the fastest accessible one, to use for storing some temporary files for fast access by client apps. I have tried using MultinetGetConnectionPerformance to determine the connection speed, but it doesn't return sensible results.

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

I have now! See my other reply. Thanks.

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

Thanks for your reply. It's not that - I've found it: VC6 used RichEdit 1.0 controls by default, whereas VS8 uses RichEdit 2.0 controls by default, so that is where the difference lies. Version 1.0 seems to count line breaks as 2 chars, whereas 2.0 counts them as 1 char. I was getting my positions from my CString, which contains CR+LFs so counts line breaks as 2 chars. I have changed my code to use the Find facility (EM_FINDTEXT/EM_FINDTEXTEX) in the RichEdit control, and all is now OK. (Not really sure why I didn't just use that in the first place!)

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

There seems to have been a change in behaviour between VC6 and VS2005 builds when calling SetSel / EM_EXSETSEL in a rich edit control. I have code which emboldens certain lines of text, which used to work in VC6, but since moving to VS2005 has come up with the wrong results. The code is something like:

CString sText;
pEdit->GetWindowText(sText);

CString sSection = "SectionHeading";
int nPos = sText.Find(sSection);
int nPosEnd = nPos + sSection.GetLength();
pEdit->SetSel(nPos, nPosEnd);

If the heading is at the start of the text, then it's ok, else the selection is offset by the number of lines, which makes we think that the old code counted line breaks as two characters, but the new code counts a line break as one character. In the sText, the line breaks are definately two characters in both VC6 and VS8 builds. Any ideas anyone?

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

If I am debugging a (32-bit) app using VC6 on Vista 64-bit, and I break out, then the app I am debugging is left running, despite the debugger ending the debugging (apparently successfully). The process appears in task manager, but attempts to kill it simply do nothing (no error, just nothing). The app is locked, so I can't rebuild it, so it's definately loaded into memory somehere. The only way to get out of the situation is to close my VC and re-start it. Anyone else having this problem? Any one know a fix? Paul.

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

Found it: my PS2 mouse is bust. I've switched it for a USB mouse, and I no longer have the beeps. I arrived at that because it started making my mouse pointer jump, and doing a scroll and a right-click, every time a system beep happened.

Dave Kreskowiak wrote:

You can't tell me that you haven't thought of doing this yourself!

Yes, I have, but nobody's that much fun around here! In a previous company we used to do that kind of thing all the time. Ah, those were the days...

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

Thanks for the ideas Dave. My thoughts on those: 1. That was my first thought (which is why I posted on the Hardware board), but as far as I can see the fan is OK, processor temp OK. I would kind of expected the occasional freeze if this was the case anyway. Still, jury's still out on other hardware problems. Bit of a coincidence that a colleagues PC did the same though. 2. Mmm, thought of that too. In some ways more likely, as that would explain why my PC was not the only one, but our AV is generally good - though I know nothing's 100% effective - so we would usually consider ourselves to be (nominally) "virus-free" 3. No-one laughs at me and gets away with it. Do you hear me? NO-ONE! ;P

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

Recently, my PC at work has decided that every 5 minutes or so it will beep several dozen times. The beeps are not evenly spaced, and so I wondered if my PC is trying to send a morse code distress message! Strangely, a colleague's PC did exactly the same about a month ago, so he disconnected the speaker. We never found out what was causing it. I've no idea whether this is a hardware thing, or an OS thing (we're both on Win XP). I don't know where to start looking. Does anyone have any idea what it could be? Has anyone had the same thing? Is anyone fluent in morse code, and translate the PC's distress call?

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

I frequently use SetRedraw(FALSE) -> do drawing stuff -> SetRedraw(TRUE), but I sometimes have an outer drawing loop that does this, which calls, as part of the drawing, something else that also turns off/on redrawing, thus overriding the 'outer' loop's redraw flag. I have wondered if anyone knows of any way of determining the current value of the redraw flag for a window?

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

Just looked at source for CEditView printing, as suggested by Jack Squirrel in his reply[^], and it seems that MFC uses a similar method, by having a guess, and then adjusting the string until it best fits. They do that for all platforms (MFC doesn't use DrawTextEx anywhere as MFC pre-dates the function). Looks like that's what I'm going to have to do after all :sigh: , but at least our customer will be happy! :)

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV) -- modified at 5:05 Monday 10th October, 2005

Mmm. Just looked at that. It uses a method similar to the one I was avoiding :~ by guessing how many might fit, then decreasing/increasing the length of the string until it fits best. Oh well, looks like that's the way to go. :sigh:

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

Mmmm. That's what I was afraid I may have to resort to. It's not very efficient for huge chunks of text, which is why I didn't really want to do it this way in the first place (our reports are often very long, with large chunks of text), but I guess I can optimise it by splitting the string up and testing it using a binary method if it's over a certain length. I guess as it's only a problem on Windows 98, I'll just do it this way for that - maybe that'll teach them to use a real(-ish) OS! Thanks for your time looking at this! Paul.

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)

Thanks! :-O Using GetTextExtent/TextOut is all very well, but that doesn't tell me how much of my text will fit into a given rectangle. Once I've drawn my clipped text onto the bottom of my page, I need to know where in my text string I need to start drawing on the next page. (I do use MFC BTW, but I don't think that's relevant.)

"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)