Topic: StreamReader Problem

[Glenn R]

I was thinking that one of the upcoming questions might be along these lines:

How do I link my data for a specific block in my data file to a specific block reference in a specific drawing kind of thing.
The only way I can think of doing this is by tracking drawing name and handles (or a drawing GUID instead of name) and this can be fragile.

However, having re-read some recent posts, I think I was wrong in my assumption. Wannabe is going the other way to what I was thinking - applying his data file to many drawings without any specific linkage.

[wannabe]

Cheers all for the quality feedback.

[It's Alive!]

Doing a 'While True' is never a good idea in my opinion, not the least of which is confusion.
Have a look at some of the examples I've posted using TextReader (as I suggested earlier) for a better way of using a loop to read each line from a file and breaking out when at the end.

Other than that, coming along well.

Personally, no problem with while(true) ( c++, while(1) ) and for( ; ; ) in the
right context.  The compiler optimizes the while loops to be as effecent as the for loop here, and the
intent is known.  But in Wannabe's sample, he is better served with while(coordsFile.Peek() >= 0)

Neither do I, nor do I with goto statements 

[Glenn R]

Nasty boy! Fight!

[Chuck Gabriel]

Neither do I, nor do I with goto statements 

You'll burn for that, heretic!

[Glenn R]

Next thing you know, he'll be expostulating the virtues of VB of all things!
I'm with the Chuckster - burn, baby, burn.

[Kerry]

Neither do I, nor do I with goto statements 

I'm reminded of this from 'Program Design' by Peter Juliff

[Glenn R]

hehe - good one.

[Chuck Gabriel]

Next thing you know, he'll be expostulating the virtues of VB of all things!

Touché.  I'll just go back to my hole now.

[MikeTuersley]

Each time you post these questions, the best solution is to use XML. Serialize/Deserialize removes the readers; Previous/Next Node handles the comparing; etc., etc.

Sorry, but...are you serious?  How do you suggest he get the data in XML format in the first place?
XML is not the Ron Popeil's Dice-o-matic wonder machine.

Paul

It is is most cases but most of you have no idea how to handle or maintain data. Text, CSV, etc. are vehicles of 20 years ago. Look around, everything is in XML for a reason - from AutoCAD settings to Office's new .???x file formats.

[It's Alive!]

You got me there, I didn’t even know who Ron Popeil was till I googled him 

[kdub_nz]

< ... >  but most of you have no idea how to handle or maintain data.  < ... >

well, that's just plain cruel .. 

[pkohut]

Each time you post these questions, the best solution is to use XML. Serialize/Deserialize removes the readers; Previous/Next Node handles the comparing; etc., etc.

Sorry, but...are you serious?  How do you suggest he get the data in XML format in the first place?
XML is not the Ron Popeil's Dice-o-matic wonder machine.

Paul

It is is most cases but most of you have no idea how to handle or maintain data. Text, CSV, etc. are vehicles of 20 years ago. Look around, everything is in XML for a reason - from AutoCAD settings to Office's new .???x file formats.

I can understand your thinking here, most in this forum don't have a lot of experience with database backends,
xml schema creation, and have little need to share data between applications, it's just the nature of most
AutoCAD programming projects, especially the questions seen in a forum like this.  I use a couple code generators
myself for data persistence and database work.  These save so much time and easy to extend in the future, I
absolutely love them, but not all projects require the processing and storage overhead that also comes with it.

Paul

[Spike Wilbury]

Each time you post these questions, the best solution is to use XML. Serialize/Deserialize removes the readers; Previous/Next Node handles the comparing; etc., etc.

Sorry, but...are you serious?  How do you suggest he get the data in XML format in the first place?
XML is not the Ron Popeil's Dice-o-matic wonder machine.

Paul

It is is most cases but most of you have no idea how to handle or maintain data. Text, CSV, etc. are vehicles of 20 years ago. Look around, everything is in XML for a reason - from AutoCAD settings to Office's new .???x file formats.

I can understand your thinking here, most in this forum don't have a lot of experience with database backends,
xml schema creation, and have little need to share data between applications, it's just the nature of most
AutoCAD programming projects, especially the questions seen in a forum like this.  I use a couple code generators
myself for data persistence and database work.  These save so much time and easy to extend in the future, I
absolutely love them, but not all projects require the processing and storage overhead that also comes with it.

Paul

For MikeTuersley - and - Paul

It will be interesting to know how both of you come up with those conclusions.

[Tuoni]

Each time you post these questions, the best solution is to use XML. Serialize/Deserialize removes the readers; Previous/Next Node handles the comparing; etc., etc.

Sorry, but...are you serious?  How do you suggest he get the data in XML format in the first place?
XML is not the Ron Popeil's Dice-o-matic wonder machine.

Paul

It is is most cases but most of you have no idea how to handle or maintain data. Text, CSV, etc. are vehicles of 20 years ago. Look around, everything is in XML for a reason - from AutoCAD settings to Office's new .???x file formats.

I can understand your thinking here, most in this forum don't have a lot of experience with database backends,
xml schema creation, and have little need to share data between applications, it's just the nature of most
AutoCAD programming projects, especially the questions seen in a forum like this.  I use a couple code generators
myself for data persistence and database work.  These save so much time and easy to extend in the future, I
absolutely love them, but not all projects require the processing and storage overhead that also comes with it.

Paul

For MikeTuersley - and - Paul

It will be interesting to know how both of you come up with those conclusions.

I agree.