Author Topic: arrays  (Read 10307 times)

0 Members and 1 Guest are viewing this topic.

JONTHEPOPE

  • Guest
arrays
« on: July 25, 2014, 12:25:46 AM »

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]
  1.  
  2. [CommandMethod("assignlinetype")]
  3. public static void assignlinetype()
  4. {
  5.     Document acDoc = Application.DocumentManager.MdiActiveDocument;
  6.     Database acCurDb = acDoc.Database;
  7.  
  8.     using (Transaction acTrans = acCurDb.TransactionManager.StartTransaction())
  9.     {
  10.         LayerTable acLyrTbl;
  11.         acLyrTbl = acTrans.GetObject(acCurDb.LayerTableId,
  12.                                         OpenMode.ForRead) as LayerTable;
  13.  
  14.         LinetypTable acLineTbl;
  15.         acLineTbl = acTrans.GetObject(acCurDb.LinetypeTableId,
  16.                                         OpenMode.ForRead) as LinetypeTable;
  17.  
  18.         string[] acLinetypes = new string[3];
  19.         acLinetypes[0] = "hidden10"
  20.         acLinetypes[1] = "center10"
  21.         acLinetypes[2] = "dot10"
  22.  
  23.        foreach  (string linetype in acLinetypes)    
  24.          if (acLineTypTbl.Has(sLineTypName) == false)
  25.         {
  26.             acCurDb.LoadLineTypeFile(sLineTypName, "acad.lin");
  27.         }
  28.  
  29. // how do I error handle this if true???
  30.  
  31.         string[] sLayerNames = new string[3];
  32.         sLayerNames[0] = "ACIRed";
  33.         sLayerNames[1] = "TrueBlue";
  34.         sLayerNames[2] = "ColorBookYellow";
  35.  
  36.         Color[] acColors = new Color[3];
  37.         acColors[0] = Color.FromColorIndex(ColorMethod.ByAci, 1);
  38.         acColors[1] = Color.FromColorIndex(ColorMethod.ByAci, 1);
  39.         acColors[2] = Color.FromColorIndex(ColorMethod.ByAci, 1);
  40.  
  41. // can I have an array here that references linetypes to the layers?
  42.                                    
  43.         int nCnt = 0;
  44.  
  45.         foreach (string sLayerName in sLayerNames)
  46.         {
  47.             if (acLyrTbl.Has(sLayerName) == false)
  48.             {
  49.                 using (LayerTableRecord acLyrTblRec = new LayerTableRecord())
  50.                 {
  51.                     acLyrTblRec.Name = sLayerName;
  52.  
  53.                     if (acLyrTbl.IsWriteEnabled == false) acLyrTbl.UpgradeOpen();
  54.  
  55.                     acLyrTbl.Add(acLyrTblRec);
  56.                     acTrans.AddNewlyCreatedDBObject(acLyrTblRec, true);
  57.  
  58.                     acLyrTblRec.Color = acColors[nCnt];
  59.                  
  60.  
  61. // should there be a linetype reference here ?
  62.                      
  63.                 }
  64.             }
  65.             else
  66.             {
  67.                 LayerTableRecord acLyrTblRec = acTrans.GetObject(acLyrTbl[sLayerName],
  68.                                                                  OpenMode.ForWrite) as LayerTableRecord;
  69.  
  70.                 acLyrTblRec.Color = acColors[nCnt];
  71.  
  72. // should there be a linetype reference here do I load the linetype table record for write now ?
  73.  
  74.             }
  75.             nCnt = nCnt + 1;
  76.         }
  77.         acTrans.Commit();
  78.     }
  79. }

MexicanCustard

  • Swamp Rat
  • Posts: 705
Re: arrays
« Reply #1 on: July 28, 2014, 08:14:24 AM »
You could use a Dictionary<string,string> to map layer names to linetypes
Revit 2019, AMEP 2019 64bit Win 10

WILL HATCH

  • Bull Frog
  • Posts: 450
