Resolved Immidiate window ??

[ksor]

I'm using VS2022 and I just re-entered working with C# - last time was VS2008 !

How come I can't ask for values NOT used in the code when I'm want to see the values in the Immidiate window - it return with someting like: "Can't evaluate thie because it's NOT usen in the program"

Well, if it WAS used in the program (=code) I had no need for asking in the Immidiate window - would I - I do NOT remember VS2008 was reacting this way - I could ask avalues of whatever I wanted to !

 

[jmcilhinney]

The point of the Immediate window is to help you work out what's going on in your program. Why would evaluating things that aren't used in your program be a thing you would want to do and how would it even work? I use it regularly for exactly that and so do many thousands of developers the world over. I suggest that you learn what the Immediate window is and isn't here. After that, if there's still a problem, you might try providing us with an actual example of what you think should be possible in the Immediate window but isn't.

 

[ksor]

The point of the Immediate window is to help you work out what's going on in your program. Why would evaluating things that aren't used in your program be a thing you would want to do and how would it even work? I use it regularly for exactly that and so do many thousands of developers the world over. I suggest that you learn what the Immediate window is and isn't here. After that, if there's still a problem, you might try providing us with an actual example of what you think should be possible in the Immediate window but isn't.

It would be nice to know the COUNT in a Fore Each XX and you you can't get that, because COUNT is not used in the code !

I often used the Immidiate window to just "browse" the values of different properties in the object I handle in the code - that you can't do either !

I think that's a normal use of that window - right ?

Did I turn OFF something or what ?

 

[jmcilhinney]

It would be nice to know the COUNT in a Fore Each XX and you you can't get that, because COUNT is not used in the code !

The count of what? You mean the number of items in XX? If so then obviously XX is used in the code so you need to get that value of the XX.Count property. It should be obvious that you can't just type "count" in the Immediate window and it read your mind to know what that means. You have to enter code that actually means something to the compiler.

I often used the Immidiate window to just "browse" the values of different properties in the object I handle in the code - that you can't do either !

Of course you can. Provide a specific example because I can only assume that you are doing something wrong that you haven't actually bothered to describe.

 

[ksor]

I don't think I'm that dement - if the for/next loop in the code is a for EACH/next then I often wont to know how MANY items I can expect - but I CAN*T ask that in the Immidiate window - not on my machine !

You write"Of course you can. Provide a specific example because I can only assume that you are doing something wrong that you haven't actually bothered to describe."

Herer I have an example - I want to know how many 'items' the outLookNS.Stores have:

When I type in the Immmidiate window 'outlookNS.Stores.' then it presents the property 'Count' for me - but can't evaluate it anyway !

What do I misunderstand here ?

 

[Skydiver]

There is a difference between plain C# objects and objects that you you obtain via the Office Object Model. The former is early bound, while the latter in late bound. With early bound objects, the code is generated at compile time to allow for access to all its members. With late bound objects, an IDispatch COM interface is obtained at runtime and invoked to call external code. Apparently the immediate window is optimized for the early bound case. This is why there is a suggestion in the error message saying to try casting the object to dynamic.

If you are thinking/saying but I used to do this all the time in VB6 and it worked, the reason for that is that VB (before VB.NET) was always late bound. The IDE there knew how to do access to late bound objects.

 

[ksor]

There is a difference between plain C# objects and objects that you you obtain via the Office Object Model. The former is early bound, while the latter in late bound. With early bound objects, the code is generated at compile time to allow for access to all its members. With late bound objects, an IDispatch COM interface is obtained at runtime and invoked to call external code. Apparently the immediate window is optimized for the early bound case. This is why there is a suggestion in the error message saying to try casting the object to dynamic.

If you are thinking/saying but I used to do this all the time in VB6 and it worked, the reason for that is that VB (before VB.NET) was always late bound. The IDE there knew how to do access to late bound objects.

>Skydiver - Oh, yeah - of cause you're right ... slowly I remember some things again from my last experience with VS2008 - early/late bound and it's coming up here again - THX

Anyway ... the intellisense is sometimes a little slow or not working in the Immidiate window ...

Early/late binding is the problem here - so THX again !