Re: Glitchy mouse clicks out of sync. with position of caret in RichEdit control and text displayed incorrectly [modified] - C / C++ / MFC Discussion Boards

yeah added.

strmbasd.lib
StillCapture.lib
..\baseclasses\STRMBASE.lib
these are the libraries which we added in additional dependencies

Hi there,

I have a mysterious bug in a rich edit control one of my programs. It is sporadic and I haven't been able to find any way to duplicate it. It just suddenly happens when mid-edit of the text. You go for days sometimes with no occurrence of the bug, then suddenly without warning it will happen.

The richedit class is
RICHEDIT20A

What happens

Part of the text gets displayed incorrectly formatted. If you click on it to set the caret, then some parts are inaccessible. The caret also sometimes isn't synchronised with the click point so you click in one place in the window and the caret gets set somewhere else, usually at the same y coord, and to the left or the right of the click point.

Manifests in many ways but most often, the visual display of the text changes to show the first character of each line on a separate line of the window. Like this:

This is actual text copied from most recent time it happened:

do a search for ,,

Volume envelope for editable waveform instrument (Ctrl + ) - makes a difference for instruments selected not the editable instrument

Mid edit, this suddenly changed so it was displayed as

|d
o a search for |,,
|V
olume envelope for editable waveform instrument (Ctrl + ) - makes a difference for instruments| selected not the editable instrument

There the | shows the furthest right you can set the caret in each line. So e.g. if you click to the right of the first d, then the caret gets set at the start of the line, not after the 'd' as you would expect.

If you click to the right of instruments in the second line the caret gets set immediately after the s and you can't set it any further to the right than that.

You can highlight text in that "inaccessible" area of the text with click and drag, but the caret doesn't change position when you do that.

The same text displays fine in other rich edit controls

If you copy / paste the text to another rich edit, then it displays fine. If you look at the rich edit source, everything looks fine too. No unusual fonts used, it is usually all one font when it happens.

Clears up if you stream the rich edit source code out and back in again

Display issues clear up on resize, and on switch word wrap on / off. But some of the text may still be inaccessible and the caret positioned incorrectly when you click on the text.

Clears up completely if you edit the rich edit source. In the program then what happens when the user does that is that it uses EM_STREAMOUT and EM_STREAMIN to stream the rich edit contents out to a string, display that string in a plain text edit control, then stream back into the rich edit. So, you do that the issue is fixed until next time it happens.

So seems pretty clear that there is nothing wrong with the actual rich edit source for the control.

Example source code

What the richedit source looks like is like this:

{\rtf1\ansi\ansicpg1252\deff0\deflang2057{\fonttbl{\f0\fnil\fcharset0 Arial;}}
\viewkind4\uc1\pard\fs20
do a search of source code for ,,\par
\par
...
}

- that's after an EM_STREAMOUT from the problematical richedit control.

I subclass the richedit, but do nothing unusual in the subclassing (just do a bit of extra processing for WM_KEYDOWN etc), and I also added an option to switch off the subclassing - and it still happened with it disabled.

Can't think of anything else unusual I do apart from the EM_STREAMOUT and EM_STREAMIN.

I have been able to duplicate a few times while running the program in the debugger, and was able to break after the bug happened but again everything seemed fine in the code.

Have any of you got any ideas at all about what this might be? Or any lines of investigation that I could follow up.

Does it happen on multiple computers or just on yours? My first thought is memory corruption, is it somehow possible that you somehow overwrite memory that "belongs" to the rich edit control, like, out-indexing an array or somesuch? Did you try a complete rebuild of the project since you experienced the problem?

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers don't kill programs, users kill programs <
> "It doesn't work, fix it" does not qualify as a bug report. <

It happens on my laptop as well, so two different computers and on my desktop, under Vista and also under Windows 7.

Yes, that definitely sounds like a possibility. I work in C rather than C++ at a low level so have to be very careful about memory corruption, and array overflow etc. I also rather wondered if that might be the cause but hoped it would be something else!

Yes I have done a complete rebuild several times. I have made a fair number of changes in the code and it still happens.

The tricky thing about the bug is that I have made many changes in the code and since it is sporadic and fairly rare in occurrence, I have no idea when it first started as it could have been present and undetected before I noticed it.

So there is no way to know which change in the code introduced the bug (or made it noticeable at least) and no way to "roll back" to a last known "good build".

Anyway looks as if I need to make a careful check for memory corruption.

