Born and live in England. Travelled to Scotland, Wales, N Ireland, France, Belgium, Netherlands, Germany, Spain, Malta, Gran Canaria, USA (Florida and Washington DC), Canada. The furthest I've been was when I went to a clients office - don't know where they were, but none of them seemed to be on this planet :eek:

And when a programmer replies, they'll put together the construction as described, and hand it over to him. When he complains it doesn't work, programmer will say it was made to the spec! When asked if he knew it didn't work, programmer will say that testing is someone else's responsibility! :D:D

This comes down to the order in which the operands are evaluated. Your first line expands to 815 - 0 - 1 + 2 + 4 + 1 i.e. 814 + 2 + 4 + 1 = 821 Do #define HVD_HEADER_SIZE (1 + 2 + 4 + 1) to get the results you are expecting!

I am trying to get RTF text into an MS Word document, using automation. I have a method which works fine, whereby I write the rtf to the file, then call the Range object's InsertFile() method. However, this is a little slow, to say the least. Any ideas on how I could transfer my text quicker? Thanks in advance!

When you use AppWizard to create your application, you could try setting the view base class to CFormView (on the last but one page of the wizard IIRC). This allows you to define your view using a dialog template. If you have a CView derived view, then you'll have to create them dynamically.

Use the functions FindFirstFile(), FindNextFile(), and FindClose(). You'll need to recurse through and directories you come across though.

Well I'm nice and calm now, so it helped me ;) If you're less calm, then have a rant about people having a rant and you too could feel better :D Until of course someone has a rant about people having a rant about people having a rant....... :)

I was trying to prove to myself that I can do more than one thing at once. Better to have tried and failed than to have not tried at all :)

I didn't know about the option, so thanks for that! I've calmed down a little now - thinking weekend thoughts helped :)

Aaaargh. :mad: I was in the midst of typing in a new article into the article submission wizard, when a colleague sent me an email containing a hyperlink. So I clicked on it. Biiiiiiigggggg mistake. Outlook very kindly opened the aforementioned link in the instance of IE that contained the editor, nuking the product of my creative juices. So I'm cross now :(

I'm confused. Delving into the CMemFile code, it looks like the internal CMemFile buffer is NULL, which means that (memory shortage problems aside) the rich edit control has never called the callback to write to the file. It might be worth putting a breakpoint before the offending line and taking a look at the memFile member variables to see if there is indeed a valid looking buffer in there! If there is no buffer, it could be down to where you are calling the function from - could it be at a point where the rich edit control might have already cleared down the content and started destroying itself? Just out of interest, what did you set GETCONTENT_BUFFER to? I set it to 4096. Sorry I can't be any more help!

Here's the methods that I use, which happily work for thousands of characters!CString CRichEditViewEx::GetContent() { CString strContent = ""; EDITSTREAM es; CMemFile memFile; es.dwCookie = (DWORD) &memFile; es.pfnCallback = StreamOutCallback; GetRichEditCtrl().StreamOut(SF_RTF, es); memFile.SeekToBegin(); char szBuff[GETCONTENT_BUFFER + 1]; memset(szBuff, 0, GETCONTENT_BUFFER + 1); while(memFile.Read(szBuff, GETCONTENT_BUFFER) > 0) { strContent += CString(szBuff); memset(szBuff, 0, GETCONTENT_BUFFER + 1); } return strContent; } DWORD CRichEditViewEx::StreamOutCallback(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb) { CMemFile *memFile=(CMemFile *)dwCookie; memFile->WriteHuge(pbBuff,cb); *pcb = cb; return 0; }
Note that here I am getting the RTF - to just get the text, you need to change the flag SF_RTF to SF_TEXT, like you have in your code - and of course add SF_UNICODE if required. If you want to get just the selected text, which is what the line strOut=strOut.Mid(....) seems to imply, then instead of doing CString::Mid(), you can use the flag SFF_SELECTION along with SF_TEXT et al.

Think yourself lucky - here in the UK we don't get a day off to celebrate the Queen's birthday. :(

Check out WM_GETMINMAXINFO - handling this message lets you set the minimum and maximum sizes of the dialog. Note that to get the message to appear in ClassWizard, you need to go to the Class Info tab, and set the Message Filter to "Window"

Have you initialised and set Playing correctly? If it isn't set to FALSE, then the for loop will never break.

The MFC CString will accommodate strings far longer than 256 characters. It is more likely that there is something wrong with the code that is populating the CString. Post the code if you still have problems! :)

The easiest way is to precede the class in the file with an enumerator that indicates what sort of object follows.

The sorting that is being performed is a string sort - i.e. they are in alphanumeric order. What you need to do in the sorting function is convert the textual representation of the date to say, a CTime, then determine the order from that. The other option is to display the date in the format YYYY/MM/DD; when you do this the string sort operation correctly sorts the dates!

Given that you are using an Access database, you could use CDaoWorkspace::CompactDatabase().

Seems to have stopped now. Maybe the monitor telepathically knew it was going to get hit if it didn't stop :) Hope it doesn't catch fire. Don't want to interrupt my surfing working :D