TheSwamp
Code Red => .NET => Topic started by: Kerry on February 22, 2007, 05:28:11 PM
-
I think some people are going to have a tough time.
I'm seeing people who hardly understand VBA trying to convert to VB.NET and expecting to learn NET overnight without studying.
This change takes time and effort guys !! ... but with the associated benefits ... spend the time and do it correctly.
:| I've just about decided I shouldn't be even looking at VB code from today onwards.
-
You don't need to study something to learn it. There are a lot of people in this world who can't learn things by studying, they need to jump in and start messing around to truly understand it.
-
I think the biggest problem isn't so much the language/s as such, it's the huge api that .net brings to the table, then there's the autocad api that probably about doubled (or more) with the introduction of the arx wrappers!
Yes, patience is definitely required and there's a lot to learn, but baby steps (back to basics) is the way to go ;)
-
I agree wholeheartedly there Kerry.
-
You don't need to study something to learn it.
< blink >
That is an oxymoron.
There are a lot of people in this world who can't learn things by studying
Sums up the reason for this thread nicely.
they need to jump in and start messing around to truly understand it.
Which therefore means they ARE studying it then, doesn't it...
-
they need to jump in and start messing around to truly understand it.
Which therefore means they ARE studying it then, doesn't it...
True, but not in the classical sense ...
Most people associate studying with reading books and trying to apply the information, while I would suspect Tim means more of a "I wonder what happens if I do this" type of scenario ...
I have heard many times that things learned through study are fine, but those learned through experience are exquisite ...
-
One problem is lack of simple examples. There is no such thing as a super simple .net prog.
At a minimum, you must set up VS or whatever compiler to use the right references, and debug settings (loadlock thing).
Getting over that first hump, and understanding the minimum to replicate that from scratch, takes more than in the past.
I do think the adesk labs and these forums do a good job of helping, its just that people are expecting the future to be easier than the past. IMO, the .net API is much harder than activex. There is no nice help file for the .nat api like with vba. The SDK help files do not seem to answer my questions, mine are usually very simple.
Once we get lots of examples going, I think people will pick it up. I think the difficulty is balanced out by the fact that you only need one language to do decent apps, not like lisp and VBA, where you need objectdcl or a lisp to define the command function to run tha vba. .net is self contained.
Part of the reason I posted the ChLayColt project was to get people going on the patterns of common use.
-
Just to forstall any hijack into the semantic meaning of the word study ;
The object of the exercise, whichever way it's done is to gain knowledge.
If someone is able to gain knowledge of a programming language by experimenting alone ... more power to them.
-
Just to forstall any hijack into the semantic meaning of the word study ;
The object of the exercise, whichever way it's done is to gain knowledge.
If someone is able to gain knowledge of a programming language by experimenting alone ... more power to them.
No hijack intended ... carry on with previous discussions ...
-
Think about this, the first time I got serious about lisp, there was a full book out called "Maximizing Autolisp" (still on my shelf!).
There aint no Maximizing .net book out, and very few people are handing out .net programs to do little things.
I would say .net programming for acad is still pretty young, and this is why its so fun too.
-
Would you say that trying to learn a whole new language would be easier then to use a previous VB(a) ``Knowledge'' when making the jump to dotNET? -i.e., Would it be easier to start using, for instance, Boo?
-
.... Would it be easier to start using, for instance, Boo?
Where would one get peer to peer help for Boo in AutoCAD ?
-
James,
There's one main reason you don't see the C++/ARX developers "handing out" sample programs - it's hard and it takes a LOT of time to master. Once this is done, people are reluctant to release that knowledge to give others a "free ride", so to speak. To be proficient enough in C++ is difficult - add ARX to the mix and you have a whole other level.
Why do I mention this? To draw a parallel. .NET is not easy to begin with either and then you add the AutoCAD side in. Plus, you have more than one language that is suppoed to be able to do exactly the same thing.
And yes, it's a lot of fun.
Just my $2
Cheers,
Glenn.
-
I understand completely, I think this will change a bit with time, code will not be so original after a while.
I remember seeing an entire lisp subroutine library for free on one site, it takes time though.
On the topic of using previous VB knowledge, I would say its much easier to go to .net once you know some activex language. Its all about objects and inheritance in .net, so at least knowing objects and classes is a big help.
Its really hard for pure lispers to go to .net though, you have to rethink a lot of things as lists are like non-generic collections, not to be used everywhere. You package data differently in .net.
The thing I hate the most about .net is I have to close and restart acad every debug. Maybe VSTA for acad will ease the pain someday. I'd sure like it to make the same dll VS makes, none of this wierd dvb stuff.
-
Where would one get peer to peer help for Boo in AutoCAD ?
Good point.
-
The thing I hate the most about .net is I have to close and restart acad every debug
Agreed. That really put me off. The things I couldn't do in vba I couldn't do in net, so it seemed to be extra work for little payoff. I guess that's going to change soon as vba is given the concrete gumboots and I'll be left with no choice.
-
The thing I hate the most about .net is I have to close and restart acad every debug
No biggy. Although I haven't investigated it, there is an edit and continue debug option in 2005...rather like VBA from what I understand.
The things I couldn't do in vba I couldn't do in net
I'd love to know what you couldn't do...
-
I was thinking about a thread on that, like an excel form with lisp vba net etc listing can and cant does. I only got as far as jotting a few things down, I know there are plenty more.
Well wipeout in 2007 is a no go in vba and as you said a no go with net. The rest look a bit like I need to listen to Kerry and study up.
1) Ghosting (Inserts, rotations etc. require send command)
2) Add wipeout.
3) Make a layer filter active.
4) Set views and Ucs's in a split viewport.
5) Read and set dxf codes.
6) Set clip boundaries.
7) Get activeview that has not been saved.
8) Set imageframe
9) Recognise Rtext
10) Set arclength symbol
11) Add a command.
12) 3dSolid endpoints,midpoints etc.
Can do but requires lisp.
1) Math class- using vlax-curve
2) Set LeaderType
3)Viewports- set viewangle and dxf 79 (Orthographic type of UCS)
4)Mtext width
5)Dimension block name
6) Imagedef, 280
7) Dims (dxf 10,13,14,50)
-
..... The rest look a bit like I need to listen to Kerry and study up.
....
I'll have a look at that in a couple of days when I put some fires out ...
I'm pleased that you realised I wasn't being antagonistic with that comment Bryco.
Regarding samples and doc's.
It's my understanding that AutoDesk will be having a push with samples and documentation in the forseeable future.
In the mean time there are some posters here and at the AD discussion group who are prepared to answer questions, provided the OP is NOT asking for his homework to be done.
I like a good bit of sample code as well as the next person, but I think we can't loose sight of the fact that NET and it's languages require an understanding of a different set of concepts to the ones we're used to.
I believe that theSwamp members can contribute in a tangible manner in the dissemination of valuable information ... all it takes is a little sharing of the stuff we're experimenting with.
-
Just about all those things you can do with .NET with the exception of DXF codes, but you don't need to as there are properties for just about everything.
Also, as of 2008, Wipeout is finally a fully fledged citizen.............with an API....YAY!
Oh, and RTEXT...don't know about that one. Layer filter you can do with some black magic, smoke and mirrors ;)
CLip boundaries, views, ucs's, etc. I've done.
Hope this helps.
Cheers,
Glenn.
-
Interesting discussion, thanks guys.
My experience:
Started with vba.
Figured out what a class was.
Migrated to VB6.
Figured out what a dll was.
Migrated to using com components.
Tried to migrate to C++/ObjectArx with limited success and understanding.
I switched to C# and haven't written any vb code in at least a year and a half. (except for some maintenance)
Have not looked back, hoping to never write any vb code again.
-
This was posted on the AD Discussion Group today.
I'm quoting it rather than linking as it is part of a long discussion and deserves isolating because of the validity of the statements included here.
"Tony Tanzillo" <tony.tanzillo@THE_URL_BELOW.com> wrote in message news:<5507199@discussion.autodesk.com>...
The .NET API for AutoCAD is far more powerful
than LISP or VBA/ActiveX. However that power
has a price, namely that it is far more difficult to
learn and use. It has a much steeper learning
curve, and is also far more volatile (its relatively
easy to crash AutoCAD with it) than LISP or VBA.
The more important thing is to understand that
what you are talking about when you say '.NET'
and developing with it, are several things, that
are all regarded as prerequisites to each other:
- Basic concepts of sofware engineering that
are not language specific (e.g., what is an
interface; What is an iterator; how to handle
exceptions; garbage collection; and so on).
- The development tools (C#, VB.NET, C++)
and IDEs - skills and experience with one
or more programming languages.
- The .NET framework, an extensive API for
general purpose development that addresses
a very broad range of needs, and which requires
years of experience in order for one to become
reasonably familiar with, and able to use.
- The AutoCAD .NET managed wrapper API
for ObjectARX.
Equally as important is the order they appear in.
They are listed in order of skills dependence, and
each one is a prerequisite to the preceeding ones,
and is the order in which one must learn them.
IOW, trying to do it backwards is just not going
to work ;)
--
http://www.caddzone.com
AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006/2007
http://www.acadxtabs.com
-
Hear hear!
-
is there anything i wont be able to do with vb2005 express that I will need to make programs for autocad with .net
-
There will be a couple of add-ons that won't work .. no biggie.
The Express Versions will service you well, even after you migrate from learning.
I thought you may try C# to make a clean transition Jeremie.
-
Yep - cut the umbilical and ditch VB :evil:
-
what is the advantage of C# over VB.net? I thought they both compiled to the same thing and that reflector or something can translate the one into the other.
Basically I want to be able to change the cct number and va load and panelboard of a receptacle. Seems like it is not exposed in vba. not sure if it is exposed in .net or not. Seems you have to pay thru the nose to do it with C++ because you can't get OMF without ADN. The more I use ABS, the less I like it. Everything is way harder than it should be. They give you a crappy program and make you pay to fix the program that they overcharged you for in the first place.
-
what is the advantage of C# over VB.net? I thought they both compiled to the same thing and that reflector or something can translate the one into the other.
It is simply personal preference. I use VB.NET and like it. I have better things to do with my time than needlessly learn a new language.
-
I have better things to do with my time than needlessly learn a new language.
VB.NET is a new language. It is not really similar to VB6 or VBA.
-
I constantly see the .NET framework and more importantly AutoCAD's .NET API put on some kind of pedestal, which is fairly undeserving.
First and foremost C# is not a tool that requires some sort of superhuman powers to be able to program in. If you are fairly competent in general programming concepts you should be able to bang out some code after spending an hour or two reviewing some tutorials to get an understanding of the syntax. Perhaps it will not be the most beautiful chunk of code floating around nor the most efficient, but it will work.
Wow, .NET has a standard library. Big deal, most modern programming languages have them. However it doesn't mean you must spend weeks/months mastering them. When you encounter a problem is the time to examine the tools to solve them, you don't examine the tools in the event that the problem may arise. I've been programming in python for several years, and am quite proficient but I can honestly say that I don't understand how to use telnetlib from the standard library. Most likely because I've never written a program that had to interface with telnet.
The .NET api is only tough for people to grasp because it is fairly new, not well documented(from what I have seen although I may be wrong) and there aren't very many tutorials online. I believe that once AutoCAD's .NET API matures you will start seeing some solid tutorials online to take some of the mystery out of the API, as you see with v/lisp and VBA.
-
I have better things to do with my time than needlessly learn a new language.
VB.NET is a new language. It is not really similar to VB6 or VBA.
VB.NET is not a new language syntax. The syntax differences are minor. It is only the useage of the .NET framework which is the big difference.
I would have wasted time learning C# syntax when I could have spent time learning the .NET framework and AutoCAD's .NET API.
-
I have better things to do with my time than needlessly learn a new language.
VB.NET is a new language. It is not really similar to VB6 or VBA.
VB.NET is not a new language syntax. The syntax differences are minor. It is only the useage of the .NET framework which is the big difference.
I would have wasted time learning C# syntax when I could have spent time learning the .NET framework and AutoCAD's .NET API.
I never claimed it was a new language syntax. The best way I can describe the differences is VB.NET is a "polished turd".
-
The best way I can describe the differences is VB.NET is a "polished turd".
Only your opinion of course.
-
the best way I can describe the differences is VB.NET is a "polished turd".
I thought in the other thread, someone said I could not polish one of those.
Now I am confused.
Also, if I can take reflector and change my vb.net code into c# code. How can one be better than the other, especially when I know most of the syntax for the one? Hard cold facts would be appreciated. Name calling does not help me make an informed choice.
-
..
Now I am confused.
...
No you're not .. don't try to trick me :-)
Whatever I say, someone is going to get their back up .. so I'll just walk away. I don't want to start a pissing contest in here.
-
basically they do both compile to IL (there 'may' be very minor differences but none that would have any real effect), the main advantage with learning C# is to learn a bit of 'C' type syntax and a more concrete OOP environment. Another good reason is that java is a snap to learn after C# and a handy language to also have under your belt.
-
The best way I can describe the differences is VB.NET is a "polished turd".
:lmao:
I agree. Only my opinion, too, of course. Of course, if VB.NET is a "polished turd", C++ must be the raw steaming version... :-D
But to give a serious answer, I simply don't like VB syntax. Some people like it because of the lack of curly braces, but it just irks me. From the DIMs to the LOOPs, I just really hate the syntax. Simply a matter of personal preference.
I've only been using C# for a couple of weeks now, but I have to admit I rather like the language. Maybe not as much as Objective-C, with its categories and protocols and message-based implementation, but it's not bad. And it's SSSOOOOO much nicer than Lisp, which is what I had been using for most of my recent coding. Haven't had enough experience with C# or MSIL to know what I think of them for commercial software development, but they work well for customizing Autocad.
"Tony Tanzillo" <tony.tanzillo@THE_URL_BELOW.com> wrote in message news:<5507199@discussion.autodesk.com>...
- Basic concepts of sofware engineering
- The development tools
- The .NET framework
- The AutoCAD .NET managed wrapper API
for ObjectARX.
Equally as important is the order they appear in....
IOW, trying to do it backwards is just not going
to work ;)
That's true. But for someone who has firm grounding in most of the concepts, the lack of examples and generally-poor state of the documentation - especially for the Civil-3D API - makes things unnecessarily difficult.
I've only been hammering through the .NET API for a couple of weeks now, but I've discovered a lot of things that were a real pain to discover, simply because of the state of the documentation. And then there are a number of things that seem like they should work, but they don't, because of something Autodesk did. And then there's the bugs, and errors in the API, of which I've already found several. So it seems like a good set of examples would serve a lot of common good...
Does anyone have interest in creating a Swamp.NET library? To see what I mean, take a look at the source code on this page (http://www.ejsurveying.com/sincpacc3d.htm). The three classes in the "AutocadUtilities" directory illustrate the beginnings of a C# Autocad .NET library. The other classes in the project implement four Autocad commands, and illustrate how the library routines are used. All of these particular routines require Civil-3D to run, but the concept holds for all Autodesk products. I know that a lot of people like to keep source code for stuff like this private, but I feel greater value can be realized by distributing it. That way, more people will understand how to create customizations, which will change people's ideas of what they can do with the product, which will result in more good ideas creeping into the public domain, which is good for all Autocad users in general.
A Swamp.NET library would serve a dual purpose - in addition to illustrating how to customize Autocad, and it would also fill in the gaps in Autodesk's API, so that not everyone would have to "reinvent the wheel" so much. That would give people more time to write the USEFUL stuff, rather than fighting through nuts-and-bolts.
At the moment, I've only implemented a small set of functionality. But eventually, it could become a relatively full-fledged library, which we could compile into a "SwampLib.DLL" for general use. Kind of an informal open-source effort, which provides useful utilities to other users, and at the same time serves as an example of how to perform various tasks. For example, since Autodesk did not expose the FeatureLine API in Civil-3D, I went to lots of extra brain-damage in order to figure out how to do basic work with FigureLines. There's no good reason that every other person who wants to customize Civil-3D FeatureLines should have to go through the same brain-damage. Instead, they could just use the CurveUtil routines from the SwampLib.
Don't know if it would be practical or not. It might only work if the library had a single person to work as "editor", otherwise it might deteriorate into chaos. That might be an awful lot of work. And we'd undoubtedly need seperate libraries, one for Vanilla and one for each vertical app, so it might require multiple "editors". Could turn into a lot of effort. But just thought I'd throw the idea out there, and see what people thought. In any case, I intend to keep posting the source code for my Civil-3D utilities on our companies web page, at least for the time being, so there's at least that much for people struggling with the Civil-3D .NET API.
-
the best way I can describe the differences is VB.NET is a "polished turd".
I thought in the other thread, someone said I could not polish one of those.
Now I am confused.
Also, if I can take reflector and change my vb.net code into c# code. How can one be better than the other, especially when I know most of the syntax for the one? Hard cold facts would be appreciated. Name calling does not help me make an informed choice.
Why don't you try a little experiment? Code up something small but useful in VB.NET, and then use Reflector to convert it to C#. Then study the C# code side-by-side with the VB code, and try to make some judgments as to which language seems more expressive to you.
-
Does anyone have interest in creating a Swamp.NET library?
I would be interested. I'm no C# programmer but if I could some of the basics behind me and actually create something useful then I'm sure my time spent learning and using C# would increase.
-
Whatever I say, someone is going to get their back up .. so I'll just walk away. I don't want to start a pissing contest in here.
That is disappointing. Yours was one of the opinions I was most hoping to hear. And I say that with all seriousness. Please do share.
-
Why don't you try a little experiment? Code up something small but useful in VB.NET, and then use Reflector to convert it to C#. Then study the C# code side-by-side with the VB code, and try to make some judgments as to which language seems more expressive to you.
On second thought, I'm not sure that's such a great idea. You would probably get C# code that employed VB coding techniques instead of more organic looking C#. It probably wouldn't be very helpful in the end. Maybe instead you could post something small, written in VB, and let one (or more) of the C# gurus rewrite it in C# for you to study. I'd be willing to convert anything sufficiently trivial, but I'm definitely not one of the most experienced C# programmers here.
By the way, Kerry thinks C# rules and VB drools. :D
-
By the way, Kerry thinks C# rules and VB drools. :D
I figured that much, I just want to know why he thinks that.
Actually Chuck, I would be interested why you chose C# over VB.net also.
-
I was hoping not to taint your thinking, but I find C# to be less verbose and more expressive than VB. You know I've done my share of VB, and I still use it from time to time, but I don't miss things like "Dim i as Integer" or "Function foo(ByRef val as Double) as Double" when I'm coding in languages with C-like syntax. I vastly prefer "Int i = 0;" and "double foo(double& val)."
I know those are only small things, but there are other little bits of syntactic sugar that, when taken in concert, make C# feel more elegant and concise than VB to me.
-
And besides, We will call you a toy programmer if you decide to go with VB. :evil:
And not just behind your back...
-
The only minor way I can see vb.net being any different to c# in what it produces (IL) would most likely be in code structure , say 'for' looping or similar and it would most likely be because of a minor difference in syntax. Any difference would be more than likely the placement of instructions and branching in IL and perhaps a hanfull of extra intructions, as mentioned you would have to try it out and see if it would have any realistic impact.
Any language that can produce IL basically uses the .net library (and others) extensively and it doesn't matter what language you use these lib's are/produce identical IL, your coding and it's structure produces the rest and in the scheme of things is a lot less code compared to what's hidden behind the scenes being used in the lib's.
I don't think it matters all that much what language you use for things like customising AutoCAD or Office software etc., most of the code is already written for you anyway.
-
And besides, We will call you a toy programmer if you decide to go with VB. :evil:
And not just behind your back...
That's alright I'll just call you elitist wankers.
-
I was hoping not to taint your thinking, but I find C# to be less verbose and more expressive than VB. You know I've done my share of VB, and I still use it from time to time, but I don't miss things like "Dim i as Integer" or "Function foo(ByRef val as Double) as Double" when I'm coding in languages with C-like syntax. I vastly prefer "Int i = 0;" and "double foo(double& val)."
I know those are only small things, but there are other little bits of syntactic sugar that, when taken in concert, make C# feel more elegant and concise than VB to me.
Learning all new syntax is quite a big undertaking. The VB.net syntax is more familiar to me already so I would have to have a good reason to make the switch. How similar is the C# syntax to C++? If they are very similar, then making the switch would be beneficial in that I would learn C++ syntax as well. That for me would be a reason to switch and might justify making the switch, because eventually I would like to learn C++. Still want to know why Kerry thinks C# is better.
Being called a toy programmer would not bother me a bit. Been one of those all my programming life. But I am also able to use my toy programming abilities to earn a living. So I like being a toy programmer.
-
Also, if I can take reflector and change my vb.net code into c# code. How can one be better than the other, especially when I know most of the syntax for the one? Hard cold facts would be appreciated. Name calling does not help me make an informed choice.
I don't see where I said C# was a better language than VB.NET. If you ask me they're both crap.
-
How similar is the C# syntax to C++? If they are very similar, then making the switch would be beneficial in that I would learn C++ syntax as well. That for me would be a reason to switch and might justify making the switch, because eventually I would like to learn C++.
This (http://www.softsteel.co.uk/tutorials/csharp/lesson2.html) may help you out.
-
Why don't you try a little experiment? Code up something small but useful in VB.NET, and then use Reflector to convert it to C#. Then study the C# code side-by-side with the VB code, and try to make some judgments as to which language seems more expressive to you.
On second thought, I'm not sure that's such a great idea. You would probably get C# code that employed VB coding techniques instead of more organic looking C#. It probably wouldn't be very helpful in the end. Maybe instead you could post something small, written in VB, and let one (or more) of the C# gurus rewrite it in C# for you to study. I'd be willing to convert anything sufficiently trivial, but I'm definitely not one of the most experienced C# programmers here.
By the way, Kerry thinks C# rules and VB drools. :D
I'd be willing to convert the application to boo (http://boo.codehaus.org/). Perhaps it may be "less verbose and more expressive" (http://boo.codehaus.org/Part+01+-+Starting+Out). :)
-
Does anyone have interest in creating a Swamp.NET library?
I would be interested. I'm no C# programmer but if I could some of the basics behind me and actually create something useful then I'm sure my time spent learning and using C# would increase.
I've been tossing this idea around for a while.
I think that a solution better suited to developing participation in the forums here would be to encourage the posting of workable self contained examples { including the includes and a list of references }. There is currently nowhere that has the same potential as this place. Having players come back to share their experiences is going to assist us all more, I'm sure, without putting the onus on one person to update a library .. as generous as that offer is !
I'd like to think that the forum could be full of "look what I did" posts rather than "I need this Help urgently" posts ... though the latter does sometimes get the juices flowing :-)
just my 2c.
-
.... Please do share.
Personally I felt inaquate seeing and typing 'Dim' so often ..
seriousy I have no cares what anyone uses, it's just that I can see the potential for a lot of grief when people try to translate vb/vba code to VB.NET. Seems more sensible to make the shift, mental and procedural ...
added:
I know that the argument can be made about translating VB/Vba to C# will be just as difficult, but at least nothing will be taken for granted, which is where I see the real problem ... assumptions are a killer.
-
Good points Kerry.
A couple of mine own:
1. More of MS's effort *appears* to be behind C# - the reason: To attract the C++ crowd.
2. Because of 1. above, C# has always had more features and 'syntactic sugar' than VB.net has - operator overloading anyone?
3. C# and VB.net certainly DO NOT compile to the same IL code in some circumstances.
4. The syntax for C# was derived from C/C++/Java, so learning it's syntax will definately help you if you want to study some of the others.
5. There are still features available only to C# - iterators and yield I believe.
I'm definately with Chuck on this one.
Cheers,
Glenn.
-
... Perhaps it may be "less verbose and more expressive" (http://boo.codehaus.org/Part+01+-+Starting+Out). :)
As the original copyright owner of that phrase, I'd be willing to license it to you for a nominal sum. :-p
-
.... Please do share.
... and this one may sound weird, but who cares ..
I find that when reading C# code the Curley braces let be breathe .. take a breath between paragraphs and sentences ... have a natural pause between thoughts. With VB I seem to be holding my breath trying to get through it.
again, my personal inadequacy :-)
-
.... Please do share.
Personally I felt inaquate seeing and typing 'Dim' so often ..
seriousy I have no cares what anyone uses, it's just that I can see the potential for a lot of grief when people try to translate vb/vba code to VB.NET. Seems more sensible to make the shift, mental and procedural ...
added:
I know that the argument can be made about translating VB/Vba to C# will be just as difficult, but at least nothing will be taken for granted, which is where I see the real problem ... assumptions are a killer.
The potential for alot of grief certainly has not been relised in my case. The only grief I have had is a lack AutoCAD .NET API documentation.
-
I'm getting really tired of the 'lack of documentation' quotes...it's all there if you want to find it and know how to interpret it - others have done it and are doing it.
-
I'm getting really tired of the 'lack of documentation' quotes...it's all there if you want to find it and know how to interpret it - others have done it and are doing it.
I am doing it. I seem to be asking for a lot less help than a lot of other people.
Compare documentation and the fact is it isn't as well documented as the other API's.
In my real experience with VB.NET the lack of documentaion has been my biggest grief but yes I can overcome it.
-
Are you talking about the VB.NET documentation itself or AutoCAD .NET documentation? As far as I'm concerned, the Microsoft Visual Studio Documentation and Platform SDK documentation are excellent.
ARX isn't as well 'documented' as the other API's in a certain lightl, because, it's an advanced topic and the docs assume an advanced level of reader from the start, if that makes sense. However, all the API calls are there and the acad .net implemenation just wraps those.
-
Are you talking about the VB.NET documentation itself or AutoCAD .NET documentation? As far as I'm concerned, the Microsoft Visual Studio Documentation and Platform SDK documentation are excellent.
ARX isn't as well 'documented' as the other API's in a certain lightl, because, it's an advanced topic and the docs assume an advanced level of reader from the start, if that makes sense. However, all the API calls are there and the acad .net implemenation just wraps those.
yes.
and this is where the topic started .. anyone aiming to develop in .NET has to do some serious study/investigation/reading/GestaltLeaps to be effective.
Cut and Paste VB/VBA code into VB.NET will not do it !
-
Are you talking about the VB.NET documentation itself or AutoCAD .NET documentation? As far as I'm concerned, the Microsoft Visual Studio Documentation and Platform SDK documentation are excellent.
ARX isn't as well 'documented' as the other API's in a certain lightl, because, it's an advanced topic and the docs assume an advanced level of reader from the start, if that makes sense. However, all the API calls are there and the acad .net implemenation just wraps those.
AutoCAD.
-
.... because eventually I would like to learn C++.
jjs
If you are planning to learn C++ eventually, you might take a look at using C++ and C++/CLR . Here you can get the most bang for the buck by being able to use either pure managed, pure unmanaged and mixed managed - unmanaged code. It’s much harder to learn and not as user friendly as C# or VB.NET but you will have the most control. I am learning both C++/CLR and C# and so far I have found it fairly easy to jump between the two.
Another great reason to learn a C dialect is it makes it much easier to understand the sample code in the ARX documentation, which can be helpful in learning the AutoCAD API.
Have fun
See http://www.theswamp.org/index.php?topic=14266.msg171894#msg171894
-
yes.
and this is where the topic started .. anyone aiming to develop in .NET has to do some serious study/investigation/reading/GestaltLeaps to be effective.
Cut and Paste VB/VBA code into VB.NET will not do it !
Agreed.
-
don't forget, there's always COM is is that going to be canned in the near future too?
-
When .NET was still relatively new, I read opinions from several well-respected members of the AutoCAD development community that all agreed that VB.NET was dissimilar enough to VB6/VBA that learning it would be akin to learning an entirely new language. Based on that presumption (which I took at face value at the time), these folks all seemed to also agree that if we were going to be learning a new language anyway, we might as well learn the one that Microsoft seemed to be pouring the bulk of their efforts into, C#. Even had I not already been drawn over to the dark side by C++ and ObjectARX, the weight of all those expert opinions probably would have convinced me to choose C# over VB.NET.
However, since I never have taken a serious look at VB.NET, I have to admit that it is possible my mentors may have overstated the differences between VB6 and VB.NET. Nathan certainly seems to think so, and I seem to recall that he is a fairly capable programmer in his own right, so I'll give him the benefit of the doubt. I bet if he ever made the switch, he'd never look back though. :-)
-
When .NET was still relatively new, I read opinions from several well-respected members of the AutoCAD development community that all agreed that VB.NET was dissimilar enough to VB6/VBA that learning it would be akin to learning an entirely new language. Based on that presumption (which I took at face value at the time), these folks all seemed to also agree that if we were going to be learning a new language anyway, we might as well learn the one that Microsoft seemed to be pouring the bulk of their efforts into, C#. Even had I not already been drawn over to the dark side by C++ and ObjectARX, the weight of all those expert opinions probably would have convinced me to choose C# over VB.NET.
However, since I never have taken a serious look at VB.NET, I have to admit that it is possible my mentors may have overstated the differences between VB6 and VB.NET. Nathan certainly seems to think so, and I seem to recall that he is a fairly capable programmer in his own right, so I'll give him the benefit of the doubt. I bet if he ever made the switch, he'd never look back though. :-)
Thanks for the kind words. I do believe in the merits of C# but have personally made an easy transition to VB.NET (understanding the AutoCAD .NET API has been a challenge) and actually like the syntax. This is why I feel strongly about personal preference.
One other thing that was touted early on in the Adesk groups was that there wouldn't be VB.NET examples. As well as that being untrue I have been able to learn from excellent C# examples by the likes of Tony Tanzillo simply by using an online code converter.
One thing Tony has pointed out in the Adesk groups and that I agree strongly with is API training. Unfortunately we have none available in Australia and I have not been able to convince the boss to send me overseas.
One of the reasons I transitioned over easily also might be because I did a 5 day VB.NET course and have bought books on VB.NET, ADO.NET and Crystal Reports for VS.NET.
-
Nathan, similar to Chuck, I'm not questioning your efficacy or aptitude.
Because most of us do learn to a degree by osmosis, the issue of samples is interesting.
I recall back in the day learning lisp, before the internet, { no laughing } I think it was easier to learn then because I had to work it out myself essentially. Currently there are examples of almost everything available on the net. The dilema facing beginners now is choosing GOOD code as a sample .. without the knowledge being discriminating is difficult.
I imagine the same thing will happen with .NET code. At this stage I think there are more examples of good C# code around than of VB.net code .. and at the risk of harping on it, while people continue to engage in cut and paste coding the situation will not improve.
2c
-
...
One thing Tony has pointed out in the Adesk groups and that I agree strongly with is API training. Unfortunately we have none available in Australia and I have not been able to convince the boss to send me overseas.
I've mentioned this to some people (who shall remain nameless) at AutoDesk. I'm hoping we get to see some videos and transcripts .. but am not holding my breath just yet. I do believe the powers that be recognise the importance of information dissemination .. but it has been difficult for them while the product has been in a state of flux.
-
After looking at net for a couple of hours, it looked a little to me like it was enough work just adding all the header stuff that I would start with vb than move to c# later as the header stuff looked so similar anyway. Instead of making a truly logical decision, I'll probably go with the C# as I've just invested $5.50 in a secondhand net book recommended by Kerry. I mean to say there's no going back after $5.50
-
hehehe
Don't blame me !
That's too much responsibility on my shoulders :-)
I hope you enjoy the trip Bryco .. I'm sure you will.
-
Daniel,
Thanks for the idea - managed C++!
I hope you have time to document your progress using this. I would be very interested as you have me thinking of doing the same thing...
-
Daniel,
Thanks for the idea - managed C++!
I hope you have time to document your progress using this. I would be very interested as you have me thinking of doing the same thing...
Its loads of fun. I have started goofing around with C++/CLR and mixing managed & unmanaged code little here. http://www.theswamp.org/index.php?topic=14124.msg170254#msg170254 But beware as this was my first attempt. :ugly:
-
Thanks,
I don't know how I missed that.
-
Good points Kerry.
A couple of mine own:
1. More of MS's effort *appears* to be behind C# - the reason: To attract the C++ crowd.
2. Because of 1. above, C# has always had more features and 'syntactic sugar' than VB.net has - operator overloading anyone?
3. C# and VB.net certainly DO NOT compile to the same IL code in some circumstances.
4. The syntax for C# was derived from C/C++/Java, so learning it's syntax will definately help you if you want to study some of the others.
5. There are still features available only to C# - iterators and yield I believe.
I'm definately with Chuck on this one.
Cheers,
Glenn.
This is the kind of info I was really looking for. Thanks Glenn
Ok, So I wasted 4 hours on VB.net training videos, plus the time it took to install VB.net. I have c# installed. Now I just need to find a source for C# syntax. Does anyone know of a good C# syntax source?
Is there a table that shows the vb syntax on one side and the c# syntax for the same thing on the other side?
VB.net :wink: C#
Dim intVar as integer :wink: Int intvar = 0;
Function foo(ByRef val as Double) as Double :wink: double foo(double& val)
I also assume C# is case sensitive. I know that will get me.
-
Jeremie,
MSDN has some pretty good resources for both VB and C# learning ..
They are in the middle of changing web sites and the new site does not have all references yet.
http://lab.msdn.microsoft.com/TryMsdn/Library.aspx?uniqueid=ms06xk7d&newpull=http%3a%2f%2fmsdn2.microsoft.com%2fen-us%2fvcsharp%2faa336809.aspx
http://blogs.msdn.com/csharpfaq/default.aspx
-
All the 'C' family of languages are case-sensitive (not 100% sure about Java) - it's one of the many reasons I like it.
-
Is there a table that shows the vb syntax on one side and the c# syntax for the same thing on the other side?
Try this
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vxgrflanguageequivalentscodeexamples.asp
I've noticed a couple of comparisons but haven't bookmarked any :-)
added : perhaps better side by side ..
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vxorilanguageequivalentskeywords.asp
-
Because most of us do learn to a degree by osmosis, the issue of samples is interesting.
I recall back in the day learning lisp, before the internet, { no laughing } I think it was easier to learn then because I had to work it out myself essentially.
Kerry, I agree 100% that learning by "figger'n it out yerself" is the best way to learn, however, one must take into consideration that many times, one is under huge time constraints to accomplish some task in order to keep employed. This makes "copy and paste" a much more attractive option, and even to a point, makes it understandable. I learned VB by buying a book, and reading and doing the examples. The book was chock full of errors, and figger'n out how to make it work like they wanted taught me FAR more than the actual text in the book did. But, I wasn't doing it for a living yet!! :lol:
Oh, I forgot to mention my point! Don't be too hard on the "copy/paste" crowd... :)
-
Heck I have copy and pasted this code so many times, I am beginning to understand it. :lol:
The great thing about slamming out code is getting to re-write it better. :-D