Re: arrays
« Reply #2 on: July 28, 2014, 05:52:56 PM »
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 to see that the LayerTableRecord has a LinetypeObjectId property which you need to set to provide your default behavior.

You could also solve this with an array of Tuple<string, int, ObjectId> to represent the layer name, color, and Id of LinetypeTableRecord since you are accessing these bits of data only once and sequentially. 

In more general terms Mr Custard is absolutely right to use the dictionary

Locke

  • Guest
Re: arrays
« Reply #3 on: July 29, 2014, 08:52:07 AM »
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-)

John, when things start to appear super complicated, it usually means there's something you're missing.  Another idea for what you're trying to accomplish is creating your own class.  Then you can just store them in a normal array/list.

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]
  1. // This...
  2. if (acLineTypTbl.Has(sLineTypName) == false)
  3. {
  4.     acCurDb.LoadLineTypeFile(sLineTypName, "acad.lin");
  5. }
  6.  
  7. // Becomes this:
  8. if (!acLineTypTbl.Has(sLineTypName))
  9. {
  10.     acCurDb.LoadLineTypeFile(sLineTypName, "acad.lin");
  11. }
  12.  

WILL HATCH

  • Bull Frog
  • Posts: 450
Re: arrays
« Reply #4 on: July 29, 2014, 01:29:02 PM »
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

JohnK

  • Administrator
  • Seagull
  • Posts: 10626
Re: arrays
« Reply #5 on: July 29, 2014, 01:48:35 PM »
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).
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

dgorsman

  • Water Moccasin
  • Posts: 2437
Re: arrays
« Reply #6 on: July 29, 2014, 02:44:13 PM »
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

Shouldn't be any problems helping noobs, but I do agree that giving a man a fish only results in him asking for tartar sauce (and breath mints).  Most of the frustration come when jumping over the underlying concepts.  In this case, the documentation for LayerTableRecord class as well as the various means of effectively managing list-type information (List, Dictionary, Collection, etc.).

Its a fine line between telling them to RTFM, and giving them complete finished code (which will likely fail on them when its copy/pasted out of context leading to more questions rather than understanding).  I usually get around that by going into Stupid Question mode ie. asking a few relevant questions which *should* prompt some research on their part, hopefully leading to learning and not just read/copy/paste.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: arrays
« Reply #7 on: July 29, 2014, 04:04:42 PM »
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).

Which book John ?

Clumsy gets better with practice ;-D
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.

JohnK

  • Administrator
  • Seagull
  • Posts: 10626
Re: arrays
« Reply #8 on: July 29, 2014, 05:50:23 PM »
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]
  1. for ( int i = 0, int j = 0 ; i < count ; ++i, ++j ) {
  2.     // my code
  3. }
  4.  
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: arrays
« Reply #9 on: July 29, 2014, 06:11:54 PM »
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]
  1. for ( int i = 0, int j = 0 ; i < count ; ++i, ++j ) {
  2.     // my code
  3. }
  4.  

Yes, with a small change ...

Code - C#: [Select]
  1. void Main()
  2. {
  3.         int count = 7;
  4.         for ( int i = 0, j = 10 ; i < count ; ++i, ++j ) {
  5.  
  6.         Console.WriteLine(i + ":" + j);
  7.         }
  8. }

Quote
0:10
1:11
2:12
3:13
4:14
5:15
6:16
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.

JohnK

  • Administrator
  • Seagull
  • Posts: 10626
Re: arrays
« Reply #10 on: July 29, 2014, 06:18:38 PM »
Yes, with a small change ...

Code - C#: [Select]
  1. void Main()
  2. {
  3.         int count = 7;
  4.         for ( int i = 0, j = 10 ; i < count ; ++i, ++j ) {
  5.  
  6.         Console.WriteLine(i + ":" + j);
  7.         }
  8. }
… snip

Oh, nice! The compiler understands what type "J" is. …that's cool. Thank you.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: arrays
« Reply #11 on: July 29, 2014, 06:19:47 PM »
The book is called: "Programming C#: Building .NET Applications With C#"
It's a pretty good book.


Jesse Liberty does a good job I think

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.



John; Have a look at Express 2013 for Windows Desktop
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
or Express 2013 for Windows, or Express 2013 for Web

Working in a decent IDE isn't a bad as you've been saying for the last 10 years ;-D

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.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: arrays
« Reply #12 on: July 29, 2014, 06:23:59 PM »

or worst case, there is a compiler installed with the .NET Framework

http://msdn.microsoft.com/en-us/library/78f4aasd.aspx
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.

Jeff H

  • Needs a day job
  • Posts: 6150
Re: arrays
« Reply #13 on: July 29, 2014, 06:25:43 PM »
Visual studio will make you forget about VIM  :evil:



JohnK

  • Administrator
  • Seagull
  • Posts: 10626
Re: arrays
« Reply #14 on: July 29, 2014, 06:26:36 PM »
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.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

JohnK

  • Administrator
  • Seagull
  • Posts: 10626
Re: arrays
« Reply #15 on: July 29, 2014, 06:27:27 PM »
Visual studio will make you forget about VIM  :evil:

I will find and hunt you down like the dog you are!
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: arrays
« Reply #16 on: July 29, 2014, 06:29:35 PM »
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
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.

JohnK

  • Administrator
  • Seagull
  • Posts: 10626
Re: arrays
« Reply #17 on: July 29, 2014, 06:43:01 PM »
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
Hummm… Interesting.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: arrays
« Reply #18 on: July 29, 2014, 06:48:09 PM »
Just realised there is another question buried in there ...
-i.e. Why use a foreach when a for statement will be much cleaner.



The foreach knows how to iterate arrays and collections without us having to do the counting to determine the index.
Personally I prefer it.

This is interesting.
http://www.dotnetperls.com/for-foreach
http://www.dotnetperls.com/foreach
http://www.dotnetperls.com/collections


« Last Edit: July 29, 2014, 06:51:16 PM by Kerry »
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.

JohnK

  • Administrator
  • Seagull
  • Posts: 10626
Re: arrays
« Reply #19 on: July 29, 2014, 06:59:57 PM »
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.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: arrays
« Reply #20 on: July 29, 2014, 07:02:30 PM »
< .. >

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]
  1. // This...
  2. if (acLineTypTbl.Has(sLineTypName) == false)
  3. {
  4.     acCurDb.LoadLineTypeFile(sLineTypName, "acad.lin");
  5. }
  6.  
  7. // Becomes this:
  8. if (!acLineTypTbl.Has(sLineTypName))
  9. {
  10.     acCurDb.LoadLineTypeFile(sLineTypName, "acad.lin");
  11. }
  12.  

Good point Parrish.
« Last Edit: July 29, 2014, 07:34:00 PM by Kerry »
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.

JONTHEPOPE

  • Guest
Re: arrays
« Reply #21 on: July 30, 2014, 01:33:29 PM »
Thanks everyone for the advice I have two books instant and c# something.
They are very cryptic and they run ahead too fast.
I am also really enjoying the disscussions on this board.
I am very much a beginner and any advice from someone experienced helps alot.

class : new class
 
« Last Edit: July 30, 2014, 01:50:31 PM by JONTHEPOPE »

JohnK

  • Administrator
  • Seagull
  • Posts: 10626
Re: arrays
« Reply #22 on: July 30, 2014, 02:32:25 PM »
Good JONTHEPOPE. Take all the advice you can get and study as much code as you can. Find an opensource project and study the code to pick up tricks.

As I said, I dont know C# yet but I have some general programming habits from my C++ I can share.

