 |
|
 |
Hi,
I have a CSynsocket class in a CWinThread Class in my ::initinstance I call CAsynsocket::connect and
get WSAEWOULDBLOCK return code after which my code returns to the process the main CWinapp thread
by the time I get the CASynsocket::onconnect notification the nErrorCode notification is WSAETIMEDOUT the connection timed out
I there anyway to ensure that when the socket connection is ready that ::onconnect notification gets processed ?? Immediately
Thanks
|
|
|
|
 |
|
 |
Hi,
I know in releation to DuplicateHandle
the mutex,events other kernel objects are releative to the Particular Process... my question
is once I get a process handle either as PROCESS_INFORMATION.hProcess param from CreateProcess API
or via OpenProcess
can use that in any process to copy the kernel object from one process table to another
|
|
|
|
 |
|
 |
you should use WideCharToMultiByte first. I already tested
|
|
|
|
 |
|
 |
First of all, great code. It really makes understanding this control much easier to deal with. But when I played around with it, I had a run time error in the stream in callback routine. Specifically at this line:
if (cb < psBuffer->GetLength()) cb = psBuffer->GetLength();
I had to change this line because it turned out that cb was in fact greater than the length of psBuffer. This would throw off the for loop below it, since the length of the buffer was smaller than cb. But then again, I'm only streaming in strings that are really small--not 30kb and over.
New code:
if (cb > psBuffer->GetLength()) cb = psBuffer->GetLength();
So is it just me? Or did I find a "feature" for streaming relatively smaller strings into the control?
|
|
|
|
 |
|
 |
"cb" is count of bytes we can write to RichEdit's buffer, i.e. it is buffer length. We must not transfer more than cb bytes to avoid buffer owerflow. So if cb is less than length of our string, we transfer first cb characters and then remove them from the string: for (int i=0;i<cb;i++) { *(pbBuff+i) = psBuffer->GetAt(i); } *psBuffer = psBuffer->Mid(cb); And if cb is greater than length of the string, we just don't use rest of the buffer: if (cb > psBuffer->GetLength()) cb = psBuffer->GetLength().
|
|
|
|
 |
|
 |
I know this is a 9 month old post I am replying to but I believe Zinkyu's fix is correct.
Thanks for the original code and the fix.
|
|
|
|
 |
|
 |
In the function OnReadin() I would like the RTF equivelant of an HICON object. Can anyone help me out here?
|
|
|
|
 |
|
 |
If somebody looks for a simple way to some string into a richeditctrl, I would like to show you the easiest way.
I think belows are the one of them.
void Set(LPCTSTR tcsBuff)
{
GetRichEditCtrl()->SetSel(0, -1);
GetRichEditCtrl()->ReplaceSel(tcsBuff);
}
void Append(LPCTSTR tcsBuff)
{
GetRichEditCtrl()->SetSel(GetRichEditCtrl()->GetWindowTextLength(), -1);
GetRichEditCtrl()->ReplaceSel(tcsBuff);
}
This is the most painless way I've known.
-taekwonv-
|
|
|
|
 |
|
 |
Have you tested this with big strings? I think you will find that upto about 30k everything will be fine but over that, the text will be cropped. Also there is no need to select the text and replace it in your Set function, SetWindowText will do it in one go, but again, limited to strings <30k (approx).
-- modified at 2:46 Saturday 17th March, 2007
I program for fun.
|
|
|
|
 |
|
 |
When you copy the contents of the string to the buffer you are not checking the length of the string. Here is a similar implementation using a basic_string for us non-MFC users:
DWORD CALLBACK RTFLoadStreamCallback( DWORD dwCookie, LPBYTE lpBuffer,
LONG lSize, LONG *plRead )
{
if( ! lSize ) return( 1 );
string *txt = (string *)dwCookie;
for (int i=0;i<lSize,i<txt->size();i++) {
*(lpBuffer+i) = txt->at(i);
}
*plRead = i;
txt->erase(0,i);
return( 0 );
}
|
|
|
|
 |
|
 |
The CString::GetBufferSetLength(int nNewLength) call made me wonder why only half of this call's features were being used and how the CString::SetAt() was working before the buffer was released. Also the CString::Mid(0) function was returning a copy of itself when CString::Delete works on itself, so I re-coded the functions this way:
DWORD __stdcall MEditStreamInCallback(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
CString * psBuffer = (CString *)dwCookie;
if (cb > psBuffer->GetLength()) cb = psBuffer->GetLength();
memcpy(pbBuff,*psBuffer,cb); *pcb = cb;
psBuffer->Delete(0,cb); return 0;
}
DWORD __stdcall MEditStreamOutCallback(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
if(cb < 1)
return 0;
CString sThisWrite;
CString * psBuffer = (CString *) dwCookie;
memcpy(sThisWrite.GetBuffer(cb),pbBuff,cb); sThisWrite.ReleaseBuffer(); *psBuffer += sThisWrite;
return 0;
}
It works for me. YYMV.
--
Jacob
|
|
|
|
 |
|
 |
PS. This code is not UNICODE safe. Use * sizeof(TCHAR) where appropriate.
|
|
|
|
 |
|
 |
