|
Loading happens asynchronously. You need to ensure that the load has finished (the load of about:blank and the load of your stream) before triggering another load. Going from memory here... but until about:blank has finished loading, GetHtmlDocument() isn't going to succeed... so at present, your routine is relying on about:config loading fast enough to allow the rest of the code to work. Which is possible and likely (but not guaranteed). Of course, the second time around, the browser will be busy loading your custom stream (which you don't seem to be releasing anywhere... bad), so it's probably not gonna finish loading about:blank until a while after your attempt to direct it to a memory stream has finished.
Realistically, you want this to happen via callbacks. Trigger the load via about:blank, then wait for the NavigateComplete2 or DocumentComplete event, then direct the browser to your stream. And, once that load is complete, free up the memory.
---- ...the wind blows over it and it is gone, and its place remembers it no more...
|
|
|
|
|
Yes you have absolutely right.
I changed a little the critical part of the code with the following using the NavigateComplete2 and about:blank as you recommended.
Now its working. I dont know if its a better solution from the old one, but it works.
IDispatch * pDisp = GetHtmlDocument();<br />
if (!pDisp)<br />
return;<br />
<br />
IHTMLDocument2* pDoc;<br />
if (SUCCEEDED(pDisp->QueryInterface( IID_IHTMLDocument2, (void**)&pDoc )))<br />
{<br />
CComBSTR bstrURL;<br />
CComVariant varDummy;<br />
pDoc->open(bstrURL, varDummy, varDummy, varDummy, NULL);<br />
<br />
SAFEARRAY *pSA;<br />
SAFEARRAYBOUND saBound = {1, 0};<br />
pSA = SafeArrayCreate(VT_VARIANT, 1, &saBound);<br />
<br />
VARIANT *pVar;<br />
CComBSTR bstrHTML = source;
<br />
varDummy = bstrHTML;
<br />
SafeArrayAccessData(pSA, (void**)&pVar);
pVar[0] = varDummy;
SafeArrayUnaccessData(pSA);
<br />
pDoc->write(pSA);
pDoc->close();
<br />
SafeArrayDestroy(pSA);
pDoc->Release();
<br />
}
sdancer75
|
|
|
|
|
For some magic reason I need to have /Od /Ob1 (disable optimizations, only __inline function expansion) in my release build. Don't worry about why I need to do this, I really need to do it.
Is there a way to add some magic #if in my code that will cause a compilation error if these specific compiler options are not in place?
I need this in order to prevent some dutiful developer from changing these settings 1-2 years from now and breaking the code. Unfortunately I cannot add comments in the project settings dialog (it's not the first time I needed to do so).
Thanks in advance!
Dimitris Staikos
|
|
|
|
|
I don't have a solution, but I sure do admire the problem. 
Guess you're stuck with documenting the code – and explaining why it is so imperative not to enable optimizations.
Florin Crişan
|
|
|
|
|
Hello everyone,
For the SysAllocString API, I am wondering,
1. any special benefits if we use SysAllocString compared with using a simple wide character string, like L"Hello"?
2. If we use SysAllocString to allocate constant string, then does SysAllocString allocate the constant string on heap, stack or on the constant string pool?
thanks in advance,
George
|
|
|
|
|
Don't take this as gospel unless someone at Microsoft confirms it but SysAllocString is potentially faster than using a simple wide character string becuase it uses some kind of reserved string memory. Could be part of non-paged pool or another special memory area. Someone may be able to point you at MS documentation as to how this works but I have never seen any.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
So you never use Matthew? What do you use instead?
regards,
George
|
|
|
|
|
Yes I use BSTRs (known as bee stings because they can be painful ) every day, generally on WinCE though where the memory model is a bit different. They are indeed allocated by the COM runtime and almost certainly in some sort of 'global' memory belonging to the COM runtime itself. Check out CoTaskMemAlloc, I suspect that's what's being used under SysAllocString. Can't prove it though.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
I am interested to learn what do you mean *memory belonging to the COM runtime itself*? For example, in the following scenario, an EXE will utilize an in-process server COM DLL.
1. The EXE will load the in-process server COM DLL into its process space;
2. When we use SysAllocString to allocate memory for strings in the in-process server COM DLL, the memory will brlongs to the EXE heap space? or the *memory belonging to the COM runtime itself*? What is COM runtime? A separate process or some other DLLs loaded by the EXE which utilizes the in-process server COM DLL?
regards,
George
|
|
|
|
|
The COM runtime is a bunch of DLLs e.g. oleaut32.dll which implement COM itself. These get loaded into your EXE process but they contain code capable of crossing process boundaries and the Kernel/User mode boundary so it is theoretically possible for COM runtime data to exist across processes( The Running Object List is a mysterious beast of this kind). BSTRs are certainly allocated per-process and have to be auto-marshalled to transfer them but because of the peculiar nature of the COM allocator it may or may not be using the processes normal heap. If it is then it isn't using it through the normal (slow) heap manager. I don't know whether COM simply uses it's own manager on a preallocated chunk of the default heap, uses a second help, or uses Kernel memory outside the process but assigned to it. It is capable of all 3 but only MS would know for sure where BSTRs really live and why they turn out slightly faster than ordinary strings.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
Why do you think BSTR is faster than ordinary strings? Do you have any performance data?
regards,
George
|
|
|
|
|
I don't have any data but the excolleague of mine who wrote the high performance String classes for my company did do a lot of testing and he reckoned BSTRs were faster in real usage than the alternatives. I suspect this is to do with their use of the COM memory allocator.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I don't know if you have noticed[^] but SysAllocString is part of the COM library (you need to link to oleaut32.lib if you use it).
The returned type is a BSTR – a string type used by COM – rather than a WCHAR *. The differences are:
- BSTRs are allocated using the COM allocator, so they can passed to another process (and deallocated by another process). This is why you should use SysFreeString rather than delete or free.
- BSTRs have a length prefix (besides having null terminator).
The length is kept (as a UINT) in the memory location just before the first character.
The BSTR type is actually defined as a WCHAR *, pointing to the first character (just like a regular LPWSTR), so you can use BSTRs wherever you can use LPWSTRs. Just remember that you should use SysFreeString to deallocate it.
So, a regular string looks in memory like this:
S o m e [space] t e x t [null]
53 00 6f 00 6d 00 65 00 20 00 74 00 65 00 78 00 74 00 00
whereas a BSTR looks like this
string length S o m e [space] t e x t [null]
09 00 00 00 53 00 6f 00 6d 00 65 00 20 00 74 00 65 00 78 00 74 00 00
Hope this clears things up a little bit.
See also this page[^].
Florin Crişan
|
|
|
|
|
Cool Florin!
I have a further question, you mentioned below,
Florin Crisan wrote: so they can passed to another process (and deallocated by another process).
I do not quite understand what do you mean passing to another process? In my limited knowledge, I only developed in-process server COM (.DLL) before and I have never met with situation that I need to pass something to another process (in-process server COM DLL will be loaded by another process).
It is appreciated if you could provide more information about what do you mean passing the BSTR value to another process.
have a good weekend,
George
|
|
|
|
|
I'll reply to that...
If you used an out of process COM (either just in an exe, or on another machine), windows does the heavy lifting of transferring the parameters to your COM interface functions for you.
BSTR is a) Easy for it to marshall (moving about) and (b) is the string type originally used by VB, so your COM object can be used by VB programs, VBScript, etc. Lots more than clean nice pure C++ programs.
Iain.
|
|
|
|
|
Thanks Iain,
As you mentioned marshall, it is one of the things I want to learn in the past, but missed some good tutorials. I have C++ native unmanaged COM (in-process server) development experience, could you recommend some learning materials about marshall please?
regards,
George
|
|
|
|
|
Sorry, I've just been picking this stuff up as I go.
I would recommend Michael Dunn's series on shell extensions for a good (free) start.
Iain.
|
|
|
|
|
Hi Iain,
What do you mean *Michael Dunn's series on shell extensions*? Could you provide an URL please?
regards,
George
|
|
|
|
|
Try using the author search - they'll be pretty obvious!
Iain.
|
|
|
|
|
SysAllocString() creates a BSTR (BASIC STRing), which is the primary means for passing strings between COM objects. Memory for the string is managed by COM. Depending upon the usage, you may need to call SysFreeString() to release the memory allocated to the string when you're finished with it.
If you are using COM, then you will probably need to use BSTR's.
There is no performance or other advantage to using them otherwise. If you just need simple wide character strings, use wchar_t strings.
Software Zen: delete this;
|
|
|
|
|
Thanks Gary,
I have also done some self-study, here in MSDN
http://msdn2.microsoft.com/en-us/library/ms221069.aspx
It is mentioned,
BSTRs are allocated using COM memory allocation functions. This allows them
to be returned from methods without concern for memory allocation.
I do not quite understand what does it mean? No need to take care of memory
allocation? We still need to call SysFreeString manually.
regards,
George
|
|
|
|
|
Hello,
Can we use DoModal like this:
<br />
CMyAlert *alert = new CMYAlert;<br />
alert->Create(CMYAlert::IDD,this);<br />
<br />
<br />
if (alert->DoModal()==IDOK)<br />
{<br />
message("IDOK is clicked")<br />
}<br />
I want to know when IDOK is clicked On CMyAlert,
Is there another way to know it?
thanks
|
|
|
|
|
Gofur Halmurat wrote: I want to know when IDOK is clicked On CMyAlert,
The CMyAlert dialog will have to notify the parent window that the OK button was clicked. either by passing a pointer to the parent to the dialog? or from the dialog, send a private message to the parent window saying the OK was clicked.
What is your intention ?
Do you want to have the dialog dismissed when the user clicks on Ok ?
|
|
|
|
|
Hello,
My parent window has a button, if i click the button the CMyAlert appears, and there is a button on CMyAlert, when i click the button on CMyAlert, Some changes will have to be done on parent window. How can i implement this?
either by passing a pointer to the parent to the dialog? or from the dialog, send a private message to the parent window saying the OK was clicked.
How can i implement this option? can u show me with examples?
thanks
|
|
|
|
|
are you wanting a modeless dialog by any chances ?
if not, then why don't you do the job when the modal dialog is closed ?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
