Author Topic: StreamReader Problem  (Read 22328 times)

0 Members and 1 Guest are viewing this topic.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: StreamReader Problem
« Reply #60 on: April 29, 2009, 10:42:20 AM »
It will be interesting to know how both of you come up with those conclusions.

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

Tuoni

  • Gator
  • Posts: 3032
  • I do stuff, and things!
Re: StreamReader Problem
« Reply #61 on: April 29, 2009, 10:43:13 AM »
 :-D

pkohut

  • Guest
Re: StreamReader Problem
« Reply #62 on: April 29, 2009, 05:16:52 PM »

I can understand your thinking here, most in this forum don't have a lot of experience with database backends,


I was trying to figure out where Mike is coming from, so I googled some past posts of his and it looks like he has a bit
of experience with database backends, ADE, and VB, and that that must be the angle.  My statement
probably isn't an accurate reflection of the group, as I had very limited experience with DB's prior to 2005.

XML seems to be everywhere, especially if you look at the consumer market and interoperability, great stuff then.  Beyond
that it's a binary world and interoperability is usually some sort of tab/comma delimited format.  Internal applications,
embedded devices, data publishing sources, legacy apps, the list is long, probably don't support XML.

Paul

Glenn R

  • Guest
Re: StreamReader Problem
« Reply #63 on: April 29, 2009, 06:00:03 PM »
XML, IMO, is the new text/csv/formatgoeshere, but I've always thought of it as an INI file on steroids. It is also becoming extremely prevalent and it does have many uses and I personally will use it in preference to the above mentioned formats, where applicable.

I do take umbrage at Mike's and to some extent Paul's, blanket comments, as I suspect Luis and Tuoni have done, about MOST not having experience with a backend data-store - this is quite simply not the case with myself or many members in this particular group.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: StreamReader Problem
« Reply #64 on: April 29, 2009, 06:04:52 PM »
Blanket use of xml for small apps / equally small data sets is akin to being invited to bring a guitar to a BBQ and showing up with a piano.

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

kdub_nz

  • Mesozoic keyThumper
  • SuperMod
  • Water Moccasin
  • Posts: 2138
  • class keyThumper<T>:ILazy<T>
Re: StreamReader Problem
« Reply #65 on: April 29, 2009, 06:08:56 PM »


Yep, just because we can doesn't mean we must ..

.. and mike, some of us can :)
Called Kerry in my other life
Retired; but they dragged me back in !

I live at UTC + 13.00

---
some people complain about loading the dishwasher.
Sometimes the question is more important than the answer.

pkohut

  • Guest
Re: StreamReader Problem
« Reply #66 on: April 29, 2009, 06:21:32 PM »
umbrage

New word, like it.

I was trying to generalize without stepping on to many toes.  Here's a buck for a shoe
shine  :angel:

Spike Wilbury

  • Guest
Re: StreamReader Problem
« Reply #67 on: April 29, 2009, 06:59:49 PM »
XML, IMO, is the new text/csv/formatgoeshere, but I've always thought of it as an INI file on steroids. It is also becoming extremely prevalent and it does have many uses and I personally will use it in preference to the above mentioned formats, where applicable.

I do take umbrage at Mike's and to some extent Paul's, blanket comments, as I suspect Luis and Tuoni have done, about MOST not having experience with a backend data-store - this is quite simply not the case with myself or many members in this particular group.

No me ofendi, para nada solo me dio curiosidad saber como llegaron a esa conclusion, lo que si el primer comentario echo por Mike es en si demasiado cruel y arrogante.

:)

Tuoni

  • Gator
  • Posts: 3032
  • I do stuff, and things!
Re: StreamReader Problem
« Reply #68 on: April 29, 2009, 07:41:33 PM »
I do take umbrage at Mike's and to some extent Paul's, blanket comments, as I suspect Luis and Tuoni have done, about MOST not having experience with a backend data-store - this is quite simply not the case with myself or many members in this particular group.
I've certainly done a little bit of backend database stuff in a couple of different DBMS'.  I think to say "most" is amusing and short-sighted, especially considering some of the posts I have seen recently on here.

pkohut

  • Guest
Re: StreamReader Problem
« Reply #69 on: April 29, 2009, 08:26:44 PM »
I do take umbrage at Mike's and to some extent Paul's, blanket comments, as I suspect Luis and Tuoni have done, about MOST not having experience with a backend data-store - this is quite simply not the case with myself or many members in this particular group.
I've certainly done a little bit of backend database stuff in a couple of different DBMS'.  I think to say "most" is amusing and short-sighted, especially considering some of the posts I have seen recently on here.

Ya, it was a bit short sighted Ed, read the followup post, I as much admitted it.

Paul

Tuoni

  • Gator
  • Posts: 3032
  • I do stuff, and things!
Re: StreamReader Problem
« Reply #70 on: April 29, 2009, 08:30:46 PM »
I do take umbrage at Mike's and to some extent Paul's, blanket comments, as I suspect Luis and Tuoni have done, about MOST not having experience with a backend data-store - this is quite simply not the case with myself or many members in this particular group.
I've certainly done a little bit of backend database stuff in a couple of different DBMS'.  I think to say "most" is amusing and short-sighted, especially considering some of the posts I have seen recently on here.
Ya, it was a bit short sighted Ed, read the followup post, I as much admitted it.