Here is my quick run through of your code.
Code - C#: [Select]
  1. foreach ( string linetype in acLinetypes ) {
  2.     // give me a space after the paren's
  3.     if ( !acLineTypTbl.Has(sLineTypName) ) {
  4.         // decide to use brackets or not. Don't mix.
  5.         // If you do decide to mix, decide upon a consistant
  6.         // method and stick to it.
  7.             acCurDb.LoadLineTypeFile(sLineTypName, "acad.lin");
  8.         }
  9. }
  10.  
  11. //
  12. // ...
  13. //
  14.  
  15. int nCnt = 0;
  16.  
  17. foreach ( string sLayerName in sLayerNames ) {
  18.     // Find a different variable name; only difference between the variable
  19.     // and the object is one letter. DO NOT DO THIS!
  20.     //
  21.     if ( !acLyrTbl.Has(sLayerName) ) {
  22.         using ( LayerTableRecord acLyrTblRec = new LayerTableRecord() ) {
  23.             acLyrTblRec.Name = sLayerName;
  24.  
  25.             if ( !acLyrTbl.IsWriteEnabled ) {
  26.                 acLyrTbl.UpgradeOpen();
  27.             }
  28.  
  29.             acLyrTbl.Add(acLyrTblRec);
  30.             acTrans.AddNewlyCreatedDBObject(acLyrTblRec, true);
  31.  
  32.             acLyrTblRec.Color = acColors[nCnt];
  33.  
  34.         }
  35.     } else {
  36.         LayerTableRecord acLyrTblRec = acTrans.GetObject(acLyrTbl[sLayerName],
  37.                                                          OpenMode.ForWrite) as LayerTableRecord;
  38.         acLyrTblRec.Color = acColors[nCnt];
  39.     }
  40.     // nCnt = nCnt + 1;
  41.     //  Don't get in the habit of doing this. The C language
  42.     //  programmers will have your hide. If all you want to do
  43.     //  is to incriment a variable use pre or post-incriment
  44.     //  and move on. This method is easier to understand at a glance
  45.     ++nCnt;
  46. }
  47.  
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

dgorsman

  • Water Moccasin
  • Posts: 2437
Re: arrays
« Reply #23 on: July 30, 2014, 03:37:15 PM »
<snippy>Find an opensource project and study the code to pick up tricks.

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.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

Locke

  • Guest
Re: arrays
« Reply #24 on: July 30, 2014, 03:42:41 PM »
One of the reasons I know what I do (including some interesting genetic algorithm stuff) is from doing exactly that.

Hmm, we may be talking soon.  I have a genetic algorithm I'm using to play battleship really well, and I need minds to bounce concepts off of.  (Genome design is what I'd like feedback on)

LE3

  • Guest
Re: arrays
« Reply #25 on: July 30, 2014, 03:53:29 PM »
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!

Jeff H

  • Needs a day job
  • Posts: 6150
