Author Topic: .NET Help  (Read 29082 times)

0 Members and 1 Guest are viewing this topic.

Glenn R

  • Guest
Re: .NET Help
« Reply #75 on: March 08, 2008, 04:05:31 PM »
Yeah, there's a lot there and elsewhere on MSDN if you can find it. I quite like Bill's presentations and there's a Soup to Nuts series for ASP as well if I remember rightly.

I went through the C# one and found it excellent for what it is. It's like all the programming books I buy, penned by different authors...in each you will find something that none of the others mention...unfortunately this leads to buying more books...which is not a bad thing in my book ;)

Cheers,
Glenn.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: .NET Help
« Reply #76 on: March 08, 2008, 04:25:13 PM »
Yep, every book has it's own pearls.

As for buying books, you're talking to a hopeless junky.

Thanks again for the vid link; awesome

:)
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

Glenn R

  • Guest
Re: .NET Help
« Reply #77 on: March 08, 2008, 04:32:23 PM »
Us junkies got to stick together ;)

Just noticed there's a WPF series there as well....there goes the download quota  :-)

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: .NET Help
« Reply #78 on: March 08, 2008, 04:34:46 PM »
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

Glenn R

  • Guest
Re: .NET Help
« Reply #79 on: March 08, 2008, 04:39:00 PM »
pretty damn cool

David Hall

  • Automatic Duh Generator
  • King Gator
  • Posts: 4075
Re: .NET Help
« Reply #80 on: March 09, 2008, 04:21:42 PM »
very cool find
Everyone has a photographic memory, Some just don't have film.
They say money can't buy happiness, but it can buy Bacon and that's a close second.
Sometimes the question is more important than the answer. (Thanks Kerry for reminding me)

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: .NET Help
« Reply #81 on: March 09, 2008, 05:35:38 PM »
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

sinc

  • Guest
Re: .NET Help
« Reply #82 on: March 12, 2008, 12:28:05 PM »
Then it's still an awful job from an architecture perspective!  :-D
I have to disagree, while the .NET api for Autocad might have its flaws here and there,
It’s very well written. (i.e. no mishmash ) … just my opinion though.  :-)
OK, that's it! You're going to have to report to the nearest GAC (good architecture center) where I will personally expose you for 48 hours to dozens of well designed API's and download 22 years of development experience into you via the new neural interface. Whooaaahahhaa (insert evil sound track here). Oh, wait, I'll have to adjust the release forms and disclaimers to exclude PTDD (post-traumatic development disorder).  :-D

Actually, the .NET API for ACAD all on its own doesn't present such a mishmash, you're right, that's only when you get into the verticals. But from dealing with SDK's and API's in the past 22 years I do have to say it's been close to the worst I've seen (there's one I worked with that was even worse, a $25.000 SDK license for a product that shall remain nameless where the docs shipped onto 17 badly photocopied sheets of paper).

I think you're still suffering from the same problem I was, in that since Autodesk has been pushing .NET for all customizations for a while now, we expect to actually get a .NET API.

And while we largely DO have a .NET API for the core product, we do NOT have one for Civil-3D.  The portion that is specific to Corridors has a managed DLL created for it, but that's about it.

For the rest of it, we are actually using the Active-X API from inside of C#.NET, which is possible, but it's ugly.  It's the basic reason we end up with all those obnoxious variants and so forth.  And of course, there is no ObjectARX documentation, either, so we are left digging through the ActiveX/VBA docs to try and figure out what we need to know, which is particularly onerous to newbies to .NET.

I heard a comment from someone at Autodesk, too, that there would not be a .NET API for C3D because "it's not necessary".  I couldn't really understand that comment, especially since other parts of the company are heavily pushing .NET, but I've stopped expecting consistency from Autodesk.

sinc

  • Guest
Re: .NET Help
« Reply #83 on: March 12, 2008, 12:41:59 PM »
In case you haven't guessed by now my preferred language for general tasks is Python. For general desktop/console apps I will use either Python or IronPython (I like System.Windows.Forms). For AutoCAD .NET extensions I use Boo exclusively but would consider VB.NET over C# if I were forced to use a MS provided .NET language.

I actually agree with you about Python and Boo.  I actually wish that C# had taken more from Python, but I would hardly call it a "horrid" language to deal with.

Personally, I've never liked VB, and do not view it's lack of curly braces as a redeeming feature for the rest of the syntax.  I'm surprised that you would say you would prefer VB over C# for such a minor reason.  But to each his own.

As far as using Boo, the problem there is that it is still a young and relatively unknown and unsupported language.  Sure, it's got its core of rabid followers, and it is powerful and has major potential, but it is not a mainstream language at this point.  And any time you choose to use a language that is not mainstream, you have to deal with additional complications, and have more-difficulty in using that language in a large development effort.  And you always run the risk that the language will NOT end up being a mainstream language at all - it may instead merely be the precursor for a not-yet-invented language that becomes the mainstream language.

