Resolved Using struct

[RobertbNZ]

I'm having trouble using a struct. Why doesn't this work: -

        Changes Changed = new Changes();
        Changed.Skip = true;
        struct Changes
        {
            public bool Skip;
            public bool EMPNO;
        }

The line "Changed.Skip = true; is rejected with messages: -
IDE1007 The name 'Changed' does not exist in the current context
IDE1007 The name 'Changed.Skip' does not exist in the current context
In researching this I found this site where I replaced their example of struct with mine by posting this code: -

using System;               
public class Program
{
    public static void Main()
    {
        Changes Changed = new Changes();
        Changed.Skip = true;
        Console.WriteLine(Changed.Skip);
        Console.WriteLine(Changed.EMPNO);
    }
}
struct Changes
{
    public bool Skip;
    public bool EMPNO;
}

This worked perfectly, producing the expected result
True
False
I have tried moving my definition of Changes to match this code structure, first to follow the the class containing Changes Changed = new Changes();, and then to the end of the object where it follows

namespace MyJSv
{
    
}

In all cases I get the two IDE1007 messages from the 2nd of these statements, but there is no error on the first. If I write "Changed." there is no Intellisense list.

        Changes Changed = new Changes();
        Changed.Skip = true;

 

[RobertbNZ]

I would suggest downloading and installing Instant C# from Tangible Software Solutions if converting VB to C# is something you expect to do often.

I used the Telerik product quite a bit when I was beginning with C#, I rarely use it now, only when I'm trying to get something to work that I know how to do in VB, but can't seem to get right in C#. I've bookmarked Instant C#. What I really want is a "VB.Net => C# tutorial" so that I UNDERSTAND the differences. I think you'll agree that, to somebody with my VB experience, the reasons for this problem were NOT obvious.

 

[NoUserHere]

The fact that Instant can convert a project from one language to another is really good. The only thing I've noticed which appears to be a minor bug in the parsing is that it places the region in the wrong place.

//====================================================================================================
//The Free Edition of Instant C# limits conversion output to 100 lines per snippet.

//To purchase the Premium Edition, visit our website:
//https://www.tangiblesoftwaresolutions.com/order/order-instant-csharp.html
//====================================================================================================

using System;
using System.Windows.Forms;

#region Imports

That was actually embarrassing, as I actually found a vb file which was many many years old. Going back to my starting days of VB.Net. The code is awful.

But it still managed to translate it very well whereas Telerick could not parse it. I will add a link to it in my signature, as I'm sure It will be worth a reference in the future.

 

[NoUserHere]

What I really want is a "VB.Net => C# tutorial" so that I UNDERSTAND the differences.

Read the getting started link in my signature. If you want to get to know the language. Read the documentation (all of it), and don't skip any chapters. Doing so defeats the purpose of learning or trying to learn at all.

 

[RobertbNZ]

Read the getting started link in my signature. If you want to get to know the language. Read the documentation (all of it), and don't skip any chapters. Doing so defeats the purpose of learning or trying to learn at all.

Thank you, I've bookmarked this, and I'll read through it as I get time. But I repeat, I'd REALLY like something that can help me leverage my existing VB.NET knowledge as I develop C# expertise. A tutorial aimed at me and people like me would save us a huge amount of time and encourage the shift to C# from VB that MS presumably wants. Like all developers I'm busy, and I learn best as I solve my own problems, we don't want to spend more time than we need to on understanding basics and classroom problems. Those of us with VB expertise could come up to C# speed much more effectively than by reading extensive soporific documentation before we can get started.

I'm going to mark this issue Resolved now, it was solved for me with John's comment much earlier, and the difference between VB and C# rules perfectly illustrates why a VB => C# tutorial would be valuable.

 

[jmcilhinney]

I think you'll agree that, to somebody with my VB experience, the reasons for this problem were NOT obvious.

I don't agree with that at all. Unless I'm missing something, VB would have rejected the equivalent code for exactly the same reason.

 

[RobertbNZ]

I don't agree with that at all. Unless I'm missing something, VB would have rejected the equivalent code for exactly the same reason.

I don't agree with that at all. Unless I'm missing something, VB would have rejected the equivalent code for exactly the same reason.

I gave this example earlier in this topic. Are these not equivalent?

        bool Changed_Skip = false;
        Changed_Skip = true;

        Dim Changed_Skip As Boolean = False
        Changed_Skip = True

 

[jmcilhinney]

I gave this example earlier in this topic. Are these not equivalent?

        bool Changed_Skip = false;
        Changed_Skip = true;

        Dim Changed_Skip As Boolean = False
        Changed_Skip = True

Yes they are equivalent, and they both either work or fail in the same places for the same reasons.

In both cases, the code is valid inside a method but is invalid inside a type but outside a method because only declarations are allowed at that scope. The assignment is invalid at the class level in both cases for the same reason.

 