Re: arrays
« Reply #26 on: July 30, 2014, 06:20:09 PM »

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]
  1.  
  2. [CommandMethod("assignlinetype")]
  3. public static void assignlinetype()
  4. {
  5.     Document acDoc = Application.DocumentManager.MdiActiveDocument;
  6.     Database acCurDb = acDoc.Database;
  7.  
  8.     using (Transaction acTrans = acCurDb.TransactionManager.StartTransaction())
  9.     {
  10.         LayerTable acLyrTbl;
  11.         acLyrTbl = acTrans.GetObject(acCurDb.LayerTableId,
  12.                                         OpenMode.ForRead) as LayerTable;
  13.  
  14.         LinetypTable acLineTbl;
  15.         acLineTbl = acTrans.GetObject(acCurDb.LinetypeTableId,
  16.                                         OpenMode.ForRead) as LinetypeTable;
  17.  
  18.         string[] acLinetypes = new string[3];
  19.         acLinetypes[0] = "hidden10"
  20.         acLinetypes[1] = "center10"
  21.         acLinetypes[2] = "dot10"
  22.  
  23.        foreach  (string linetype in acLinetypes)    
  24.          if (acLineTypTbl.Has(sLineTypName) == false)
  25.         {
  26.             acCurDb.LoadLineTypeFile(sLineTypName, "acad.lin");
  27.         }
  28.  
  29. // how do I error handle this if true???
  30.  
  31.         string[] sLayerNames = new string[3];
  32.         sLayerNames[0] = "ACIRed";
  33.         sLayerNames[1] = "TrueBlue";
  34.         sLayerNames[2] = "ColorBookYellow";
  35.  
  36.         Color[] acColors = new Color[3];
  37.         acColors[0] = Color.FromColorIndex(ColorMethod.ByAci, 1);
  38.         acColors[1] = Color.FromColorIndex(ColorMethod.ByAci, 1);
  39.         acColors[2] = Color.FromColorIndex(ColorMethod.ByAci, 1);
  40.  
  41. // can I have an array here that references linetypes to the layers?
  42.                                    
  43.         int nCnt = 0;
  44.  
  45.         foreach (string sLayerName in sLayerNames)
  46.         {
  47.             if (acLyrTbl.Has(sLayerName) == false)
  48.             {
  49.                 using (LayerTableRecord acLyrTblRec = new LayerTableRecord())
  50.                 {
  51.                     acLyrTblRec.Name = sLayerName;
  52.  
  53.                     if (acLyrTbl.IsWriteEnabled == false) acLyrTbl.UpgradeOpen();
  54.  
  55.                     acLyrTbl.Add(acLyrTblRec);
  56.                     acTrans.AddNewlyCreatedDBObject(acLyrTblRec, true);
  57.  
  58.                     acLyrTblRec.Color = acColors[nCnt];
  59.                  
  60.  
  61. // should there be a linetype reference here ?
  62.                      
  63.                 }
  64.             }
  65.             else
  66.             {
  67.                 LayerTableRecord acLyrTblRec = acTrans.GetObject(acLyrTbl[sLayerName],
  68.                                                                  OpenMode.ForWrite) as LayerTableRecord;
  69.  
  70.                 acLyrTblRec.Color = acColors[nCnt];
  71.  
  72. // should there be a linetype reference here do I load the linetype table record for write now ?
  73.  
  74.             }
  75.             nCnt = nCnt + 1;
  76.         }
  77.         acTrans.Commit();
  78.     }
  79. }

I do not understand what you are asking?
Forgot about arrays, loading linetypes, etc... what are you trying to accomplish?


dgorsman

  • Water Moccasin
  • Posts: 2437
Re: arrays
« Reply #27 on: July 30, 2014, 06:33:29 PM »
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!

The lack of detailed code comes from the usual reasons - a lot of the code is modular or specialized so its a bit of work to "dial it back" for a stand-alone sample, when it comes to ownership/conflict of interest I draw the line a little tighter than most, paid work comes first, and there are those much more qualified and have the time to detail out the examples.

As for a GA sample, the one I was learning on was in MegaMek in SourceForge.  Its in Java, but the syntax is almost identical to C#.  At some point in the distant past somebody had dropped in a GA "bot" for the game but it had little documentation.  I was interested in cleaning it up (the classic bot had/has serious performance issues) so I jumped in with both feet.  I got as far as understanding how GA's work and was doing some initial planning work when work/career took off leaving little time for non-work programming.  Not to say I haven't been looking for work applications, like command prediction (think right-click command history but in reverse).
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

MickD

  • King Gator
  • Posts: 3636
  • (x-in)->[process]->(y-out) ... simples!
Re: arrays
« Reply #28 on: July 30, 2014, 07:12:07 PM »
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.

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.

"Programming is really just the mundane aspect of expressing a solution to a problem."
- John Carmack

"Short cuts make long delays,' argued Pippin.”
- J.R.R. Tolkien

LE3

  • Guest
Re: arrays
« Reply #29 on: July 30, 2014, 09:21:45 PM »
...when it comes to ownership/conflict of interest I draw the line a little tighter than most, paid work comes first,

Thank you I was just curios, and I understand too.

JohnK

  • Administrator
  • Seagull
  • Posts: 10626
Re: arrays
« Reply #30 on: July 31, 2014, 06:06:37 AM »
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.

