|
I am writing a client to access a COM server that
was apparently implemented in VB. When I use #import
on the dll, the intermediate file doesn't compile
because some of the parameters return arguments of
the form "CollectionPtr* pFoo". I can find no reference
for this type supported by C++, or ATL, or MFC.
When browsing the dll with the COM object viewer, the
IDL shown does indeed show the Collection** argument
type.
Is there a way to use these Collections from a C++
client program?
Thanks
Regs
Prakash
|
|
|
|
|
CollectionPtr is a generated type, a smart-pointer wrapper for "Collection", and will be in the .tlh or .tli file that's generated by '#import'. That leaves you with 'what is a Collection'.
Steve S
|
|
|
|
|
A Collection is a VB object that has an IDispatch interface but (as far as I recall) does not have a non-dispatch COM interface. You can use it from C++ but it is a little inconvenient since you have to use the IDispatch interface.
The things that the intermediate file shows as CollectionPtr you can generally use as IDispatchPtr.
You want to call functions through the IDispatch interface with the names _NewEnum to get an Enumeration over the items in the collection (typically IEnumVARIANTPtr), Count to get a count of items in the collection, and I think there is usually an Item function to get a particular item from the collection by index.
|
|
|
|
|
Hmm... this may be one of the most frequently asked questions but I've already searched the web and couldn't find anything, so please forgive me posting this question 
Why is ASSERT in release version defined as (void)0 and not as just nothing? What will (void)0 compile to (on binary, assembler level)?
Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? 
(doesn't work on NT)
|
|
|
|
|
Dominik Reichl wrote:
What will (void)0 compile to (on binary, assembler level)?
NOP
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
DavidCrow wrote:
NOP
So it's wasting time! 
Why not defining it as nothing? This wouldn't waste a CPU cycle, would it?
Thanks!
Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
(doesn't work on NT)
|
|
|
|
|
Not necessarily.
It might be optimised out in the final code...
Steve S
|
|
|
|
|
But, for example, take the TRACE0 macro. This macro is defined as just nothing instead of ASSERT. So there must be a reason why ASSERT is defined as ((void)0)...
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
(doesn't work on NT)
|
|
|
|
|
Dominik Reichl wrote:
Why is ASSERT in release version defined as (void)0 and not as just nothing?
Because removing code could result in confusing compiler warnings. Consider this:
if ( some_flag )
ASSERT(something_else);
Now, remove the ASSERT entirely and you get:
if ( some_flag )
;
which generates a compiler warning because of the empty statement after the if.
--Mike--
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
CP SearchBar v2.0.2 released
|
|
|
|
|
But
if ( some_flag )
TRACE0("Closed file successfully.\n");
TRACE0 is defined as just nothing, so it _is_ translated to
if ( some_flag )
;
So TRACE0 cannot be used the same way as ASSERT? Both TRACE0 and ASSERT take one parameter... 
Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? 
(doesn't work on NT)
|
|
|
|
|
(void)0; is essentially a 'null' statement. It doesn't generate any code, but satisfies the compiler requirement for a statement. As mentioned elsewhere in the thread, it is not an empty statement:
; which may generate compiler warnings depending on where it is used.
Software Zen: delete this;
|
|
|
|
|
is it possible to change style of a CComboBox form dropdown to dropdown-list?
i mean: not re-create a new box.
thx.
includeh10
|
|
|
|
|
Yes, on the Styles tab of the Combo Box Properties dialog, simply select Drop List from the Type box.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Unlike David, I'm assuming you mean at run time, not design.
No. The combo caches the initial style and creates the associated widgets like a separate list box etc in some cases.
Steve S
|
|
|
|
|
Another solution is SetExtendedUI().
Kuphryn
|
|
|
|
|
Hello.
I'm currently designing a user interface for a piece of physics software which is currently only able to run through DOS. I'm new to Visual C++, and haven't done much programming for windows before. I have created an SDI MFC using the MFC App Wizard. The main menu contains the items: File Edit Setup Help.
When the user clicks on Setup (which is not a pop-up menu, it acts more like a button), a modeless dialog box opens up. What I want to do is have the Setup option disabled until the user opens a file (File -> Open). I have found lots of information on how to disable/enable items contained within these menu options, but not on how to deal with the menu options themselves. I am pretty sure that I must make use of ON_ UPDATE_COMMAND_UI, I'm just not completely sure what to do.
Any help anyone could provide me would be greatly appreciated!
|
|
|
|
|
Yep, that's the way to do it. Look at the excellent article of Michael Dunn, "The Code Project Visual C++ Forum FAQ"[^], you may find there some useful info.
HTH,
K.
Every gun that is made, every warship launched, every rocket fired, signifies in the final sense a theft from those who hunger and are not fed, those who are cold and are not clothed - Dwight D. Eisenhower
|
|
|
|
|
I have looked at that article, and I do have an CMainFrame::OnUpdateSetup(CCmdUI* pCmdUI) function (with the message map ON_UPDATE_COMMAND_UI(ID_SETUP, OnUpdateSetup)), but I don't know how to actually call this function.
I thought that I could use ON_COMMAND(ID_FILE_OPEN, OnFileOpen) and in OnFileOpen make some sort of call to the OnUpdateSetup which will activate the setup option if a file has been opened. I still don't understand how i'm supposed to code: if a file has been opened, enable the Setup option in the menubar.
|
|
|
|
|
You don't have to explicitely call this method, the MFC framework will do it for you when needed and when CPU time available. Once the method declared, the only thing you have to do is to define the condition of sensitivity (pCmdUI->Enable(<<condition>)). the="" condition="" could="" for="" example="" be="" a="" boolean="" attribute="" set="" to="" true="" when="" file="" is="" opened.
hth,
k.=""
<hr="" color="#ADBDFF" width="60%" align="left" height="10%">
Every gun that is made, every warship launched, every rocket fired, signifies in the final sense a theft from those who hunger and are not fed, those who are cold and are not clothed - Dwight D. Eisenhower
|
|
|
|
|
But how do I tell the MFC framework to do it when it's needed? I don't need the Setup option activated until a file is opened. So how do I do this? I understand that I don't have to explicitly call this method, but I do need to somehow indicate when I want the setup menubar option to become enabled.
This is what I have at the moment:
...
ON_UPDATE_COMMAND_UI(ID_SETUP, OnUpdateSetup)
ON_COMMAND(ID_FILE_OPEN, OnFileOpen)
...
void CMainFrame::OnUpdateSetup(CCmdUI* pCmdUI)
{
pCmdUI->Enable(true);
}
void CMainFrame::OnFileOpen()
{
CString fileName;
CString szFilter = "All Files (*.*)|*.*||";
CFileDialog cfd(true, NULL , NULL , OFN_HIDEREADONLY, szFilter, NULL);
cfd.DoModal();
fileName = cfd.GetFileName();
//this is where i want to say that if a file was selected
//enable the setup menubar option
}
|
|
|
|
|
The MFC framework knows what OnUpdate... methods to call thanks to the message map.
Let's suppose you add a boolean attribute to the mainframe, called m_bFileOpen, set to FALSE in the constructor. Your code would be:
void CMainFrame::OnUpdateSetup(CCmdUI* pCmdUI)
{
pCmdUI->Enable(m_bFileOpen);
}
void CMainFrame::OnFileOpen()
{
CString fileName;
CString szFilter = "All Files (*.*)|*.*||";
CFileDialog cfd(TRUE, NULL , NULL , OFN_HIDEREADONLY, szFilter, NULL);
if(cfd.DoModal() == IDOK){
fileName = cfd.GetFileName();
m_bFileOpen = TRUE;
}
}
HTH,
K.
Every gun that is made, every warship launched, every rocket fired, signifies in the final sense a theft from those who hunger and are not fed, those who are cold and are not clothed - Dwight D. Eisenhower
|
|
|
|
|
For completeness, you might want to support resetting the flag on close.
If you were using MDI document view, you could have the main app see if the documents collection was empty instead.
Steve S
|
|
|
|
|
You're right. But I think the app is a SDI one  ;)
To be more accurate, I think the boolean should be attached to the document class, set to TRUE when OnOpenDocument succeeds, and set to FALSE on OnCloseDocument.
Every gun that is made, every warship launched, every rocket fired, signifies in the final sense a theft from those who hunger and are not fed, those who are cold and are not clothed - Dwight D. Eisenhower
|
|
|
|
|
yeah, it is SDI...
and you're right, attaching the boolean variable to the Doc class would probably be best...
Thanks for all the help!!
|
|
|
|
|
Thanks for the help. One more question, I'd like the Setup option to appear greyed out when it is disabled. Is there something similar to:
pCmdUI->Enable(m_bFileOpen);
that will do this? I thought that by disabling it, it would automatically grey it out as well, but i was wrong.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
