Which is a better method to concatenate large blocks of text?

[J.S.]

In a Windows Form application, which is the better method to concatenate
large blocks of code?

1. Reading the text from text files.
2. Adding the text to the VB file itself?

Thanks!
J.S.

--

 

[Cor Ligthert [MVP]]

J.S.

In a Windows Form application, which is the better method to concatenate
large blocks of code?

Can you explain more with concatentate large blocks of code?

1. Reading the text from text files.
2. Adding the text to the VB file itself?

That depends on what you are doing, you can even add by instance adding the
text from a database.

Cor

 

[J.S.]

Can you explain more with concatentate large blocks of code?

I am trying to create a Windows application in VB 2005 beta that has a form
with some textboxes. The values entered in the textboxes are variables
which I want to integrate with some other blocks of code (which I have) to
generate code for another application. So the code thus generated would be
based on concatenating some blocks of code (say for example, ASP code) with
the variable values entered by the users. I have managed to do this two
ways - by inserting the blocks of code also in the VB file, and by pulling
the blocks of code from external text files on my computer.

My question is: which of these methods is better from a performance and
"best practices" standpoint? If I integrate all the code into the VB file
then users will just need an .exe file to work with my application. If I
pull blocks of code from external text files then I'll have to create text
files on their computers as well when my assembly is unzipped by them.

That depends on what you are doing, you can even add by instance adding
the text from a database.

You are right; a database would be a good method in many instances. In this
application, however, I'd rather use one of the above methods unless there
are significant reasons not to do so. The reason I use text files in one
method is because I don't know if I could convert the text files into some
kind of binary and still have it be read by my application.

Thanks for your help; I am a complete newbie at this.

J.S.

 

[Cor Ligthert [MVP]]

J.S.

I definitly would not do it with the exe file. If you have no problem that
the user can see the file, than probably (if I understand you well), I would
go for the XML dataset because that is terrible easy to handle.

In VB 2005 it should also be possible to use direct the datatable XML for
this

I hope this helps.

Cor

 

[J.S.]

Hi Cor,

That is exactly what I was looking for. Thanks for your kind advice.

J.S.

 

[dfoster]

I am trying to create a Windows application in VB 2005 beta that has a form
with some textboxes. The values entered in the textboxes are variables
which I want to integrate with some other blocks of code (which I have) to
generate code for another application. So the code thus generated would be
based on concatenating some blocks of code (say for example, ASP code) with
the variable values entered by the users. I have managed to do this two
ways - by inserting the blocks of code also in the VB file, and by pulling
the blocks of code from external text files on my computer.

My question is: which of these methods is better from a performance and
"best practices" standpoint? If I integrate all the code into the VB file
then users will just need an .exe file to work with my application. If I
pull blocks of code from external text files then I'll have to create text
files on their computers as well when my assembly is unzipped by them.

Performance-wise, pulling from a text file is going to be slower, but
I seriously doubt that the difference is going to be significant, so I
really wouldn't worry about that at all.

Contra Cor, I also don't like the idea of datasets for this. That's just
going to make your input files difficult to read and difficult to edit.

Also, by "inserting the blocks of code in the VB file", do you mean
defining them as strings? If so, I also don't like this idea, since
long string blocks are really hard to read.

There's the third choice here, which is to add the text files to
your project and embed them in the applicatio as embedded resources.
I'd lean towards this for a few reasons: a) they're still text files,
and so they're easy to edit, b) they're easy to version and there's no
chance of the wrong version of a text file winding up with the wrong
version of your app, c) installation stays simple since you still have
just the one exe file.

 

[Cor Ligthert [MVP]]

Contra Cor, I also don't like the idea of datasets for this. That's just

going to make your input files difficult to read and difficult to edit.

Can you explain this?

In my opinion XML datasets are extremely easy to read, to use the data and
to edit, therefore I should miss something?

Cor

 

[J.S.]

Performance-wise, pulling from a text file is going to be slower, but
I seriously doubt that the difference is going to be significant, so I
really wouldn't worry about that at all.
Thanks!

Also, by "inserting the blocks of code in the VB file", do you mean
defining them as strings? If so, I also don't like this idea, since
long string blocks are really hard to read.

Yes, that's what I meant. For example:

Textbox1.Text = "Some code" &_
"Some more code" & Var1 &_
"Lots more code" & Var2 &_
so on and so forth