Hi ya Mick.
No kidding? I just got done reading a chapter on interfaces and I thought they were the dumbest thing and I told myself I will never use these because of what a PITA (pain in the…) they seemed to be. After that post though, they are defiantly worth the look. I have an idea for an api I want to test ideas out with so I will try interfaces first.

If you have any small-easy-to-chew samples of test driven development methology code I would love to read it. I was just getting into that with C++.

Done, I will check out S.O.L.I.D. I already have his page bookmarked and will start reading it while I drink my morning coffee.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

Locke

  • Guest
Re: arrays
« Reply #31 on: July 31, 2014, 11:04:48 AM »
C# in Depth by Jon Skeet is an outstanding read.  Additionally, Marc Gravell and Eric Lippert both have blogs worth following.

Jeff H

  • Needs a day job
  • Posts: 6150
Re: arrays
« Reply #32 on: July 31, 2014, 12:59:22 PM »
John,
to relate a interface to C++ would be a abstract class with all abstract members.


About every example I have seen on Inheritance is so simple that using Inheritance  just makes it more complicated and makes it hard to realize or see the benefits in it. Looking at a popular or successful open source project would probably be a much better example.

Just because something "is a" does not mean it should inherit from that object, and there is usually never that perfect abstraction that some literature tend to imply exists.

Those animal and vehicle examples just make it more confusing and give you a bad context a lot times when thinking about an actual real project.


Inheritance and polymorphism gets tightly coupled with thinking abstractly so it is usually explained with an abstraction, but to look at it for what it is helps me I think if should be used, as in what is actually happening and this is obviously not the exact way it works but thinking of inheritance as

Classes will have there properties(data) and a method table(a table that points to each of its functions defined in class)

When I inherit from class starts of with the class I inherited from and will restrict access to certain methods depending on if private, etc....
I can add new properties(data) and methods to its method table.
If a method is virtual in base class then that allows me to change the method pointed to in method table to the new class implementation.
If method is abstract then I have to provide a method for the method table to point to.
Polymorphism just means sense part of its definition is the base class I can treat it as the base class.
Will this help me or make it easier to deal with?

The main thing about Test driven development I like as Mick mentioned is way it forces you to approach project.
The traditional OOP approach of creating an abstraction I think is almost impossible without many years of experience of creating applications to be able even know how to formulate ones that will actual work and be a benefit to the project.




 
 

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: arrays
« Reply #33 on: July 31, 2014, 04:53:02 PM »

Here's a pretty good Inheritance tree you'll see fairly often.



And the derived Types from Curve;  think " .. Is a curve "



These are a little more practical than the 'typical' car class you'll see in books.
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.

MickD

  • King Gator
  • Posts: 3636
  • (x-in)->[process]->(y-out) ... simples!
Re: arrays
« Reply #34 on: July 31, 2014, 06:27:17 PM »
As JeffH was saying, there's definitely a place for inheritance and his example of member data and specific member methods still holds. Interfaces are basically a 'contract' of what an object can do or provide (such as the foreach example), what this means is that you can 'tack' on an interface and pass ANY object type that inherits that interface to a consumer of that api. This has a lot more power than polymorphism.

An interface is like a 'shim' or adapter if you will and that's why you won't see them used so much in sample code as they only confuse the issue.

@John,

I don't have anything that explains the concept at the moment, but I'll try a brief(?) description of the process.

In TDD you create your tests first for class that you want to test, you create these test methods to test your class methods and you will find that some of these methods require other objects.
To inject these dependencies that don't exist yet (you write your tests first remember) you need to create something, here's where you would use an interface.
You would then write a 'helper' or mock class that consumes your new interface and all this class does is help make the tests pass, even with BS code/data, just make it pass. You have now 'inverted' your dependency by letting the interface worry about it instead of your new class being tightly coupled to an actual object.

That sounds counter intuitive at first but you are not testing your dependencies just yet, only that the implementation details of the class you are working on behaves as expected, integration testing is when you plug it all together to test real dependencies all work together.