[RobertbNZ]

Yes they are equivalent, and they both either work or fail in the same places for the same reasons.
In both cases, the code is valid inside a method but is invalid inside a type but outside a method because only declarations are allowed at that scope. The assignment is invalid at the class level in both cases for the same reason.

You're quite right. That's really subtle. I've spent almost 15 years working with ASP.NET and VB.NET and never properly understood the difference between "inside a type" and "inside a method". Almost ALL code I've written has been within a method, there is very little opportunity to write code "inside a type but outside a method" in a forms or ASP.NET application.

I really believe that there is a need for the Tutorial "Learning C# after VB", and if it doesn't exist then I'll be producing it for my own use over the next few months as I develop C# expertise. Here's an offer. If I start writing this, is anybody in MS interested in working with me, with a view to this becoming part of MS documentation. If you want to see the quality of my documentation, have a look at the Users' Guide and Language Reference sections of the MANASYS Jazz Help

 

[Skydiver]

there is very little opportunity to write code "inside a type but outside a method" in a forms or ASP.NET application.

This would imply that you have severely limited yourself by only using the WinForms or WebForms Designer and only adding in code after you double clicked on a control and put in code into the event handler. If that implication is correct, then that would also lead to the conclusion that the code written is likely using the visual controls as the data model, and that the business logic is intertwined inside the code for the various event handlers.

This not the way modern code is written anymore. The same way modern C++ is not written as C-with-classes anymore, modern .NET applications (regardless of C#, VB.NET, F#, or IronPython) try to keep a separation between the data model, business logic, and the visual display. Yes, blog posts and toy applications may still mash these elements together, but often the point of the blog post or toy application is to showcase a particular technology or technique, not to be an example of production ready code.

 

[RobertbNZ]

This would imply that you have severely limited yourself ...

You're probably correct. Some aspects of my situation might be relatively uncommon: I had been a developer in the mainframe era (PL/I, COBOL, with MVS (now ZOS)), then started a software company developing mainframe and then Unix and PC software (MS-DOS, then Windows 3.11 => 95 => 98 => NT etc.), then I sold this company and became an IT consultant advising companies on their systems requirements and managing project teams to deliver them. I recognized that Visual Studio development was very different to the world of punched cards and batch compiles, and I decided to teach myself modern programming, so I started with an ASP.NET application (FamNet) now hosting over 15M family history records. One only learns by doing something real, classroom exercises are superficial. Then I retired. When a request came for an IBM version of my original mainframe (Fujitsu) product I grabbed it because I was a bit bored, and this has led to MANASYS Jazz, a Windows Forms application that provides modern programming tools to the world of mainframe users. Through this period I have been working on my own, and I have learnt Visual Studio/VB.NET programming from textbooks, forums, Google. You're wrong to think that I've written most of the code within event handlers: almost all of the code of MANASYS is in the back end language parser and code generator. You're right however to suggest that I've limited myself, and I have certainly baked in some mistakes, like using List because I didn't then know about LinkedList or Dictionary. I understand well the issues of separating data model, business logic, and visual display, I've been dealing with this since mainframe days, and you'd see this exemplified in the internal design of MANASYS.

Other aspects are very common. Like all developers, once I'd grasped the basic concepts of ASP.NET and VB.NET always my learning was directed to "How do I do xxxx?" We're all under time pressure, once we've found something that works we'll use it, we don't read about all the other methods and properties that aren't immediately necessary, or the subtleties of a class derived from X compared to a class derived from Y. Much of the documentation is infuriating, written from the point of view of the developer, not from the point of view of a user who wants to achieve something. There are some class description pages that I've pored over for hours and still not found out "When should I use this? How?"

Hence my offer to work with somebody in Microsoft to develop the tutorial that I suggested. It would benefit me by enlarging my knowledge of the technology that I'm using, and it would benefit MicroSoft by bringing a user perspective that is sadly lacking.

 

[Skydiver]

My understanding is that there are 1 or 2 MVP's or former MVP's here. They maybe able to provide you with the right contacts at Microsoft for a writing gig. The three technical writers I knew when I used to work there have either retired, or changed careers, otherwise I would have tried to make an introduction.

I'm sorry if the documentation you are running into is written that way. For me they have been written quite well. Well, at least the documentation written after 2005 or so. Prior to that, yes, MSDN documentation was actually quite poor. Those three people I would have reached out too were some of the people who helped MS turn the corner by changing the way docs were written.

 

[Skydiver]

almost all of the code of MANASYS is in the back end language parser and code generator.

If that is true, then you wouldn't be a situation where almost all your code would be just inside methods. Yes, a majority would be inside methods, but there would have been places where you would have encountered the same situation you had at the beginning of this thread.