locked
conditional compilation; Intellisense doesnt seem to be working RRS feed

  • Question

  • Dear All.

    I am using VC 2005, writing a chunk of code like this...

    #ifdef USE_LICENSING
    #include<file1.h>
    code...
    code..
    #endif

    the editor grays out the code between then ifdef and endif tags, I can use features like intellisense only if i comment out ifdef and endif tags..

    anyone aware of this??

    Satish
    Boston,MA.
    Wednesday, November 30, 2005 6:12 PM

Answers

  • As long as USE_LICENSING is not defined in your code then it doesn't matter what you have in between and hence Intellisense greys it out.


    Thanks,
      Ayman Shoukry
      VC++ Team
    Wednesday, November 30, 2005 6:31 PM
  • I will make this easier for you and log a suggestion issue on your behalf directly into our database.

    Thanks,
      Ayman Shoukry
      VC++ Team
    Wednesday, November 30, 2005 11:54 PM

All replies

  • As long as USE_LICENSING is not defined in your code then it doesn't matter what you have in between and hence Intellisense greys it out.


    Thanks,
      Ayman Shoukry
      VC++ Team
    Wednesday, November 30, 2005 6:31 PM
  • This is a shortcoming present in all the Visual Studio languages.  It's an obvious oversight (and has been since the dawn of VS.NET) since you should be able to use intellisense regardless of the value of any conditional in the vicinity (there is no restriction when using other types of conditionals, for instance - i.e., if you have "if (false)", you can still use intellisense for that code block).

    David Anton
    www.tangiblesoftwaresolutions.com
    Instant C#: VB.NET to C# Converter
    Instant VB: C# to VB.NET Converter
    Instant C++: C# to C++ Converter
    Instant J#: VB.NET to J# Converter
    Clear VB: Cleans up outdated VB.NET code
    Wednesday, November 30, 2005 11:29 PM
  • That is a very good point. Could you please log a suggestion issue at http://lab.msdn.microsoft.com/productfeedback/default.aspx.

    Thanks in advance in taking the time to log the issue!

    Thanks,
      Ayman Shoukry
      VC++ Team

    Wednesday, November 30, 2005 11:45 PM
  • I would if I didn't need to re-enter all the information that I've already entered when I signed up initially...  (maybe I should enter a suggestion to not require re-entry of all that information when making a suggestion...)

    It says you can click 'Cancel' if you don't want to, but that just takes you out of the entire suggestion area.

    Wednesday, November 30, 2005 11:52 PM
  • I will make this easier for you and log a suggestion issue on your behalf directly into our database.

    Thanks,
      Ayman Shoukry
      VC++ Team
    Wednesday, November 30, 2005 11:54 PM
  • Thanks!
    Wednesday, November 30, 2005 11:56 PM
  • Done! The suggestion is now logged in our internal database. The responsible folks will for such look into such issues before our next update if it is a new version or a SP.

    Thanks,
      Ayman Shoukry
      VC++ Team
    Thursday, December 1, 2005 12:04 AM
  • Not sure if my problem belongs to this post... Not even sure if it`s a bug or a feature, but the code between #ifdef and #endif is grayed out when the condition is defined in a specific configuration`s properties under preprocessor definitions (and that config is selected). Not very convenient since I can`t use intellisense Sad
    Friday, December 2, 2005 8:50 PM
  • I added your issues to the bug entry I created before.

    Thanks,
      Ayman Shoukry
      VC++ Team

    Friday, December 2, 2005 8:54 PM
  • (removing duplicate post)
    Friday, December 2, 2005 9:00 PM
  • Ambiguities get in the way of using intellisense.  I am not really bought into the idea of letting intellisense parse both arms of a #ifdef/else/endif, because it is often the case that you're defining something two different ways depending on the preprocessor value. 

    e.g.

    #ifdef OLD_VERSION
    void function(int, char*);
    #else
    void function(int, char*,bool).
    #endif.

    Do you want Intellisense to give you both choices, letting you choose one that won't compile? 

    If you look at the CRT headers, there are a lot of #if's in there, depending on a build, and less noise would better when it comes to intellisensing these headers.

    Brian

    Friday, December 2, 2005 9:09 PM
  • I would not say that it seems not to be working, but that it does no more work at all.

    From my opinion, “improvements” made on IntelliSense in VS 2005 are in fact a regression. Or otherwise how do you call something that gives you less opportunity than you had before?

     

    - Everything under conditional directives is no more used by IntelliSense.

    - Writing code inside conditional directives doesn't let you use IntelliSense no more.

     

    I was thinking that IntelliSense was a great tool helping the developer in rapid development.

    When you develop, and unless you are a very beginner you often implement conditional paths at the same time, but this now requires you to modify your defines in order to be able to use the power of IntelliSense. This in addition with the time taken for the IntelliSense engine to react to the modifications (In the project I’m working actually, the quickest way to get back IntelliSense after definition changes is to unload/reload the project after a change) is really not an improvement for an efficient work.

     

    IntelliSense now recognize macros, well… great, it gives you some information about parameters. But:

    - This is without the power you obtained before by defining a fake prototype for your macro in within conditional directives.

     

    #ifdef _0

    BOOL SET_ERROR( int nSeverity, LPCWSTR szText ){};

    #endif

    #ifdef _SEVERITY_DEFINED

    #define SET_ERROR( nSeverity, szText ) g_fVar ? (ErrorWithSeverity( nSeverity, szText ), TRUE) : FALSE;

    #else

    #define SET_ERROR( nSeverity, szText ) g_fVar ? (Error( szText ), TRUE) : FALSE;

    #endif

     

    // Now SET_ERROR is recognized as a function with a return code (not in VS 2005).

     

    - What about macro having no explicitly defined parameters (often function mappings).

     

    #ifdef _0

    void DEBUG_TRACE( LPCWSTR szFormat, ... ){};

    #endif

    #ifdef _DEBUG

    #define DEBUG_TRACE ::DbgTrace

    #else

    #define DEBUG_TRACE 1 ? (void)0 : ::DbgTrace

    #endif

     

    // Now DEBUG_TRACE is recognized as a function (not in VS 2005).

     

    - It is now impossible to get IntelliSense for variables defined within the macros

     

    void Method( long lParam )

    {

        METHOD_INIT( CClass );

    #ifdef _0

    CClass* pItem;

    #endif

     

        // Now pItem-> pop-up and give the members (not in VS 2005).

    }

     

    And I certainly did forget some...

    Wednesday, December 7, 2005 11:28 AM
  • Wednesday, December 7, 2005 2:26 PM
  • I agree that I.S. takes way too long to populate its database and I've found it to not be completely reliable in more complex scenarios. 

    This is what I've tried:

    #if 0
    void FOO(int x,int y) {}
    #define FOO(x) (x+1)
    #else
    #define
    FOO(y) (y+2)
    #endif


    int
    _tmain(int argc, _TCHAR* argv[])
    {
    // After you wait about a minute or two...type
       return
    FOO( // <- intellisense suggests FOO(y), which is the correct context.

    If intellisense gave you all three options: FOO(x,y) -- a function, FOO(x) -- a macro, and FOO(y) -- a macro, you have what some people would call "a mess."

    I would expect intellisense to use exactly the definition that I would get if I right click on FOO and do "go to definition."

    I think your first point about a fake prototype was just taking advantage of buggy behavior.  However I do see how this would be nice for things that are conditionally compiled, like debug macros.  You might be able to pull this off by using variadic macros, which are macros that take a variable number of arguments.  This C99 standard was just implemented in VS2005, and it relieves the need to write macros like above, where a zero-arg macro maps to a function name only. 

    If this approach is feasible, then I wonder if the Microsoft headers should be revised so that these kind of macros would work under intellisense.

    Brian



    Wednesday, December 7, 2005 2:40 PM
  • This is indeed something That was beind my back and frustrated me without noticing the problem itself... Thnx guy for the submission! I hope now Microsoft fixes it.... ( I wonder why VS.Net 03 didn't have any service packs... )
    Wednesday, December 7, 2005 4:58 PM