So, you have tested your new class and you have one or more new interfaces (apis if you will) for your dependencies, you can now create tests for the real dependency classes instead of helpers inheriting the interfaces as the api. Rinse and repeat.
This way you don't end up writing code you don't need as you are designing the api as you go and re-factoring out unused code and keeping it all DRY. It also allows you to change the implementation details without breaking anything, you could even plug in completely different dependencies as long as you implement the interface api.

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.
"Programming is really just the mundane aspect of expressing a solution to a problem."
- John Carmack

"Short cuts make long delays,' argued Pippin.”
- J.R.R. Tolkien

JohnK

  • Administrator
  • Seagull
  • Posts: 10626
Re: arrays
« Reply #35 on: July 31, 2014, 06:33:43 PM »

I hope you don't mind me giving a C++ more realistic `typical car class' example...

Code - C++: [Select]
  1. // create a base class...
  2. //
  3. class BaseClass
  4. {
  5.     long id;
  6.     std::string description
  7. public:
  8.     // default constructor
  9.     BaseClass() {
  10.         id = 0;
  11.     }
  12.  
  13.     // default destructor
  14.     virtual ~BaseClass () {}
  15.  
  16.     // =---------=
  17.     //  get'rs
  18.     // =---------=
  19.     virtual long get_id() { return id; }
  20.     virtual std::string& get_description() { return description; }
  21.  
  22.     // =---------=
  23.     //  set'rs
  24.     // =---------=
  25.     virtual bool set_id(long n) {
  26.         id = n;
  27.         if (id == n) return true;
  28.         else return false;
  29.     }
  30.     virtual bool set_description(std::string &str) {
  31.         description = str;
  32.         if (description == str) return true;
  33.         else return false;
  34.     }
  35. };
  36.  
  37. // Make some inheritance happen...
  38. //
  39. class DerivedClassOne :public BaseClass
  40. {
  41.     double Value;
  42. public:
  43.     // default constructor
  44.     DerivedClassOne() {
  45.         Value = 0;
  46.     }
  47.  
  48.     // default destructor
  49.     virtual ~DerivedClassOne () {}
  50.  
  51.     // =---------=
  52.     //  get'rs
  53.     // =---------=
  54.     virtual double get_Value() { return Value; }
  55.  
  56.     // =---------=
  57.     //  set'rs
  58.     // =---------=
  59.     virtual bool set_Value(double v) {
  60.         Value = v;
  61.         if (Value == v) return true;
  62.         else return false;
  63.     }
  64. };
  65.  
  66. // Let's make this a little more "real world" and create another
  67. // class...
  68. //
  69. class DerivedClassTwo :public DerivedClassOne
  70. {
  71.     double AnotherValue;
  72. public:
  73.     // default constructor
  74.     DerivedClassTwo() {
  75.         AnotherValue = 0;
  76.     }
  77.  
  78.     // default destructor
  79.     virtual ~DerivedClassTwo () {}
  80.  
  81.     // =---------=
  82.     //  get'rs
  83.     // =---------=
  84.     virtual double get_AnotherValue() { return AnotherValue; }
  85.  
  86.     // =---------=
  87.     //  set'rs
  88.     // =---------=
  89.     virtual bool set_AnotherValue(double v) {
  90.         AnotherValue = v;
  91.         if (AnotherValue == v) return true;
  92.         else return false;
  93.     }
  94. };
  95.  
  96. // So far everything seems neat and tidy (read: linear). Let me
  97. // demonstrate usage now...
  98. //
  99. int main(int argc, char** argv)
  100. {
  101.     DerivedClassTwo *MySuperAwesomeClass = new DerivedClassTwo();
  102.     // create an instance of "DerivedClassTwo" (the last in the
  103.     // inheritance chain) and call it "MySuperAwesomeClass".
  104.     MySuperAwesomeClass.set_id( 7 );
  105.     // Set the ID var in the BaseClass class
  106.  
  107.     std::string mySuperAwesomeClassDescriptionString( "Description String" );
  108.     MySuperAwesomeClass.set_description( mySuperAwesomeClassDescriptionString );
  109.     // Set the description var in the BaseClass class
  110.  
  111.     MySuperAwesomeClass.set_Value( 7 );
  112.     // Set the Value var in the DerivedClassOne class
  113.  
  114.     MySuperAwesomeClass.set_AnotherValue( 7 );
  115.     // Set the AnotherValue var in the DerivedClassTwo class
  116.  
  117.     // Because I inherited the public methods of DerivedClassTwo which
  118.     // inherited the public methods of DerivedClassOne which inherited
  119.     // the public methods of BaseClass I get access to ALL of their public
  120.     // methods.
  121.     //
  122.     // What causes most people confusion is that in cpp you don't have
  123.     // to implement all methods from each inherited class (and that I
  124.     // can have multiple inherited classes in each class where it can
  125.     // get messy quick).
  126.     //
  127. }
  128.  

