Referenced structure not 'sticking'

Question

I am currently porting a lot of code from an MFC-based application to a DLL for client branding purposes.

I've come across an unusual problem. This bit of code is the same in both systems:

// ...
    CCommsProperties props;

    pController->GetProperties( props );
    if (props.handshake != HANDSHAKE_RTS_CTS) 
    {
     props.handshake = HANDSHAKE_RTS_CTS;
     pController->RefreshCommProperties( props );
    }

// ... in another file: 
void CControllerSI::RefreshCommProperties ( const CCommsProperties& props )
{
    // ... code ...
}

CommProperties is a wrapper for the comm settings, serialization of etc. and pController is of type ControllerSI which itself is a layer between the actual Comms and the Application.

On the original MFC version the setting of handshake to RTS-CTS sticks but when running as the DLL version it resets itself to 0 as soon as the function is entered. The code is contained entirely in the DLL section of the code, so there are no boundaries.

The main differences between the original and the new modules is the variables that call the various dialogs have been removed and the removed #includes

I've lost an afternoon to this and I don't really want to lose any more...

Answer 1

It is difficult to see what is wrong from the given code alone. Some general pointers:

1. The object is initialized and processed in different binary modules with incompatible linking (such as C-run times)

2. If the class/structure is shared it is not exported/imported correctly.

3. The class(s) are defined in more than one place, and you are not including the correct definitions.

The above three are the most likely causes, especially, if all fields are reset to their default initialized values.

if this is only happening with only one or two fields, the structure may be poorly aligned and you may need to rearrange the fields to correct these (check that in release too).

In general, I am tempted to hypothesize that the object you have intialized is not the one RefreshCommProperties() sees, for some reason, may be one of the three above.

Answer 2

To really figure out what is going on, you probably need to post your source code -- or at least as much to replicate the problem. Unfortunately, StackOverflow doesn't seem like it encourages this. You could post your code on an FTP site or go to a site that allows posting of source code (like CodeGuru).

Answer 3

It's possible that CCommsProperties are defined in two different places, and each file includes its own version.

To test this theory, in the debugger you need to look at &props.handshake . If debugger tells you that the field has different address inside and outside the function, then the hypothesis is true and you can proceed to examining preprocessor output to figure out why it happens.

Answer 4

After Saratv posting, I decided to ditch what I had done and restart it from working source again.

This time however it works...I guess I will never know why passing a structure caused it to change.