I generally use Visual C++ 6.0 still, but ran the program in Visual C++ 2010 Express as it sometimes flags memory corruption issues and other issues not noticed by the older compiler. But nothing turned up - was able to reproduce the bug while running it in the debugger, and no issues were reported by it.

Looks like a case for a memory debugger then. So far I've got by without one but this has me stumped, and it's about 15,000 lines of code, possibly more, so it would take a fair while to work through it all looking for the bug.

I'm downloading an evaluation version of Purify for Win just now, and I may try Insure++ as well. Will reply here if it fixes it.

Do say if you have any other recommendations for a good memory debugger for this sort of a bug anyone, preferrably free or low cost as I don't have much of a budget for it.

Thanks,

Robert

Hey, of course you know that this is just a guess from my side, the problem might be something completely different, i just hope i am not stearing you in the wrong direction. I can't really recommend any good memory debugger...
I'm still thinking what else could cause such an odd occurance, if i can think of something, i will tell you...and please if you find out what caused your problem, do send a post here, i am really curious, thanks in advance. Smile | :)

Ah, and maybe show some code about what your subclassed window proc does, maybe there's something i or someone else here can spot that might cause a problem and it slipped your attention...

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers don't kill programs, users kill programs <
> "It doesn't work, fix it" does not qualify as a bug report. <

Yes that's all right, I understand its a guess. But sounded like a good one to me, the way you put it.

Best lead I've had anyway so far.

I don't think it is the subclassing because I do the same thing in all my other programs with no problems at all, it's a standard thing in my software.

What it does is to trap key down, and mouse move, and if the edit control consists of e.g. just a single number - and the user clicks on a number and then drags the mouse up / down far enough (to next or previous line or out of the field if it is single line), it adjusts the number. Increases it if user drags up, decreases it if user drags down. Can also adjust numbers in multi-line text if you use Ctrl + click & drag up / down on the number.

So - sort of way of changing numbers without needing to use a spin control - easier to do often and also works with text fields without a spin control. The routine itself is fairly simple, about 200 lines of code - but uses PostMessage to other parts of the program in order to actually adjust the numbers (to get e.g. the edit notifications working fine so it is just as if the user themselves entered a new number by hand).

Also I disabled it and still got the bug at least once without this feature - that was long ago, not tested it recently, there is room for a small amount of doubt I suppose that it was the same bug still, but same symptoms.

So anyway I think a bit unlikely that that's what it is and it's rather too much code to post here anyway.

Anyway, I just installed the Purify memory debugger. Something interesting happened, not sure if that's what it is. Will post about that in a separate post.

Yes, with Purify, I got an unhandled access violation during start up.

I don't know if it is related. Possibly not, doesn't seem that likely after looking at it a bit closer.

Unfortunately the evaluation version doesn't show any more information, you have to buy it to find out the line of code etc, and the access violation doesn't happen with the normal debug or release build, only with the debug build when run under Purify. For that matter, doesn't happen with the release build under Purify.

But I managed to find the line of code by adding MessageBox statements and seeing where it happened. It happens here:

HBITMAP LoadPicture(LPCTSTR pszPath)
{
 if(pszPath[0]=='\0')
 return NULL;
 if(!FileExists((char *)pszPath))
 return NULL;
 if(!gis_NT_or_new_OS)
 if(bHasExt((char *)pszPath,".bmp"))
 {
  return (HBITMAP)LoadImage(hInstance,pszPath,IMAGE_BITMAP,0,0,LR_LOADFROMFILE|LR_CREATEDIBSECTION);
 }
 {
  WCHAR wpath[AT_MAX_PATH];

  MultiByteToWideChar(CP_ACP, 0, pszPath, -1, wpath, AT_MAX_PATH);

  IPicture* pPic;
  #ifdef _DEBUG
  MessageBox(hwndFocus,"LoadPicture - call OleLoadPicturePath(..)","Debug",0);
  #endif
  OleLoadPicturePath(wpath, NULL, NULL, NULL, IID_IPicture,(LPVOID*)&pPic);
  #ifdef _DEBUG
  MessageBox(hwndFocus,"LoadPicture - after call OleLoadPicturePath(..)","Debug",0);
  #endif
  if(!pPic)
  return NULL;

  HBITMAP hPic = NULL;
  pPic->get_Handle((UINT*)&hPic);
  // http://windowssdk.msdn.microsoft.com/en-us/library/ms678485.aspx
  // The stream must be in BMP (bitmap), JPEG, WMF (metafile), ICO (icon), or GIF format.
  HBITMAP hPicRet = (HBITMAP)CopyImage(hPic, IMAGE_BITMAP, 0, 0, LR_COPYRETURNORG|LR_CREATEDIBSECTION);
  pPic->Release();
  return hPicRet;
 }
}