This is the basic method to inheritance One->Two->Three->Final. In C++ confusion starts with mutiple inheritance.

Code: [Select]
       +-->Human---+--->Employee--+-->Abused--+--->Intern
       |           |              |           |
       |           |              |           +--->Drafter
       |           |              |           |
       |           |              |           +--->Designer
       |           |              |
       |           |              +--------------->Engineer
       |           |              |
Alive--+           +--->Client    |
       |                          |
       +-->Animal------>Dog-------+--------------->Boss

What I don't like about C# classes, which interfaces will give me [ :) ], is that I cannot have multiple inheritance. This is the reason my intrest was caught when I started on the interfaces chapter. I do not like some aspects of them but I will play around with them more and eventually learn more about them. :)

Kerry, That's almost exactly how I imagined the autodesk API to look like.

Thanks for the tip Locke!

Thank you Mick!
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

JohnK

  • Administrator
  • Seagull
  • Posts: 10626
Re: arrays
« Reply #36 on: July 31, 2014, 06:58:15 PM »
<snip>

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.
I think I understand but I know I have to get on this topic right away. I like this already.
TheSwamp.org (serving the CAD community since 2003)
Member location map - Add yourself

Donate to TheSwamp.org

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: arrays
« Reply #37 on: July 31, 2014, 07:19:21 PM »
Quote from: Micky D
This 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.)
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.

MickD

  • King Gator
  • Posts: 3636
  • (x-in)->[process]->(y-out) ... simples!
Re: arrays
« Reply #38 on: July 31, 2014, 07:59:05 PM »
Quote from: Micky D
This 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.)

Oooh! it's a deal :D

But... I'm in the horrible position at the moment of having written a complete application and now need to write tests for it (....doh!) so I will be doing a great deal of this very soon.

It's quite tempting and natural to use the cad api directly as it saves a lot of extra code but I've separated my code quite a bit, even to the point where I've basically wrapped the Bricscad api (the bits I need) into my own interface. I didn't want cad api code sprinkled all through 'my' application code, any cad 'adapter' code is handled by my interface which I could reuse in any other cad system if required.

I will be extracting this out to its own dll soon so I'll report when I get something set up.
Doing this will enable me to test my main application logic in the normal way in isolation and only leaves a much smaller part that requires the more difficult set up.

I need to revisit some threads here and make a start.
"Programming is really just the mundane aspect of expressing a solution to a problem."
- John Carmack

"Short cuts make long delays,' argued Pippin.”
- J.R.R. Tolkien

MickD

  • King Gator
  • Posts: 3636
  • (x-in)->[process]->(y-out) ... simples!
Re: arrays
« Reply #39 on: August 01, 2014, 06:23:02 AM »
After revisiting some threads after my other studies I come across a mention to "Automated Testing with the AutoCAD® .NET API" doc by Scott McFarlane from the AU class of 2012/13, this is exactly what I'm trying to describe, a great read.
The big point to take away here is abstracting the 'boiler plate' code away from your app code and why.
"Programming is really just the mundane aspect of expressing a solution to a problem."
- John Carmack

"Short cuts make long delays,' argued Pippin.”
- J.R.R. Tolkien