There's the third choice here, which is to add the text files to
your project and embed them in the applicatio as embedded resources.
I'd lean towards this for a few reasons: a) they're still text files,
and so they're easy to edit, b) they're easy to version and there's no
chance of the wrong version of a text file winding up with the wrong
version of your app, c) installation stays simple since you still have
just the one exe file.

I have been looking at embedded resources. There I two questions I am
wondering about this:

1. Is it correct that at design-time the text files would be separate but
would be embedded into the .exe file when the assembly is built?

2. If the text files are going to remain embeddeed in the .exe and not be
unzipped then how would I change the path for the text file in my VB file?

For example, now I have something like c:\textfile.txt. If I want to read
text from an embedded text file the path must be something else since there
will be no separate textfile.txt at run-time.

Thanks,
J.S.

 

[J.S.]

I found some information about resources here:
http://msdn.microsoft.com/library/d...pgrfResourceFileGeneratorUtilityResgenexe.asp

 

[dfoster]

Can you explain this?

In my opinion XML datasets are extremely easy to read, to use the data and
to edit, therefore I should miss something?

Often that's true, but remember the OP is dealing with code blocks here.
Long bits of (presumably) VB code in text files. Text files with VB
in them are easy to edit, you just load them into an editor and you get
syntax coloring, autoindentation, maybe even some intellisense depending
on what's in the file.

Move them into a DataSet Xml file though and all that goes away.
The editor won't recognize the text file as VB, and you'll have to deal
with entities for all invalid characters. And code blocks tend to have
quite a few '>' and '<' characters in them.

 

[dfoster]

I have been looking at embedded resources. There I two questions I am
wondering about this:

1. Is it correct that at design-time the text files would be separate but
would be embedded into the .exe file when the assembly is built?
Correct.

2. If the text files are going to remain embeddeed in the .exe and not be
unzipped then how would I change the path for the text file in my VB file?

For example, now I have something like c:\textfile.txt. If I want to read
text from an embedded text file the path must be something else since there
will be no separate textfile.txt at run-time.

It depends on how you use namespaces in your app. The name of the
embedded resource is namespace/filename. In the simplest case where
everything is in a single namespace, you just call

GetManifestResourceStream(Me.GetType(), "textfile.txt")

There's a lot of sites on the Net that describe all this in detail, but
it's pretty straightforward.

 

[J.S.]

It depends on how you use namespaces in your app. The name of the

embedded resource is namespace/filename. In the simplest case where
everything is in a single namespace, you just call

GetManifestResourceStream(Me.GetType(), "textfile.txt")

There's a lot of sites on the Net that describe all this in detail, but
it's pretty straightforward.

Thanks! I appreciate your help.

J.S.

 

[Jay B. Harlow [MVP - Outlook]]

J.S.
In addition to the other comments:

It sounds like you are building some type of "Code Generator" where you have
a template & then insert "variables" into this template. Correct?

I would consider using Xml (not specifically a DataSet) to store the
"template" itself in.

Then I would use System.Xml.XPath namespace to read the "template" & the
System.CodeDom namespace to generate the source file.

In many ways using a DataSet to read the Xml file is both easier & harder
then using an XPathNavigator object (from System.Xml.XPath).

The Xml file could either define the structure of your template directly
(ala XSLT) or it could include snippets of code that you use one of the
CodeSnippet* classes to piece the pieces together. The advantage of using
Xml to define the structure directly is that you could then allow your code
generator to support languages other then VB, as the template itself would
not have any language (VB, C#) specific constructs in it, it would only have
abstract Xml constructs. The "variables" that you define would be in a
specific language, however it sounds like your user is typing the values of
these variables any way.

NOTE: I would use one of the CodeSnippet* classes to inject what the user is
entering into the generated CodeDom file...

FWIW: ASP.NET, XSD.EXE & WDSL.EXE all use the CodeDom for their code
generation. I understand that VS.NET has its own Code Serializer that may or
may not leverage the CodeDom.

Alternatively I would consider using either an XSLT to transform the
template & "variables" into a .vb file. In some ways I see XSLT as being the
"easier" but more "restrictive" approach...

Hope this helps
Jay

| In a Windows Form application, which is the better method to concatenate
| large blocks of code?
|
| 1. Reading the text from text files.
| 2. Adding the text to the VB file itself?
|
| Thanks!
| J.S.
|
| --
|
|