Visual Basic - Re: Newbie: Saving as Word doc

Author

Re: Newbie: Saving as Word doc

Norman Yuan

2004-03-28, 9:57 pm

You could try to have WordApp open the *.txt directly without first renaming
the *.txt file as *.doc file. Word can open plain text file. Then save it as
*.doc file in Word format to destination folder. But I do not think there is
significant gain of processing time, after all, renaming file does not take
too long.

Also, in the end of your code, you may want to add: "WordApp.Quit" before
"Set WordApp=Nothing", or you could end up with hidden WordApp instance in
running in memory after you finish processing, since you did not set
WordApp.Visible to "True" when instantiating it.

"Ed" <ed_millis@removethis.hotmail.com> wrote in message
news:%23Z9OWv0EEHA.3784@TK2MSFTNGP10.phx.gbl...
> Well, my first attempt at fixing this thing didn't work, so I'm trying
> again. I've inherited a VB app that experts here say is poorly written.
I
> can believe it! Plus, I'm not real hot at programming, so I don't always
> understand exactly what's going on. This VB app opens up text files in
> Word, splits them into separate documents, and saves each new document
into
> a folder with a " .doc" extension.
>
> I have discovered that just because the new docs are saved with " .doc",
and
> Word sees and opens them just fine, they are *not* necessarily Word docs,
> with real Word formatting. This means some of my Word macros (like search
> tools, etc.) don't work because they can't "see" what they need to key off
> of.
>
> I added code to the VB app to run after the separation part is finished
that
> goes back into the folder, opens every doc, and resaves it as a Word doc.
I
> have over 12,000 docs, though, and after 30 minutes and it still wasn't
> done, I figured there had to be a better way - like get it to save as a
Word
> doc the *first* time, rather than do it again. But, like a newbie, I
don't
> know how to change the code to do that.
>
> This appears to be the current Save process:
> ' get text cut from long doc
> Set fil = fso.GetFile("c:\tempfile.txt")
> Count = Count + 1
> ' save into folder as " .doc"
> fil.Copy ("c:\TIR\" & tempfile & ".doc")
> tempfile = " "
>
> This is what I've added:
> fldr2 = "c:\TIR " & dates & "\"
> Set WordApp = CreateObject("Word.Application")
> strFName = Dir$(fldr2 & "*.*")
> Do While Len(strFName) > 0
> If StrComp(Right$(strFName, 4), ".doc", vbTextCompare) = 0 Then
> Set WordDoc = WordApp.Documents.Open(fldr2 & strFName)
> WordDoc.SaveAs FileName:=fldr2 & strFName, _
> FileFormat:=wdFormatDocument
> WordDoc.Close
> End If
> strFName = Dir$
> Loop
> Set WordDoc = Nothing
> Set WordApp = Nothing
>
> Any help merging the two processes and shortening my run time is greatly
> appreciated!
> Ed
>
>

2004-03-28, 9:58 pm

Hi, Norman.

"Norman Yuan" <normanyuan@RemoveThis.shaw.ca> wrote in message
news:QcZ8c.13443$li5.683@pd7tw3no...
> You could try to have WordApp open the *.txt directly without first
renaming
> the *.txt file as *.doc file. Word can open plain text file. Then save it
as
> *.doc file in Word format to destination folder. But I do not think there
is
> significant gain of processing time, after all, renaming file does not
take
> too long.
>
> Also, in the end of your code, you may want to add: "WordApp.Quit" before
> "Set WordApp=Nothing", or you could end up with hidden WordApp instance in
> running in memory after you finish processing, since you did not set
> WordApp.Visible to "True" when instantiating it.

If I've got it right, I'll replace ?[color=darkred]

with ?
Set WordApp = CreateObject("Word.Application")
Set WordDoc = WordApp.Documents.Open("c:\tempfile.txt")
WordDoc.SaveAs FileName:=fldr2 & strFName, _
FileFormat:=wdFormatDocument
WordDoc.Close
tempfile = " "

And end with ?
WordApp.Quit
Set WordDoc = Nothing
Set WordApp = Nothing

Does this sound right?
Ed

Jeff Johnson [MVP: VB]

2004-03-28, 9:58 pm

"Ed" <ed_millis@removethis.hotmail.com> wrote in message
news:%23Z9OWv0EEHA.3784@TK2MSFTNGP10.phx.gbl...

> I have discovered that just because the new docs are saved with " .doc",
and
> Word sees and opens them just fine, they are *not* necessarily Word docs,
> with real Word formatting.

You can apply this logic to EVERYTHING. Extensions do not magically cause
files to become other formats, they are merely an indicator to the system
that the given file is EXPECTED to be in a particular format.

Bob Butler

2004-03-28, 9:58 pm

"Jeff Johnson [MVP: VB]" <i.get@enough.spam> wrote in message
news:eJ81hG4EEHA.2732@tk2msftngp13.phx.gbl
> "Ed" <ed_millis@removethis.hotmail.com> wrote in message
> news:%23Z9OWv0EEHA.3784@TK2MSFTNGP10.phx.gbl...
>
>
> You can apply this logic to EVERYTHING. Extensions do not magically
> cause files to become other formats, they are merely an indicator to
> the system that the given file is EXPECTED to be in a particular
> format.

with the classic example being people doing
savepicture picture1.picture, "xyzzy.ico"
and thinking they have created an icon file

for the original question I'd probably start playing with something along
these lines:
Dim oWord As Word.Application
Dim oDoc As Word.Document
Dim Count As Long
Set oWord = CreateObject("Word.Application")

Dim ff As Long
Dim sText As String
' get text cut from long doc
ff = FreeFile ' don't use the FileSystemObject from VB
Open "c:\tempfile.txt" For Binary As #ff
sText = Space$(LOF(ff))
Get #ff, , sText
Close #ff
Count = Count + 1
' save into folder as " .doc"
Set oDoc = oWord.Documents.Add
oDoc.Content.Text = sText
oDoc.SaveAs "c:\tempfile.doc" ' need to build correct path; may need to
delete file first
oDoc.Close

If oWord.Documents.Count = 0 Then oWord.Quit ' just being overly cautious
Set oWord = Nothing

--
Reply to the group so all can participate
VB.Net... just say "No"

MikeD

2004-03-28, 9:58 pm

"Ed" <ed_millis@removethis.hotmail.com> wrote in message
news:%23Z9OWv0EEHA.3784@TK2MSFTNGP10.phx.gbl...
> Well, my first attempt at fixing this thing didn't work, so I'm trying
> again. I've inherited a VB app that experts here say is poorly written.
I
> can believe it! Plus, I'm not real hot at programming, so I don't always
> understand exactly what's going on. This VB app opens up text files in
> Word, splits them into separate documents, and saves each new document
into
> a folder with a " .doc" extension.
>
> I have discovered that just because the new docs are saved with " .doc",
and
> Word sees and opens them just fine, they are *not* necessarily Word docs,
> with real Word formatting. This means some of my Word macros (like search
> tools, etc.) don't work because they can't "see" what they need to key off
> of.

This is true. Merely changing a file's extension does NOT "convert" that
file to a different format. In fact, it doesn't change the file at all. It
just means the file may be opened with a different application (and the
application has to support the file's format). What you're ending up with
is just a regular old text file that just *happens* to have a .doc
extension. Just reminiscing....in the DOS days, it was very common for text
files to have this extension (README.DOC files were *very* common).
Personally, I don't know why MS ever chose .doc as the extension for Word
document files as many other types of applications have "document" files
(fortunately, they didn't choose .dat for Access database files; that would
have REALLY fubared things).

>
> I added code to the VB app to run after the separation part is finished
that
> goes back into the folder, opens every doc, and resaves it as a Word doc.
I
> have over 12,000 docs, though, and after 30 minutes and it still wasn't
> done, I figured there had to be a better way - like get it to save as a
Word
> doc the *first* time, rather than do it again. But, like a newbie, I
don't
> know how to change the code to do that.
>
> This appears to be the current Save process:
> ' get text cut from long doc
> Set fil = fso.GetFile("c:\tempfile.txt")
> Count = Count + 1
> ' save into folder as " .doc"
> fil.Copy ("c:\TIR\" & tempfile & ".doc")
> tempfile = " "
>
> This is what I've added:
> fldr2 = "c:\TIR " & dates & "\"
> Set WordApp = CreateObject("Word.Application")
> strFName = Dir$(fldr2 & "*.*")
> Do While Len(strFName) > 0
> If StrComp(Right$(strFName, 4), ".doc", vbTextCompare) = 0 Then
> Set WordDoc = WordApp.Documents.Open(fldr2 & strFName)
> WordDoc.SaveAs FileName:=fldr2 & strFName, _
> FileFormat:=wdFormatDocument
> WordDoc.Close
> End If
> strFName = Dir$
> Loop
> Set WordDoc = Nothing
> Set WordApp = Nothing
>
> Any help merging the two processes and shortening my run time is greatly
> appreciated!

Well, you could get rid of the first part (which merely copies the file with
a different extension). Just open the .txt file directly, using your
Word.Application object. Other than that, there's probably not anything
different you can do to convert the text format file to a Word format file
(unless you want to get into the messy Word file format and write the file
"from scratch"). In all probability, that'd probably be considerably quicker
than using Automation with Word, but also a LOT more difficult.

Two other things that I see with your code:

1. NEVER hard-code paths.
2. You're not quitting Word. Setting the object variable for the
Word.Application object does not cause Word to quit. You need to call its
Quit method. You're closing the document and that's good, but you're not
quitting the Word application instance you've created.

Mike

2004-03-29, 10:30 am

Thanks for your input, Mike. I know there's a lot I have yet to learn, and
I appreciate the helpful souls here. Others also pointed out my Word.App
was left hanging, and it was definitely causing problems! But I have to ask
"Why?" on your other comment:
> 1. NEVER hard-code paths.
If this is only ever going to be used on my machine, and I have folders
created where they will always be, what is going on that I'm not seeing?
This is not a challenge; I'm assuming that I'm setting myself up for
something that is going to bite me hard if I keep doing this. The challenge
to me, then, will be to learn to tell the program how and where to find the
correct folder.

Ed

YYZ

2004-03-29, 3:31 pm

"Ed" <ed_millis@removethis.hotmail.com> wrote in message news:u4$##pZFEHA.3912@TK2MSFTNGP10.phx.gbl...
> Thanks for your input, Mike. I know there's a lot I have yet to learn, and
> I appreciate the helpful souls here. Others also pointed out my Word.App
> was left hanging, and it was definitely causing problems! But I have to ask
> "Why?" on your other comment:
> If this is only ever going to be used on my machine, and I have folders
> created where they will always be, what is going on that I'm not seeing?

Nothing. However, you may get lulled into using hardcoded paths, then...

> I'm assuming that I'm setting myself up for
> something that is going to bite me hard if I keep doing this.

Exactly. If you "keep doing [that]", then that means you are going to use elements of this code in other places. And in those
places, you may not know exactly where the file resides.

> The challenge
> to me, then, will be to learn to tell the program how and where to find the
> correct folder.

Exactly. I personally find that the files that I need to get to are either under app.path, or some subdirectory thereof. Or, the
user will have to browse to find the file, in which case the common dialog always tells me.

In your case, I doubt that you'll want to have to browse to the file every time you use this app, right? That would get annoying.
However, if you had to do it once, then you as the programmer store that path somewhere (registry, ini file), that wouldn't be too
bad.

Then in the future, let's say you wanted to move this file to a different place on your harddrive. If you code the logic to browse
to find a file, and the code to store that location, then you could merely find the new place that you put it, and you wouldn't have
to recompile your program.

See what I mean? (and I'm assuming MikeD was implying, but I'm not speaking for him).

There are certain things that make my "this isn't right" spot start itching. Anytime I see "C:\" or something like it, I start
itching. Anytime I start typing the same damn thing over and over again, I think there must be a way to encapsulate the
functionality and create a function that takes the few things that are different with the code as parameters.

Just my 2 cents.

Matt

2004-03-29, 5:30 pm

Thanks, Matt. I appreciate the wisdom - sounds like it was "hard won"! I
will definitely work on that!

Ed

"YYZ" <notapplicable> wrote in message
news:%23MU52XcFEHA.1240@TK2MSFTNGP10.phx.gbl...
> "Ed" <ed_millis@removethis.hotmail.com> wrote in message
news:u4$##pZFEHA.3912@TK2MSFTNGP10.phx.gbl...
and[color=darkred]
Word.App[color=darkred]
ask[color=darkred]
>
> Nothing. However, you may get lulled into using hardcoded paths, then...
>
>
> Exactly. If you "keep doing [that]", then that means you are going to use
elements of this code in other places. And in those
> places, you may not know exactly where the file resides.
>
the[color=darkred]
>
> Exactly. I personally find that the files that I need to get to are
either under app.path, or some subdirectory thereof. Or, the
> user will have to browse to find the file, in which case the common dialog
always tells me.
>
> In your case, I doubt that you'll want to have to browse to the file every
time you use this app, right? That would get annoying.
> However, if you had to do it once, then you as the programmer store that
path somewhere (registry, ini file), that wouldn't be too
> bad.
>
> Then in the future, let's say you wanted to move this file to a different
place on your harddrive. If you code the logic to browse
> to find a file, and the code to store that location, then you could merely
find the new place that you put it, and you wouldn't have
> to recompile your program.
>
> See what I mean? (and I'm assuming MikeD was implying, but I'm not
speaking for him).
>
> There are certain things that make my "this isn't right" spot start
itching. Anytime I see "C:\" or something like it, I start
> itching. Anytime I start typing the same damn thing over and over again,
I think there must be a way to encapsulate the
> functionality and create a function that takes the few things that are
different with the code as parameters.
>
> Just my 2 cents.
>
> Matt
>
>

MikeD

2004-03-29, 7:31 pm

"Ed" <ed_millis@removethis.hotmail.com> wrote in message
news:u4$%23%23pZFEHA.3912@TK2MSFTNGP10.phx.gbl...
> Thanks for your input, Mike. I know there's a lot I have yet to learn,
and
> I appreciate the helpful souls here. Others also pointed out my Word.App
> was left hanging, and it was definitely causing problems! But I have to
ask
> "Why?" on your other comment:
> If this is only ever going to be used on my machine, and I have folders
> created where they will always be, what is going on that I'm not seeing?

Nothing really, I guess, in that specific situation. I suppose that I
should have said "As a general rule, NEVER hard-code paths."

> This is not a challenge; I'm assuming that I'm setting myself up for
> something that is going to bite me hard if I keep doing this.

Precisely. Perhaps right now and for the forseeable future, you will be the
only one using this program and you're not *planning* to change your
directory structure. But things DO change. You might one day decide to
completely re-organize your hard drive(s). For anybody that considers
themself to be a "power user", this is almost inevitable every so often. I
can't tell you how many times I've done it. Even casual users, as they gain
a little more experience, think "wow, how I'm organizing things can be a lot
better". The difference is that casual users usually don't do anything about
it, whereas power users (or even semi-power users) will. In any case, if you
did re-organize your directory structure, you'd need to modify your
application accordingly. Depending on how many paths you hard-coded (and
other things; perhaps you assigned the path to a constant so you only need
to change that constant), this could be extremely easy or it could be a
nightmare. However, most every programmer will tell you it's a bad idea to
hard code paths.

> The challenge
> to me, then, will be to learn to tell the program how and where to find
the
> correct folder.

It's not really a challenge. There are a lot of things you can do. (1)
Prompt the user (in this case, you) the first time the program is run and
then save the location somewhere (the Registry, an INI file, etc.). The
next time the program is run, read the location from wherever you saved it.
Verify the folder's existance. If not found, prompt and save again (if
written correctly, you'd have a "prompting procedure" which does all this
and then you just need to call it; don't duplicate the code everywhere in
your app). (2) If the folder contains files used only by your program,
those files should probably be in the application's folder or a subfolder of
it. In that case, you can just use App.Path to get that folder, whatever it
may be, at runtime. Hard-coding just the name of a subfolder of the
application's folder is not so bad (it's hard-coded, absolute paths that are
the most troublesome).

There are 2 options for you to consider. They are many more. Be creative.

Mike

Sponsored Links