|
You might find thunk structure for x64 on the source: "C:\Program Files\Microsoft Visual Studio ####\VC\atlmfc\include\atlstdthunk.h", but wont works well.
I had managed to build x64 binary using other CSubclassWnd.
|
|
|
|
|
This is some outstanding code I think, very very good idea.
Well Done.
Iain Fraser
sd
|
|
|
|
|
Hi,
I'm experiencing the following problem:
Everything works as long as I output to one window:
m_EditLogger.SetEditCtrl( m_Edit111.m_hWnd );
m_EditLogger.AddText( String );
As soon as I switch from one edit field to another by something like:
m_EditLogger.SetEditCtrl( m_Edit111.m_hWnd );
m_EditLogger.AddText( String );
m_EditLogger.SetEditCtrl( m_Edit222.m_hWnd );
m_EditLogger.AddText( String );
sometimes I get no output at all any more (Works for a while sometimes, but after a while no new output is displayed any more (or as said above, sometimes nothing at all displayed right from the beginning).
Any idea what the problem is?
Thank you very much.
|
|
|
|
|
Strange...
Did you try to explicitly unsubclass the edit control before subclassing the new one. e.g.
m_EditLogger.SetEditCtrl( m_Edit111.m_hWnd );
m_EditLogger.AddText( String );
m_EditLogger.SetEditCtrl( NULL );
m_EditLogger.SetEditCtrl( m_Edit222.m_hWnd );
m_EditLogger.AddText( String );
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
Yes, but no change.
Indeed, even your suggestion to unsubclass before directing to another output control itself has the same destructive effect as my second "SetEditCtrl" to a real second control.
In both cases there's no output at all.
And it's not a special problem in my source adaption:
You can easily see this in your own provided original sample source by just adding a second output control and directing any output to the first and then to the second control right one after the other.
BTW: Same problem no matter if using "cout" or "AddText".
So seems that the message handling gets disorganized if 2 -"SetEditCtrl" and " AddText"- to different controls are issued right one after the other, if the text update itself of the first control (paint message or something?) has not been carried out already and the handles get mixed up that way. (Are you using PostMessage instead of SendMessage somewhere?)
|
|
|
|
|
Is it possible to save the entire content of the edit control into some text file ?
|
|
|
|
|
Very good class for logging implementation using CEdit control.
Two comments for other users:
1. Don't forget the "using namespace std;" declaration on *.cpp files.
2. Don't forget the below declaration on your stdafx.h
// Include core STL header
#include <string>
#include <streambuf>
#include <iostream>
Thanks.
|
|
|
|
|
I'm trying to send the ouput of flex and bison to a window. This code uses the old ostreams (by including <iostream.h> instead of <iostream> , and you your code:
cout.rdbuf( &m_EditStrBuf );
wont work because rdbuf doesn't take any parameters in the old library.
Can you give me an idea of how to go about this when cout is defined as:
extern ostream_withassign _CRTIMP cout;
Thanks,
Sam
|
|
|
|
|
In the following code:
// Retrieve the text from our buffer
// We store it in a local variable to prevent long time locking
::EnterCriticalSection( &m_csLock );
wsText = m_wsStore; // Is this line thread-safed?
m_bMessagePending = false;
::LeaveCriticalSection( &m_csLock );
both wsText and m_wsStore maybe share the string buffer but increasing a reference count. if std::string isn't thread-safed, I think we really need a deeply copy on m_wsStore object.
|
|
|
|
|
yuancc@21cn.com wrote:
In the following code:
// Retrieve the text from our buffer
// We store it in a local variable to prevent long time locking
::EnterCriticalSection( &m_csLock );
wsText = m_wsStore; // Is this line thread-safed?
m_bMessagePending = false;
::LeaveCriticalSection( &m_csLock );
both wsText and m_wsStore maybe share the string buffer but increasing a reference count. if std::string isn't thread-safed, I think we really need a deeply copy on m_wsStore object.
Thats an interesting point!
Well, on the first sight I was thinking that you are absolutely right here. However, on the second sight, I am not so sure that it isn't threadsafe. As far as I understood, STL is thread-safe on the class level (different instances may be used by different threads) unless explicitly stated otherwise. And it should be not that difficult to implement this for std::basic_string. If the buffer is shared between string instances, it is shared only for reading and a copy on write is performed, before any one of the threads is performing a write operation. I have not the time to take a look in the actual implementation, however, if it is just clever enough to decrement the reference count after performing the copy, it should be threadsafe in any case, because it could never happen that a shared buffer is written to.
Have fun!
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
who can understand vc's stl code written by P.J. Plauger ?
But I think in this implement, the reference count isn't protected by mutex as I can't find any related code.
Actually, the thread problem won't happen when another thread is appending a new string to m_csStore while the main UI thread is updating the edit box using wsText, becuase the m_csStroe find its ref count is 1 and then it should alloc a new buffer.
But the problem will happen, when wsText's destructor is calling, the ref count is decrementing from 1 to 0, but at same time, maybe the shared m_csStore is decrementing the ref count too. if no mutex protected, the ref count maybe less than 0 which is a potential problem.
the destructor of std::string in vc's stl is like this without thread protection but it should be a atomic operation in a multiple thread environment.
if( refcount == 0)
free(m_buffer);
else //maybe another thread is also decrementing the refcount and now it is 0 now.
else refcount--;
|
|
|
|
|
If text is added to the dialog when the bottom line is not in view, there is a significant flicker. MSDev's output windows don't do this. Anybody got hints?
|
|
|
|
|
I wish I knew the answer to this, I've been searching for months.
My best guess is to determine the rect you are updating when text is appended and only invalidate that.
|
|
|
|
|
I think you can toy arround with the On-erase-background message (excuse me for not remembering exact name).
You can stop the flicker by returning false. But that is not the answer since it will not erase previous.
But you might try duplicating text output there. You can also employ double buffering by declaring a MemDC (CreateCompatibleDC) and selecting a hbitmap (CreateCompatibleBitmap). Doing this allows you to do your slow GDI TextOut or DrawText function to faster MemDC memory. Then BitBlt the results to the control dc.
Hope this helps
RJ
|
|
|
|
|
Hi,
The answer is simple. MSDev's output windows are not implemented with the edit commun control. They developped their own custom logging control that do not redraw itself if the bottom line is not visible. You can see it by youself by using Spy++ and look with which Window classes VC++ is made of. You will not see "edit"!
The solution to obtain the same effect is not trivial. You have to write your own control that does the same. I am working on such a control. Stay tuned....
Olivier Langlois
http://www.olivierlanglois.net
|
|
|
|
|
This is an excellent class!
I was wondering if it is possible to redirect printf and wprintf, and anything that writes to stdout and stderr too? Any ideas (other than trapping WriteFile)?
|
|
|
|
|
Thanks for your feedback
omasoud wrote:
I was wondering if it is possible to redirect printf and wprintf, and anything that writes to stdout and stderr too? Any ideas (other than trapping WriteFile)?
I was also thinking about it. In principle it should be possible to redirect a CRT FILE* to whatever you want, but I had given up to detect how it exactly works in the sources. Its completly undocumented.
Another idea (instead of catching WriteFile) might be to create an anonymous pipe and set it as osfilehandle for stdout / stderr (using the _open_osfhandle() CRT function and SetStdHandle() Win32 API function). However, you would also need to use an additional thread that waits for input on the pipe and then sends it to the EditLog. A clear benefit of this would be that any output that is going to stdout (even if a DLL is usig WriteFile( GetStdHandle( STDOUT_HANDLE) ) would go to the edit control. STDOUT and STDERR would also be automatically passed to child processes.
The most simple solution I use all the time is to define a small printf-like custom function in my stdafx.h which redirects the output to the editlog. Then I #undef printf and re- #define it to my custom function. Of course this does not work with externally compiled code.
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
http://dslweb.nwnexus.com/~ast/dload/guicon.htm
I've tried the code in the above link and it does work in redirecting stdout and stderr (even cin, cout, cerr work). Not sure how to use it with your class though.
The only documentation from microsoft about this that I found is in the following link:
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q105/3/05.asp&NoWebContent=1
|
|
|
|
|
omasoud wrote:
http://dslweb.nwnexus.com/~ast/dload/guicon.htm
I've tried the code in the above link and it does work in redirecting stdout and stderr (even cin, cout, cerr work). Not sure how to use it with your class though.
Well, this code actually does only part of it. It shows how to attach an Win32 file HANDLE (in this case a console handle) to CRT output (stdout, stderr, cout, cerr) at runtime.
The other things to do are:
- create an anonymous pipe with CreatePipe and use its write end HANDLE (and not a console handle) as STDOUT and STDERR as shown in the example code you found.
- create a worker thread that reads from the pipe's read end HANDLE and dumps the output to the CEditLog.
Because CEditLog has been designed to be thread-safe, this all should not be too difficult. You just have to take care (a bit) about when creating the thread, CEditLog and how to shut all of them down in a correct and graceful order.
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
First thanks for the great class! I have used it and it works great
What I wan't to do is add coloring capability to it, that dpending on the text I can change its color.
Any pointers, suggestions as I think that would be a goot addition
Thanks again
|
|
|
|
|
annum wrote:
What I wan't to do is add coloring capability to it, that dpending on the text I can change its color.
This should be possible by building CEditLog around a RichEdit control instead of an ordinary edit control. (As a side effect this would also remove the 64kb limit on Win9x - however, I never really cared about this )
Since RichEdit understoods most (all) of the messages of an edit control, the task should not be that difficult. The point that let me intentionally avoid RichEdit in the days I wrote this code, was the versioning chaos around it (it seemed to depend on Windows /IE / common-control and whatever versions...).
Have fun!
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
When I tried to link up CEditLog to a RichEditCtrl. It crashed after a few seconds of scrolling. The callstack was pretty messed up, but I think it had to do with a windows message proc.
-p
|
|
|
|
|
Hi,
I was wondering if anyone has tried to use CEditLog on an Cedit control in a FormView ... I just set everything up and the program runs... no compile errors... the program does not crash... BUT when I send text to the CEditLog nothing happens???
Anyone have any idea what I am doing wrong, or why CEditLog would not work on a Cedit control in Formview?
Thanks for your help.
Abstract3
|
|
|
|
|
I have to admit that I never used a CFormView, but I just do not believe that it would not work. An edit control is an edit control is an edit control!
I would recommend to use Spy++ and check if and which messages are sent to the edit control. If no WM_USER messages arrive, it seems to be not connected to the CEditLog. Also some breakpoints in the CEditLog code might help to figure this out.
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
Im having the same problem using CRichEditCtrl.
The problem seems to be with the values returned from GetScrollInfo.
Im working on a fix now.
|
|
|
|