Your Streamout doesnt work because *pcb isn't being set before returning.
Here's the streamin & streamout routines I use based on CStrings:
DWORD __stdcall StreamInCallback(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
if(cb > (((CString*)dwCookie)->GetLength())) cb = ((CString*)dwCookie)->GetLength();
memcpy(pbBuff,*(CString*)dwCookie,cb); // can't think of a better way.
*pcb = cb;
((CString*)dwCookie)->Delete(0,cb); // remove the text we just copied from the source (pointed to by dwCookie)
return 0;
}
DWORD __stdcall StreamOutCallback(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
*(CString*)dwCookie += CString((LPCTSTR)pbBuff,cb);
*pcb = cb; //returns the number of chars just transfered IMPORTANT!!!!
return 0;
}
I program for fun.
-- modified at 4:15 Saturday 17th June, 2006
|
|
|
|
 |
|
 |
Improved
DWORD __stdcall CBStreamOut(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
CString *pString = (CString*)dwCookie;
pString->Append((LPCTSTR)pbBuff, cb);
*pcb = cb;
return 0;
}
That way you don't have to create a temporary CString-object.
|
|
|
|
 |
|
 |
In VC6, Append isn't a member of CString, it's a member of CStringArray so this code doesn't compile.
The reason I posted a CString version of CBStreamOut and CBStreamIn is I thought that there would be quite a few people out there who had used the CString class in their programs then come across the 30k text limit problem. I thought that leaving all the casting in CBStreamOut & In would help people keep their code clean and provide a plug-in-and-go answer to the 30k limit problem.
I program for fun.
|
|
|
|
 |
|
 |
Nice article...
thanks
Kalai Kandasamy
Son, when you participate in sporting events, it's not whether you win or lose: it's how drunk you get!
-- Homer J Simpson
|
|
|
|
 |
|
 |
Hi -
Should this code work if you're streaming in a large rich text block that had a picture in it? or would any char(0) data in the picture mess up the stream?
Thanks
|
|
|
|
 |
|
 |
Hi Eric,
Pictures and other embedded OLE objects will work fine.
To my knowledge, RTF doesn't contain char(0) in the stream. I've tried it with a large number of embedded objects with no problems at all.
The thing with embedded pics is the RTF data tends to get quite large. You can find a somewhat harder-core very fast streamer here:
http://www.calcaria.net/html/rtf_stream_2.html
(Essentially a second version of the code here.)
|
|
|
|
 |
|
 |
Paul's code works great, but my objects (a bitmap in this case) are not coming through. Weird -- I can see them in the CString that gets streamed into the CRichEditCtrl (it comes from a 2nd CRichEditCtrl), but then they don't appear on the screen. Formatted text, both before and after the bitmap, comes through fine.
Do I need to play with IRichEditOle here?
thanks,
chris
|
|
|
|
 |
|
 |
Out of the box CRichEditCtrl on its own does not support OLE objects, which is why they're not appearing.
I've only used CRichEditCtrl and OLE objects within the Doc/View framework. This is because it ties in the OLE stuff with CRichEditView/CRichEditDoc. I have seen (I think either here or on CodeGuru) a project that performs some simple OLE insertion into a pure CRichEditCtrl, but that may not be equiped to deal with full OLE embedding.
|
|
|
|
 |
|
 |
Sorry for the very delayed response, but if you want embedded objects (like .bmp's but not limited to them) to appear, then indeed you must play with OLE. Specifically, you must supply an IRichEditOleCallback interface and then implement the GetNewStorage method.
The best "article" that I've seen on this is actually a comment to a CodeGuru article. The comment can be found at http://www.codeguru.com/Cpp/controls/richedit/comments.php/c5383/?thread=58860[^], entitled "Getting Images with a StreamIn/ClipBoard/Drag'n'Drop operation"
-Mike
|
|
|
|
 |
|
 |
I'm reading into a buffer data from a serial line and displaying in a rich edit control. I read the data into a buffer and I want to write that information to a file. My problem is how I get my information from my buffer to the call back function buffer(pbBuff) before doing a file write. Thanks in advance if you can help
TAW
|
|
|
|
 |
|
 |
I wrote a program, loading a text into RichEditCtrl and parse the content for special characters' positions.
My program works well until I change to RichEdit 3.0 to load Unicode content
The new RichEditCtrl can load Unicode well, but all the CR-LF were changed to CR in the control. When I do StreamOut it using SF_UNICODE format, it converts all CR to CR-LF, making my position calculation upon the original character position (while it is still in the RichEditCtrl) incorrect.
How can I prevent this to happen ?
Thank you in advance for your help
|
|
|
|
 |
|
 |
For some reasons, this function streamout is very important and interesting to me!
However, I need to get the pure string without those formats.
(Although I know there are other methods like GetWindowText, etc., but I need to use just this Streamout!)
For example, from this sRTF value of
{"{\rtf1\fbidis\ansi\ansicpg1252\deff0\deflang1035{\fonttbl{\f0\fnil\fcharset0 Microsoft Sans Serif;}}
\viewkind4\uc1\pard\rtlpar\qr\f0\fs17 America
\par }
"}
I just need "America".
or if sRTF is
{"{\rtf1\fbidis\ansi\ansicpg1252\deff0\deflang1035{\fonttbl{\f0\fnil\fcharset178 Microsoft Sans Serif;}}
\viewkind4\uc1\pard\rtlpar\qr\lang1065\f0\rtlch\fs17\'c2\'e3\'d1\'ed\'df\'c7\lang1035
\par }
"}
I just need exactly this: "'c2\'e3\'d1\'ed\'df\'c7"
How can I do that? Is there any function which can trim away those extra format parts?
Please.... someone advise.
|
|
|
|
 |
|
 |
Hello,
If you want to get pure string (without any RTF tags), please use SF_TEXT flag instead of using SF_RTF.
Hope this help.
|
|
|
|
 |