I put in extra messages to check that wpath was okay and it was. So can't see anything wrong with the code.

It is just "boilerplate code" and again I use it fine in my other programs - it is an easy way to load images in e.g. jpeg format, and documented somewhere on the MS website.

Anyway anyone notice anything wrong with this code?

I'll probably try an evaluation version of Insure++ which has good reviews to see if that gives more information - though it only lasts for I think 3 days so will need to be sure I have plenty of time to work on it during the evaluation period in case it takes a while for some reason.

Robert

Sorry - forgot to say - the crash happens in between the message boxes before and after the line of code

OleLoadPicturePath(...)

Apart from that Purify shows nothing amiss apart from a few bytes of memory not freed when the program closes.

Oh, just for completenes, but surely this isn't it and all my programs do it - Purify shows a strange message about "GetVersionEx" - OSVERSIONINFOW structure size field was not initialized. I mean, the message is clear enough but the strange thing about it is that it gets shown before the WinMain routine gets called (I add a message box at start of WinMain), and a search of the code shows that whenever I call GetVersionEx then the structure size field is initialized.

I don't think that is it though.

One other thing is that I had some code that I use to check for memory leaks and when I compiled with that then got a whole lot of error messages from Purify which may or may not be significant. At first I thought it was because of the access violation, but when I compiled without the memory leak check, it still did the access violation. So that didn't cause the access violation.

Anyway I've removed the memory leak check code from the debug build now - and it was never in the release build (which also had the bug).

Also can avoid the OleLoadPicturePath(..) code for now by commenting out the line

//  if(!gis_NT_or_new_OS)

So then it will use LoadImage(..) instead of OleLoadPicturePath(...) as the preset image for the skin is a bitmap extension .bmp

If the bug goes away that would suggest that perhaps it is OleLoadPicturePath(..) after all, for some reason.

The tricky thing is - as I don't know what causes the bug, I have to run it for a long time like a fortnight or so, after changing anything that I suspect might be the cause of it, before I can tell whether it has gone away or not. But if it is still there, there's a reasonable chance that it will happen again in the next day or two - most often happens several times a week.

Robert

modified on Saturday, June 12, 2010 10:04 PM

R. Walker wrote:
OleLoadPicturePath(wpath, NULL, NULL, NULL, IID_IPicture,(LPVOID*)&pPic);

I guess the only things that can be bad here (unless OleLoad... itself is faulty but that's of course not likely) is either wpath or the parameter after it.

I checked the documentation[^] of OleLoadPicturePath. Now, i only scratched the surface of COM, so this might be completely valid, but the documentation doesn't menation that you may specify NULL for punkCaller.

I can't detect any problem with wpath.

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers don't kill programs, users kill programs <
> "It doesn't work, fix it" does not qualify as a bug report. <

Yes sounds reasonable. I did a Google search just now - there's not much by way of example code for OleLoadPicturePath(..) but what there is all uses NULL for the second parameter. I don't know enough about the Com interface to know how to use IUnknown instead - just copied this code from somewhere else. Usually I add a comment to the code to say where I got it from, but this is very old code, maybe it comes from before I did that.

Strange thing is, though, why didn't Purify trigger an access violation here for the apparently identical code in one of my other programs? That might be a line of investigation to find out more about what is happening.

Apparently identical code in another program which Purify let through without any errors at all:

WCHAR wpath[MAX_PATH];
MultiByteToWideChar(CP_ACP, 0, pszPath, -1, wpath, MAX_PATH);
IPicture* pPic=NULL;
CoInitialize(NULL);
OleLoadPicturePath(wpath, NULL, NULL, NULL, IID_IPicture,(LPVOID*)&pPic);
if(pPic)
 {
  HBITMAP hPic = NULL;
  pPic->get_Handle((UINT*)&hPic);
  hPicRet = (HBITMAP)CopyImage(hPic, IMAGE_BITMAP, 0, 0, LR_COPYRETURNORG|LR_CREATEDIBSECTION);
  pPic->Release();
 }
 CoUninitialize();

OH I SEE IT NOW

Difference is the

CoInitialize(NULL);
// ...
CoUninitialize();

Must be required. I now remember this triggering a bug in one of my other programs until I fixed it though I can't remember any other details.

I'll add it in and test it in Purify. Need to reboot to Vista to do that, middle of doing things will do that later on (Purify doesn't run in Windows 7).

