I'm, having a hard time wanting to help you here John, it seems that you haven't taken any time to look at the documentation...
Hey at least he's posting code, and giving it a shot. 8-)
Hey at least he's posting code, and giving it a shot. 8-)
True, but my frustration comes that instead of helping people to understand the complexities of the system and the language we're holding hands and teaching them how to walk. Most of us here have spend hundreds or thousands of hours researching and trying to reach the point where we can give the help that is provided here.
It seems to me that it's a bit of a slap in the face to come here looking for others to spell this out rather than doing some research. Especially from my own personal experience: I had been working with autocad for nearly a year before my questions were complex enough that I wasn't able to find the answer. There are not many questions which haven't already been asked right here on this board.
That said, I would argue that teaching the noobs how to answer their questions is teaching them more than just answering their questions :-D
Patience you .net-ers. I'm on chapter nine of my c# book so I will be here to help with the non-api questions soon ...I hope.
BTW, I'm not really getting a big warm fuzzy over this C# language yet (very clumsy so far).
The book is called: "Programming C#: Building .NET Applications With C#"
It's a pretty good book.
:) Yes, but the inheritance thing is killing me. The book seems to be geared more for an introduction to programming but I'm rolling with it so far. I really need to get a compiler installed so I can actually run some of this code instead of accepting it at face value but I plan on going back and re-reading and or reading another book so it's all good.
Question (off topic a little): is this kind of for statement legal in C# (the code in the OP is bothering me). -i.e. Why use a foreach when a for statement will be much cleaner.Code - C++: [Select]
for ( int i = 0, int j = 0 ; i < count ; ++i, ++j ) { // my code }
0:10
1:11
2:12
3:13
4:14
5:15
6:16
Yes, with a small change ...Code - C#: [Select]… snip
void Main() { int count = 7; for ( int i = 0, j = 10 ; i < count ; ++i, ++j ) { Console.WriteLine(i + ":" + j); } }
The book is called: "Programming C#: Building .NET Applications With C#"
It's a pretty good book.
I really need to get a compiler installed so I can actually run some of this code instead of accepting it at face value but I plan on going back and re-reading and or reading another book so it's all good.
Visual studio will make you forget about VIM :evil:
LOL! :D
Ok I will but I planned on trying MonoDevelop as well so I can be cross-platform (No MS Windows at home) so I can't promise I'll stick with Visual Studio.
Hummm… Interesting.LOL! :D
Ok I will but I planned on trying MonoDevelop as well so I can be cross-platform (No MS Windows at home) so I can't promise I'll stick with Visual Studio.
I'm using MonoDevelop in Unity. Not a bad editor .. but I prefer MSVS
-i.e. Why use a foreach when a for statement will be much cleaner.
< .. >
One last tiny pet peeve... When dealing with booleans, stop re-evaluating if they're true or false. Boolean functions are already evaluated to be either true or false, therefore a comparison is just wasted cycles.Code - C#: [Select]
// This... if (acLineTypTbl.Has(sLineTypName) == false) { acCurDb.LoadLineTypeFile(sLineTypName, "acad.lin"); } // Becomes this: if (!acLineTypTbl.Has(sLineTypName)) { acCurDb.LoadLineTypeFile(sLineTypName, "acad.lin"); }
<snippy>Find an opensource project and study the code to pick up tricks.
One of the reasons I know what I do (including some interesting genetic algorithm stuff) is from doing exactly that.
THIS. Not just for reading, but also submitting code can generate some excellent feedback, and its also excellent exposure to managed code development including using diff's, version control, and bug reporting. One of the reasons I know what I do (including some interesting genetic algorithm stuff) is from doing exactly that.
How do I create a new array with linetypes and extract data from the slayernames array into the linetypes array.
Also am I trying to do too many things inside a method. Any help would save me from spontaneous combustion.Code - C#: [Select]
[CommandMethod("assignlinetype")] public static void assignlinetype() { Document acDoc = Application.DocumentManager.MdiActiveDocument; Database acCurDb = acDoc.Database; using (Transaction acTrans = acCurDb.TransactionManager.StartTransaction()) { LayerTable acLyrTbl; acLyrTbl = acTrans.GetObject(acCurDb.LayerTableId, OpenMode.ForRead) as LayerTable; LinetypTable acLineTbl; acLineTbl = acTrans.GetObject(acCurDb.LinetypeTableId, OpenMode.ForRead) as LinetypeTable; acLinetypes[0] = "hidden10" acLinetypes[1] = "center10" acLinetypes[2] = "dot10" foreach (string linetype in acLinetypes) if (acLineTypTbl.Has(sLineTypName) == false) { acCurDb.LoadLineTypeFile(sLineTypName, "acad.lin"); } // how do I error handle this if true??? sLayerNames[0] = "ACIRed"; sLayerNames[1] = "TrueBlue"; sLayerNames[2] = "ColorBookYellow"; acColors[0] = Color.FromColorIndex(ColorMethod.ByAci, 1); acColors[1] = Color.FromColorIndex(ColorMethod.ByAci, 1); acColors[2] = Color.FromColorIndex(ColorMethod.ByAci, 1); // can I have an array here that references linetypes to the layers? int nCnt = 0; foreach (string sLayerName in sLayerNames) { if (acLyrTbl.Has(sLayerName) == false) { { acLyrTblRec.Name = sLayerName; if (acLyrTbl.IsWriteEnabled == false) acLyrTbl.UpgradeOpen(); acLyrTbl.Add(acLyrTblRec); acTrans.AddNewlyCreatedDBObject(acLyrTblRec, true); acLyrTblRec.Color = acColors[nCnt]; // should there be a linetype reference here ? } } else { LayerTableRecord acLyrTblRec = acTrans.GetObject(acLyrTbl[sLayerName], OpenMode.ForWrite) as LayerTableRecord; acLyrTblRec.Color = acColors[nCnt]; // should there be a linetype reference here do I load the linetype table record for write now ? } nCnt = nCnt + 1; } acTrans.Commit(); } }
THIS. Not just for reading, but also submitting code can generate some excellent feedback, and its also excellent exposure to managed code development including using diff's, version control, and bug reporting. One of the reasons I know what I do (including some interesting genetic algorithm stuff) is from doing exactly that.
Is interesting to see that on all your posts, there is no code sample or even partial chunks it is added, as a complement, is there any code around, that we/or me can have a look, in case there is something, please post the url link(s) ?
Thanks, LE!
RE: For-Foreach:
That is interesting. However, I find it a little funny that the author uses post-incriment while talking about micro-benchmarking; in C++ there can be a lot of extra cost to post-incriment so I've got in the habit of using pre-incriment at all costs. Of course the overhead is negligible for built in types like INT, FLOAT and such but custom classes and whatnot…well, that's a funny mistake as long as its in someone else's code.
Off to read the others now.
...when it comes to ownership/conflict of interest I draw the line a little tighter than most, paid work comes first,
If I may stray off topic a tad for a sec, it's still relevant in most respects though (to people new to C#/.net).
Hi John,
Inheritance and polymorphism is over emphasised in learning literature IMO, when learning it's very easy to get caught up inheriting from everything to keep things DRY, this is bad as it creates very tightly coupled code that makes your libraries almost useless for any other applications. If you are trying to write unit/integration tests for existing code you will quickly learn why inheritance can be overused very easily.
The less talked about paradigm is Interfaces, these are what make things like the 'foreach' statement very powerful. By using the ICollection interface and overriding the necessary methods you can create your own collection types that can be iterated using foreach.
It's taken me a while but I've finally got my head around unit testing and it was interfaces that provided the 'aha!' moment, by creating your own interfaces you are creating an api that you can then plug your inherited classes into as dependencies. Test driven development pretty much enforces this style of architecture and well worth investigating once you get the language basic down.
Windows .Net loves you to inherit from their classes as it ties you tightly to the technology, I don't think this was deliberate but it does make things easy when creating user controls etc. By using interfaces though you can then separate the internal logic of your custom control behavior from the api and reuse it in other platforms (think gaming or web tech).
Check out some vid's/books from Robert C. Martin (Uncle Bob) on S.O.L.I.D design, well worth a look.
+-->Human---+--->Employee--+-->Abused--+--->Intern
| | | |
| | | +--->Drafter
| | | |
| | | +--->Designer
| | |
| | +--------------->Engineer
| | |
Alive--+ +--->Client |
| |
+-->Animal------>Dog-------+--------------->Boss
<snip>I think I understand but I know I have to get on this topic right away. I like this already.
A good example of this is something like the ActiveRecords or PDO database api's, they have a simple connection method that is used to connect to any db by using an interface to abstract the actual connection details away. You could do this with inheritance but that would means all the different companies would need to agree on the abstract base class and methods they would all need to use. By using an interface you can change the underlying database connection details without breaking all of the legacy code that uses the connection api. This is a good separation of concerns if you will and TDD pretty much enforces you to code this way.
So now you're thinking "that's more than double the code I really need to write my app" and this may be true at the start but remember some important points:
- you only write code you need, you don't go off writing stuff you think you may need but never use
- you change only the implementation details, not the api
- you have a much better and maintainable architecture, the tests serve as excellent documentation as well
- you run your tests continually throughout your dev process catching bugs as you go
- the tests provide an exact location of a problem when a test fails, setting break points and stepping through code is seldom done.
- all of your testing is automated saving you many more hours debugging than it took to write the tests (this is key!)
- you will have the confidence to change things any time you like as any bugs are quickly found and extra new tests may need to be written and the problem easily fixed.
It's a big topic but well worth the effort I think.
This is a good separation of concerns if you will and TDD pretty much enforces you to code this way.
Quote from: Micky DThis is a good separation of concerns if you will and TDD pretty much enforces you to code this way.
Have you had any joy Testing with AutoCAD Mick ??
If so I'll fly down and talk to you. ( I'll bring some longnecks.)