|
Thanks Rajkumar,
I think what you posted above is the CoCreateInstance implementation of smart pointer class, not the global implementation, right?
regards,
George
|
|
|
|
|
|
Thanks Rajkumar,
Could you give your definition or preferred definition of what is type safe please? 
regards,
George
|
|
|
|
|
This wrapper does not improve type safety at all. Let us say that p is declared as IMySpecialInterface*. How exactly is the external runtime that overwrites the value of p supposed to know whether it is 'allowed' to put a ISomePublicObject* in there or not. It cannot know, it does not check and all this is done at runtime anyway so there is no way to type constrain an addrees that is overwritten by an external process at runtime, during compilation.
Declaring p as a different type will not change the type that is pointed to after the call, ever, it simply disguises the fact that you cannot know what p is pointing to after the call except for the gaurentees that COM gives you.
When using the COM runtime you have the type safety gaurentess that the COM runtime gives you or you have none, you cannot fix this with C++ mechanics.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
hi mathew, think in other way, from client point of view, compiler type safety has nothing to do with Runtime it is upto the compilation time, it only gives hint to the programmer to avoid mistakes in the coding, obviously server will overwrite what ever pointer given to it.
I just suggest this, i am clear about it. I am not saying ur COM concept is wrong.
|
|
|
|
|
Rajkumar R wrote: it only gives hint to the programmer to avoid mistakes in the coding
Exactly, which is why in this case void** is the best reminder to the programmer that they should not trust the returned value to be the type they expect because whatever type of pointer they pass in they cannot gaurentee it. They should check with QueryInterface. IUnknown** would be just as good given that COM ensure this much witha validly written server but then the client programmer might forget to check for NULL. 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Hi Matthew,
I have read all of your replies. I am interested in,
what do you mean exactly runtime type safe (not limited in the scope of COM)? Could you give a definition please?
regards,
George
|
|
|
|
|
I didn't use the term 'runtime type safe' but if I had it would mean that although the type pointed to by a pointer returned from outside your code (like the result placed in ppv by CoCreateInstance) cannot be gaurenteed when your code is compiled because it cannot be determined, it can be gaurenteed by the external code itself, in this case the COM runtime or the external COM server. Such a gaurentee could be called 'runtime type safety'.
It is in this sense that COM is typesafe, all interfaces are derived from IUnknown which is always implemented so any interface pointers arriving in your process from outside can always be treated safely as IUnknown pointers.
Because this is all that can be gaurenteed this is also all that should be assumed, that is a very important rule of writing good code. 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I have understood your pattern, Matthew! Thanks for your patience for sharing your experience in this thread. I learned a lot from you.
regards,
George
|
|
|
|
|
Exactly, as the question is about compile time type safety
|
|
|
|
|
Thanks led mike,
For the compile time type safe issue, you mean the one I pointed in my original post?
regards,
George
|
|
|
|
|
Thanks Rajkumar,
For the Google search link you referred about type safe, there are various points which are not all the same. I am wondering which one(s) do you prefer?
regards,
George
|
|
|
|
|
I just meant search the web. Language type safety is what i meant.
|
|
|
|
|
Thanks Rajkumar,
What is your preferred definition of type safe (from the discussion, you are so knowledgeable and I think you have your or your preferred definition of type safe)? The search gives me a couple of various definitions of type safe.
regards,
George
|
|
|
|
|
|
Thanks Rajkumar,
I will read through it.
regards,
George
|
|
|
|
|
Thanks Matthew,
Which rule do you refer in the link from MSDN? Implementing IUnknown?
regards,
George
|
|
|
|
|
It's Rule number 1.[^]
"Rule #1: Must Implement IUnknown"
Hence the only certain thing about the pointer returned from CoCreateInstance, no matter how you wrap it up, it that it's an IUnknown pointer. Any assumption on top of that is at your own risk.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew!
I think both you and Rajkumar are correct.
regards,
George
|
|
|
|
|
hi guys
can i make a control say listctrl transparent,
say i have a list control in my dialog, i want to make the list control transparent so that the background of dialog will be visible through list control
Thanks
Swarup
|
|
|
|
|
|
I am using Visual Studio 6.0. Print preview changes text width on different zoom view. Let me describe in details.(Tested in an SDI application) I want to draw a text "Sample text1 Sample text1 Sample text1" whose font size is 10 and face is Arial.Just below this text I want to draw another text "Sample text2 Sample text2" whose font size is 15 and face is Comic Sans MS. Both are aligned LEFT or RIGHT.It draws fine. Now when I want to see the print preview it shows different text width than what was drawn previously. Now after zoom in again the view changes. In a word I dont get actual print preview. Can you help me plz?
|
|
|
|
|
|
Not Solved Yet. Just Create an SDI Application and insert the following codes in OnDraw()
<br />
CRect rcPos = CRect(10,10,500,40);<br />
CFont font; LOGFONT lf;<br />
ZeroMemory(&lf,sizeof(lf));<br />
lf.lfHeight = 25; lstrcpy(lf.lfFaceName,"Arial");<br />
lf.lfWeight = FW_BOLD; lf.lfCharSet = DEFAULT_CHARSET;<br />
font.CreateFontIndirect(&lf);<br />
pDC->SelectObject(&font);<br />
CString str = "Sample Text1 Sample Text1 Sample Text1"; <br />
pDC->DrawText(str, &rcPos, DT_LEFT|DT_VCENTER|DT_SINGLELINE);<br />
font.DeleteObject();<br />
rcPos.top += 30;<br />
rcPos.bottom += 30;<br />
<br />
lf.lfHeight = 30; lstrcpy(lf.lfFaceName,"Comic Sans MS");<br />
font.CreateFontIndirect(&lf);<br />
pDC->SelectObject(&font);<br />
str = "Sample Text2 Sample Text2";<br />
pDC->DrawText(str, &rcPos, DT_LEFT|DT_VCENTER|DT_SINGLELINE);<br />
font.DeleteObject();<br />
and insert following code to OnPrepareDC()
<br />
pDC->SetMapMode(MM_ANISOTROPIC);<br />
CSize sizeDoc = CSize(1000,1000);<br />
pDC->SetWindowExt(sizeDoc);<br />
CDC dcScreen;<br />
dcScreen.CreateCompatibleDC(0);<br />
int nLogPixelX = dcScreen.GetDeviceCaps(LOGPIXELSX);<br />
int nLogPixelY = dcScreen.GetDeviceCaps(LOGPIXELSY);<br />
int nDevPixelX = pDC->GetDeviceCaps(LOGPIXELSX);<br />
int nDevPixelY = pDC->GetDeviceCaps(LOGPIXELSY);<br />
if (nLogPixelX != nDevPixelX || nLogPixelY != nDevPixelY)<br />
{<br />
sizeDoc.cx = (sizeDoc.cx * nDevPixelX) / nLogPixelX;<br />
sizeDoc.cy = (sizeDoc.cy * nDevPixelY) / nLogPixelY;<br />
}<br />
pDC->SetViewportExt(sizeDoc);<br />
Now run the exe. and see print preview.
|
|
|
|
|
Its not an issue with your code, its an issue with the way print preview is implemented itself. As the screen metrics (resolution/ dpi etc) may/are not an exact match to the target print device, especially when zooming in on the content, print preview has to do an estimation when converting from the requested font size of the target DC to the screen dpi/zoom metric DC used to display the preview.
This causes the generated font size to vary slightly at various zoom levels. To see this when you select a font into a CPreviewDC you should see that is does a lot of extra work converting the font from the outputDC to the previewDC format, its at thispoint that the scaling issues occur.
If you vote me down, my score will only get lower
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