All this happens before the dialog with the rich edit in question is even created however. I wonder if missing out a required CoInitialise during start up could somehow have a sporadic effect on the rich edit processing?

I've done a new build with this bug fix and with the richedit subclassing code removed completely (it is just a minor feature and will hardly be missed).

So that will eliminate those two possible issues and will see if the rich edit bug still happens.

Robert

You could try checking the return value of the OleLoadPicturePath call (it's HRESULT, is it not?), i think there is a common error code for the "you forgot to initialize COM" case, however, if you get the picture loaded correctly then maybe there is more to it than just that...i mean, if you simply miss the init call shouldn't the load fail completely? Anyways, check the return of the OleLoad... call, maybe it gives some more usefull information.
Another thing, since it is an Ole call, shoulsn't you be using OleInitialize and OleUninitialize instead of CoInitialize/CoUninitialize? I believe i read somewhere that CoInit isn't enough for some Ole things to work correctly, OleInit calls CoInit somewhere under the hood but it probably also performs some other things that are needed for Ole things to work correctly.

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers don't kill programs, users kill programs <
> "It doesn't work, fix it" does not qualify as a bug report. <

Thanks, just tried that, HRESULT always 0. Also picture loads successfully (except when running under Purify that is).

Ran it with Purify with CoInitialize, and also OleInitialize. Still got an unhandled exception in the same place, didn't fix it. Found out that the reason it doesn't happen under Purify with my other programs is because they try LoadImage first - when I adapted one of them to make sure it always uses OleLoadPicturePath then got an access violation again when running under Purify.

Did a google search and some code examples don't use anything, some use CoInitialize and a few use OleInitialize but seems to be rarer.

Anyway will just avoid this bit of code for now and see if the bug still occcurs.

With it skipped, the program was basically error free in Purify except for a memory related warning during WM_PASTE operations pasting text into the rich edit, can't remember what it was now though and forgot to write it down - anyway doesn't give a code location in evaluation version of Purify.

Maybe the three day trial of insure++ will give more information when I have time to give it a go.

Thanks, do say if you or anyone reading this has any other ideas and I'll continue to investigate and will be sure to post here if / when I fix it.

I'll do if i come up with anything usable, good luck.

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Computers don't kill programs, users kill programs <
> "It doesn't work, fix it" does not qualify as a bug report. <

Great, thanks!

Just a quick update.

It's not done it for a week now. Normally would have happened at least once by now - as there is no particular hurry to get this sorted out, I will leave it for another week to be sure.

That's with the subclassing disabled and the OleLoadPicturePath code also disabled. Next step will be to re-enable those two features one at a time and see which it is, which would take up to another fortnight for each one.

Not had time yet to set aside three days for a test drive of Insure++.

More later,

Robert

Thanks for the update, i'm still curious so if some new info turns up about the problem, please drop a few lines here. Smile | :)

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

Well after nearly three weeks glitch free with the new update, suddenly did it today.

So - not caused by the subclassing, or by the OleLoadPicturePath (or if either of those have anything to do with it, not the only thing that causes it).

So back to the idea of checking the code thoroughly with a memory overrun checker. Which I'll do when I have time.

Robert

Damn

, lurking errors are nasty...too bad you can't intentionally reproduce it...i have no idea what could help, if i think of something i will post it...

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

Hi All

Where i can found msppt8.h? or How can i make msppt8.h file?Please help me

Generate it from Powerpoint typelibrary.
Project->Add Class->MFC->MFC Class from Typelib. if from registry, select 'Microsoft Powerpoint Object Library' or if from file browse for powerpoint type library (msppt.olb) in directory where Ms Office is installed. Select whatever classes you need there.. give header file name.. go ahead..

ok i add

msppt.olb

then it's generate more than 100 class.So which class header file name i chane.As per Microsoft site say only one header file include

Msppt.h

.So can you give me tips to which file name change.
My requirement is open MS PowerPoint.
Please celebrator it.
Thanks in advance.

modified on Friday, June 11, 2010 6:10 AM

for older versions of visual studio, it generates all wrapper classes in to single header file say mspptX.h. But it doesn't mater. Only care to include the header files before using the wrapper classes declared in them. Still you can specify single header file name for all generated classses so that just need to include this single .h file.

ok when i add

MSPPT.olb in 2005 and 2008

then i am not getting.There is any more option.
Please help me

what you are not getting? Frown | :(

sorry it's mistake
i mean to say

msppt.h

if you have msppt.h.Please attached it.
Thanks in advance