Paul
:) so I see - no problems here!  I was just justifying my previous post in terms of Glenn's.

MikeTuersley

  • Guest
Re: StreamReader Problem
« Reply #71 on: April 30, 2009, 01:02:43 AM »
I apologize if my post came across sharply, but it's accurate. "Most" don't have experience outside of their employer so they've never functioned as a professional consultant thrown into diverse environments on every new project and, therefore, forced to find/learn different methodologies. This isn't saying "Most" don't know how to handle their data within the confines they have setup, it's saying "Most" have never had to look for alternative methods so "Most" have no clue what other options are available that might better serve their purposes.

Based upon the follow up posts here, most of you have no idea what XML is or how easy it is to use. Most of you probably agree with a couple of the comments:

Quote
...have little need to share data between applications...
...not all projects require the processing and storage overhead...
...Blanket use of xml for small apps / equally small data sets is akin to being invited to bring a guitar to a BBQ and showing up with a piano....

Unfortunately, none of them are true. There is no overhead, there doesn't need to be sharing between apps, and size of app has nothing to do with whether or not to use Xml. The determining factor is how easily do you want to deal with your data? And, how much code do you want to write?

A lot of questions in this, and other, ngs are people trying to learn the various Autodesk APIs. If you discount those, the majority of the remainder are people trying to tackle problems in a linear fashion - from A to B - and they are getting stuck or hung up on things that if they were using a different approach, their problem would be removed or shifted to something simpler. Lets take this post for example:

- The OP is trying to read in points in a particular order and move forward/backwards within that order.

- Most would approach this by opening the file and reading each line within the file one at a time. If the line holds a single value, they send it to an array or collection; if the line is delimited and holds multiple values, they read the line, split it to an array and then populate a larger array/collection. Saving out the data would be the reverse of reading - reading item by item in the container object, writing to a file as a line (or concatenating into a delimited string then writing). To find an item, they will need to loop each line using a comparer to find the matching value and exit the loop when the value match is found. Moving forward/backward would require storing the current item's position within the container and add/subtract 1 to move.

- Some would follow the above scenario but use a better container object like an arraylist that has a binarysearch option to speed up the find/move functions.

- A few would use XML for the data so they could get all of the data in a useable format with 2 lines of code; saving is 1 line. Once populated, the xmldocument has functions for find, next node, previous node, etc.

- A couple would create a custom object to hold the values then use serialization to open the file and populate their object with all of the data in 4 lines of code; saving the data out is 5 lines of code. Once the data is in their object, now they can wrap the xml methods so other members of their team can use simpler calls such as MyPointList.NextPoint, or MyPointList.FindPoint(4,4,0), etc.

Instead of tackling the problem from A to B, look at it and make it easier. The last 2 options remove the problems around getting/saving the data as well as finding and moving within the data structure. IF the OP doesn't control the creation of the text/csv/ini/? input file, the problem changes focus to getting the input file into xml format. Creating an in-memory converter from original format to xml is easier for most people than dealing with the more complicated data structure that they end up creating with arrays or collections. Using other techniques such as XSLTs or CSSs would make the converter possible with 3 or 4 lines of code.

So working smarter not harder is the way to focus your energies. The best way to do this is by learning as much as possible about what is available in the .NET Framework. If I have time, I'll whip up a quick example for those of you that took umbrage to this so you can have the opportunity to see how simple Xml can be and how much time & energy it can save you.

Tuoni

  • Gator
  • Posts: 3032
  • I do stuff, and things!
Re: StreamReader Problem
« Reply #72 on: April 30, 2009, 03:00:06 AM »
I apologize if my post came across sharply, but it's accurate. "Most" don't have experience outside of their employer so they've never functioned as a professional consultant thrown into diverse environments on every new project and, therefore, forced to find/learn different methodologies. This isn't saying "Most" don't know how to handle their data within the confines they have setup, it's saying "Most" have never had to look for alternative methods so "Most" have no clue what other options are available that might better serve their purposes.
In the two and a half years I've been on here, I still wouldn't be able to say what "most" of the guys on here can do, and I think to say "most" is doing a lot of the guys on here a great disservice, as well as being wildly inaccurate and mildly amusing.

Based upon the follow up posts here, most of you have no idea what XML is or how easy it is to use.
I think you misunderstand.  It's not that "most" on here don't know what XML is (I think you'll find other people in the world may have used it too, y'know - by my count, there's at least two of us...) but that "most" on here don't believe in using one blanket solution for EVERYTHING requiring data I/O.  I could apply the same logic by recommending something such as SQlite as the backend because "I know what's best for you!"

Why use a pile driver to hammer in a 3" nail when a simple hammer will do?

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: StreamReader Problem
« Reply #73 on: April 30, 2009, 05:09:51 AM »

[selfControl=ON]

Mike, Instead of giving us a lecture MOST of us don't need, how about posting some sample code to show the OP what you have in mind.
It will probably be better received ... and you'd use less lines of code than your last post.

Regards
Kerry

[selfControl=DEFAULT]
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.

Glenn R

  • Guest
Re: StreamReader Problem
« Reply #74 on: April 30, 2009, 05:32:01 AM »
... If I have time, I'll whip up a quick example for those of you that took umbrage to this so you can have the opportunity to see how simple Xml can be and how much time & energy it can save you.

You seem to be waxing lyrical about the virtues of XML (which I admit, there are many), so please, by all means, post away old boy  :evil: