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.

--

"Cor Ligthert [MVP]" <no************ @planet.nl> wrote in message
news:Ol******** ******@TK2MSFTN GP12.phx.gbl...

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

[dfoster]

On 2005-08-21, J.S. <js*@nospam.com > wrote:

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.

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.]

"dfoster" <df*****@woofix .local.dom> wrote in message
news:sl******** ************@lo calhost.localdo main...

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/de...yResgenexe.asp

--

"J.S." <js*@nospam.com > wrote in message
news:ua******** ******@TK2MSFTN GP15.phx.gbl...

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.

[dfoster]

On 2005-08-21, Cor Ligthert [MVP] <no************ @planet.nl> wrote:

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?

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.