Two people have correctly told you how to get a char *, although neither told you that you need to call ReleaseBuffer() on the string when you're done with it. But if you want to access a single char from the string, you can use index notation to access one character at a time.
char u = s;
This is assuming a non Unicode build, of course.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Well just for curiosity sake, I guess one needs to call ReleaseBuffer() only if the buffer supplied is manipulated with, like data is altered.
Does one have to always call ReleaseBuffer(), i mean if he is just calling GetBuffer() just to convert it to form easy for display or copy etc??
Every call to GetBuffer should have a matching call to ReleaseBuffer. GetBuffer and ReleaseBuffer should only be used on code which alters the string. If you just want to inspect use operator LPCTSTR. Using this operator is automatic, ie:
constchar *pData = MyCString;
As Christian suggested however, both of these methods should only be use when using a CString with code that knows nothing about CStrings - In general use CString's member functions to manipulate it's contents.
We create a dialog box from a Document View Application, it's fairly easy. But it should also be possible to do 'invert' this operation, i.e., using dialog based application as 'main window', a doc view program must start, for example, on clicking a button on the dialog box. I tried to make it using two three ways but I was only partly successful.
Suppose you have created a new dialog based MFC application. Add a button, call it 'Start Doc View'. On clicking this button, a Doc View application should pop up. I implemented something like this:
void C...Dlg::OnDocView( ) // click event for the button
ShellExecute(...); // Supply the name of Doc View EXE and path...
But this has a disadvantage that, if the dialog application is closed, the Doc View still remains on the screen. I don't want this disadvantage. What is desired is, if the dialog based app closes, the Doc View should also 'die'.
I tried to use Doc View as DLL (I saw one or two articles at CodeGuru). Built and copied the DLL (also .h and .lib files of Doc View) into the dialog-based project, but could not make much headway. Could also be my mistake.
I am also thinking of initiating a user interface thread (when the start Doc View button is clicked) and that thread, instead of showing its own window, calls ShellExecute(...) or calls the DLL for Doc View. Would it be correct?
Can you kindly provide a solution. Also, (if possible), a line by e-mail (firstname.lastname@example.org) about your posting of article and/or your views would be my fortune.
I have the storage opened in my appln using StgOpenStorage using the flags STGM_READWRITE|STGM_TRANSACTED|STGM_SHARE_DENY_WRITE. Now is it possible to thread the writing activity to various streams in the same appln using the same handle?
I wud say this shud b possible considering file s/m within document, but since the root storage is opened with flags mentioned it may not be possible? pls advise.
As ususal with COM, if you attempt this you'll have to marshal the interface pointers to the worker threads. Whether this will work as expected depends on the threading model of the storage object (which I'm not sure of).
sorry im not sure if i have got what you have explained. i have a thread wrapper class through which I intend to pass the necessary info to the thread, am i close to ur lookout?
could you provide me a small code sample to elaborate?
In general, it is illegal to pass COM interface pointers from one thread to another directly; they must be marshaled to the other thread. This is not a limitation but a feature however. For example say you have a COM object that is not thread safe and can only safely be called from one thread. In this case passing one of its interface pointers directly to another thread would be disastrous. If you marshal the interface pointer to the other thread COM sets up a proxy in the other thread and a stub in the object’s thread and things will seem to just work. In reality the calls to proxy send information to the stub which calls the real object so all calls to the object still come from it’s own thread and all the details of the inter-thread communication are hidden. The situation if the same inter-process. In short I think you need to look up marshaling.