Seeing Common Blocks - Part II

[Intel_C_Intel]

Steve,

I posted a previous thread about seeing the CONTENTS of common blocks DLLIMPORTed into a DLL from a primary executable, in the IDE Watch window.

You said:

It's a bug, sorry. Fixed in 6.6 (free upgrade for 6.5 users, coming in August.)

Well, I downloaded the upgrade (no problems btw) and it still doesn't work.
Am I missing something? Or am I expecting too much?

For example I have a common block called DATASIZES, which contains some integer values - e.g. MAX_ITEM. The Watch window displays the STRUCTURE of DATASIZES (see below) - but not the values of its elements...

DATASIZES Undefined address
DATASIZES%MAX_CLASS Undefined address
DATASIZES%MAX_FLUID Undefined address
DATASIZES%MAX_ITEM Undefined address
DATASIZES%MAX_STRM Undefined address
DATASIZES%MAX_TABLE Undefined address
DATASIZES%MAX_USERF Undefined address

This is not an insurmountable problem for me because I can debug the main exe too, but our project guys who will be developing the DLL will probably want to be able to see this stuff...

Any ideas?

[Steven_L_Intel1]

Please send an example to vf-support@compaq.com I know that I answer a lot of questions here, but this is not supposed to be a mechanism for reporting problems to Compaq.

Steve

[Intel_C_Intel]

That's just the thing - I don't think this is a Compaq problem (i.e. with the IDE or Compaq products) I think its me :) I found a partial fix - I moved my DLLIMPORT statements for the common blocks to be before the INCLUDE statements which include the definitions of the common blocks (I think previously I was only 'seeing' the local (DLL) definition of the common block, not the main (EXE) definition). However, it doesn't work on all the common blocks (lucky, it does work on the most important ones!). So now I think it could be related to the order of imports / exports / includes, but I have no idea how to check this other than trial and error.

Is there anything I should keep in mind here?

[Steven_L_Intel1]

An example is worth a thousand words.

When importing a COMMON from a DLL, you need the following:

• There must be a correct DLLEXPORT directive in the BLOCK DATA subprogram (preferably) that declares the COMMON which you link into a DLL.
  
• There must be a correct DLLIMPORT for the COMMON directive in each subprogram that uses the COMMON
  
• You must link against the export library created from building the DLL
  
• To see the COMMON in the debugger, the DLL needs to have been built as a debug configuration and its PDB file available.
  

Again, if you're having problems with this, send us an example.

Steve

[Intel_C_Intel]

That's just the thing - I don't think this is a Compaq problem (i.e. with the IDE or Compaq products) I think its me :) I found a partial fix - I moved my DLLIMPORT statements for the common blocks to be before the INCLUDE statements which include the definitions of the common blocks (I think previously I was only 'seeing' the local (DLL) definition of the common block, not the main (EXE) definition). However, it doesn't work on all the common blocks (lucky, it does work on the most important ones!). So now I think it could be related to the order of imports / exports / includes, but I have no idea how to check this other than trial and error.

Is there anything I should keep in mind here?

[Intel_C_Intel]

I don't know where the doubled reply came from, but I've figured out the problem. The remaining 'invisible' common blocks are invisible because my test DLL does not reference any of their elements - if I add in some dummy references the common blocks become visible! Tada!

Thanks for your input anyway Steve.