For example, 15-20 years ago, there was a big debate about which one to use, C++ or Objective-C.  C++ was by-far the nastier of the two, but for various reasons we don't need to get into, it "won".  However, the entire crop of current languages - Java, C#, Python, and even Boo - took many of the ideas and principles straight from Objective-C, and all these new languages are far more like Objective-C than they are like C++.  (And to be fair, Obj-C stole many of those principles from an even-earlier language - Smalltalk.)

So although I agree with you that Boo is a "nicer" language, and undoubtedly a "better" language, I still do not agree with you that C# is "horrid".  By contrast, it is remarkably close to where Boo is at.  Boo is better in many respects, but C# is surprisingly clean, considering it was a Microsoft effort.  By contrast, take a look at C++, and then you'll see a REAL example of a "horrid" language.

And of course, it is difficult right now to get any more "mainstream" than C#, at least if you are working on Windows.  That is a significant advantage.

StefanDidak

  • Guest
Re: .NET Help
« Reply #84 on: March 12, 2008, 12:43:53 PM »
I think you're still suffering from the same problem I was, in that since Autodesk has been pushing .NET for all customizations for a while now, we expect to actually get a .NET API.

And while we largely DO have a .NET API for the core product, we do NOT have one for Civil-3D.  The portion that is specific to Corridors has a managed DLL created for it, but that's about it.

Exactly. And guess what, I've been digging in corridors for the past few days again and wondering, not just about the API design, but rather the architecture itself and the naming conventions that seem almost designed to be confusing on purpose. Wasted half the day yesterday when digging into OffsetBaseLines in a Region. Halfway through things crashed badly, rebooted the VM and thought "where was I, oh, right, OffsetBaseLines" so I ran that in the search in the CHM, got to IAeccOffsetBaseline, started casting the items in OffsetBaseLines to IAeccOffsetBaseLine to extract the data in the hierarchy below it. Only of course to discover I wasted most of the day doing that because it's IAeccBaseBaseLine, not IAeccOffsetBaseLine items in the Items! The cast survived and strangely enough all properties and collections functioned, though of course the data I was expecting was all wrong.

Spending an hour to figure out where to find a flag for a corridor that is Out-Of-Date was also a lot of fun, seeing as there isn't one. And oh, the one that really cracks me up is how you can use an empty assembly and basically hide things resulting in zero SortedStations but if applicable one or more AdditionalStations (which is odd because SortedStations returns the interval stations as well as additional stations except in these cases where the behavior becomes inconsistent).

Quote
For the rest of it, we are actually using the Active-X API from inside of C#.NET, which is possible, but it's ugly.  It's the basic reason we end up with all those obnoxious variants and so forth.  And of course, there is no ObjectARX documentation, either, so we are left digging through the ActiveX/VBA docs to try and figure out what we need to know, which is particularly onerous to newbies to .NET.

Absolutely. I'm a definite n00b when it comes to ACAD/C3D but I've been in the 3D/CGI development field for over 18 years and I've never had a harder time picking up on an SDK/API and there's been, oh, quite a few!  :-)

Quote
I heard a comment from someone at Autodesk, too, that there would not be a .NET API for C3D because "it's not necessary".  I couldn't really understand that comment, especially since other parts of the company are heavily pushing .NET, but I've stopped expecting consistency from Autodesk.

I'm with you on that one! Then again, I might be a little biased here since I contracted for Autodesk/Discreet in a distant past and have seen things from both sides of the fence.  :-)

Personally I think it's a shame to provide a .NET layer that is suffering from the things it suffers from. I can imagine that someone who has not had any .NET experience, regardless of language, gets confused, has to jump through various hoops that are possible but uncommon enough in general, and it ends up providing the perception that all this .NET stuff is too difficult, too messy, etc. when it really isn't, just the API is and the fact that you end up doing COM/AX instead of actual .NET.


sinc

  • Guest
Re: .NET Help
« Reply #85 on: March 12, 2008, 12:47:55 PM »
Personally I think it's a shame to provide a .NET layer that is suffering from the things it suffers from. I can imagine that someone who has not had any .NET experience, regardless of language, gets confused, has to jump through various hoops that are possible but uncommon enough in general, and it ends up providing the perception that all this .NET stuff is too difficult, too messy, etc. when it really isn't, just the API is and the fact that you end up doing COM/AX instead of actual .NET.

You don't even have to be new to .NET to get confused.  I think I have it down pretty well at this point, and I *still* hit times where I do something brain-dead because I forget I'm working with a mixture of .NET and COM objects.

And I think this has a large part to do with why the whole Undo/Redo mechanism seems to be so flaky with C3D.  I find myself using the StartUndoMark and EndUndoMark in everything, even if I am also using transactions, because it's the only way I know to guarantee that UNDO will work the way I want.