|
We recently upgraded to VC.NET 2003, and have noticed some alignment problems with some of our structures that we serialize to disk. I checked my old settings in VC6, and noticed that all the products have the "Struct Byte Alignment" set to 8 bytes. I wrote code that would check the sizes of all our serialized structs, and all the sizes were calculated correctly.
I then went over to VC7 and checked the project settings, he was also setup to 8 byte alignment. I ran the same size check code, and quite a few of the sizes are not the same as in VC6, which is causing us all kinds of headaches.
I've tried changing the alignments, and our structures are still off in VC7, even though the settings are the same. Has anyone else had this problem? Any tips/tricks? ... What kinds of things do you do when setting up a struct? Which items in the struct have to be on 4/8 byte boundaries etc?
Anything you can send would be appreciated.
Thx.
Mike.
doner@obtain.com
|
|
|
|
|
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!!
|
|
|
|