GP project setup utility?

[Not Really Me]

VB experts of the net,

I need an in-house app to set up a new project space. These projects are
primarily Word docs, with a few misc. file types (binary). I have a Master
set that spans 5 folders in two levels. I want to make a copy of it into a
new folder and do a general file rename to insert the project name at the
same time. I will also modify and/or set summary and custom properties on
the word files.

First if you know of something similar please let me know. I have no need
to reinvent this wheel if it already exists. Second, I can't claim to be a
VB expert. Barely a beginner. I am much more comfortable in embedded C and
asm, but I'm willing to try. So, is VB a good language choice for this? I
mostly use VB6, but I suppose I could learn .net instead. Should I? Is a
..net variant
easier to use? (I have the 2003 version already, but do not use it). I
already have working code to handle the properties stuff in VB6, so that is
not an issue.

Here's a typical Master folder layout:

Documents
|______Checklists
|______ Reviews
|______ Misc
|______ Other

The names are irrelevant. Each folder including the Documents contains 2-20
word files. The name formats are not completely fixed, but this is
representative of those in use. The xxxx will be the new project ID.

Reqs-xxxx.doc
Reqs-xxxx-ab.doc

Ideally for every .doc file in the top level folder. I would like to
generate a file in the Reviews folder with a constant string preceeding the
name. I.e., if after the initial copy from master to target folder, the top
level contains project.doc, a default pre-defined file would be copied to
the Reviews folder with the name REV-project.doc.

Comments, suggestions?

Scott

 

[Cor Ligthert[MVP]]

Scott,

I gave you already my arguments why a VB version later then VB6.
As you want that with the chance that I misunderstand you, I would in your
case first look what the following controls can do for me


OpenFileDialog
SaveFileDialog
FolderBrowserDialog (this one has a bug in 2003 with filenames larger then I
thought 100 characters)

This is simple dragging from the toolbox in a form and the objects will be
made global to the form.

You can however as well do it yourself by using a TreeView and a ListView
The classes that you then can use are the FileInfo and the DirectoryInfo
Class

There even is a sample for that
http://www.microsoft.com/downloads/...4A-881B-4206-AA0B-C2E09DCD1D2F&displaylang=en

I give you a second link, as you write in the search class as well you have
the most change to find it easy on MSDN
http://msdn.microsoft.com/en-us/library/system.io.directoryinfo(VS.85).aspx

Cor

 

[Michael Williams]

I gave you already my arguments why a VB version later
then VB6. As you want that with the chance that I
misunderstand you, I would in your case first look what
the following controls can do for me

Welcome to the dotnet puzzle page. Rearrange the above random characters
into a well know phrase or saying. Asnwers on a postcard please to . . . . .

 

[Harry Strybos]

Welcome to the dotnet puzzle page. Rearrange the above random characters
into a well know phrase or saying. Asnwers on a postcard please to . . . .
.

Michael, I fail to understand why you want to attack Cor Ligthert. At the
end of the day, what is acheived by this?
Cor helps anybody, anywhere. This person should be praised for this.

I, like you, was also a VB.Classic alcholic. My ranting and raving over what
MS had done to us was, at least, vitriolic. Then, one day, a good mate got
me started on VB.Net. While I admit the initial incantations were somewhat
obscure, it took little time to gain an increasing fondness for the .Net
paradigm.

Currently I support both VB6 and VB.Net applications, and let me assure you,
VB.Net is much more powerful and much easire to support, particullarly in
new projects. While many VB.Classic programmers still have investment in
their code base, there are many upgrade paths to move towards VB.Net. As was
mentioned, you can still utilise your old ActveX dlls until you have time to
upgrade them.

Yeah, I know, much bigger runtime etc, but with a huge amount of extra
functionality. I am currently very involved in the Web Service paradigm, and
with VB.Net, what a breeze!

In our company, we routinely put 500gig drives and 4meg of ram into pcs.
C.mon, Michael, within a couple of years, this will be considered small!

It ain't about hardware, development software or MS, it is about fear of
change!

Have a good one

Harry

 

[Clive Lumb]

VB experts of the net,

I need an in-house app to set up a new project space. These projects are
primarily Word docs, with a few misc. file types (binary). I have a
Master
set that spans 5 folders in two levels. I want to make a copy of it into
a
new folder and do a general file rename to insert the project name at the
same time. I will also modify and/or set summary and custom properties on
the word files.

First if you know of something similar please let me know. I have no need
to reinvent this wheel if it already exists. Second, I can't claim to be
a
VB expert. Barely a beginner. I am much more comfortable in embedded C
and
asm, but I'm willing to try. So, is VB a good language choice for this?
I
mostly use VB6, but I suppose I could learn .net instead. Should I? Is a
.net variant
easier to use? (I have the 2003 version already, but do not use it). I
already have working code to handle the properties stuff in VB6, so that
is
not an issue.

Here's a typical Master folder layout:

Documents
|______Checklists
|______ Reviews
|______ Misc
|______ Other

The names are irrelevant. Each folder including the Documents contains
2-20
word files. The name formats are not completely fixed, but this is
representative of those in use. The xxxx will be the new project ID.

Reqs-xxxx.doc
Reqs-xxxx-ab.doc

Ideally for every .doc file in the top level folder. I would like to
generate a file in the Reviews folder with a constant string preceeding
the
name. I.e., if after the initial copy from master to target folder, the
top
level contains project.doc, a default pre-defined file would be copied to
the Reviews folder with the name REV-project.doc.

Comments, suggestions?

Scott

Hi Scott,
Although some might think this problem quite trivial, I have done similar
things in the past using various methods and I can assure you that getting
it right is quite difficult. You have to idiot-proof each and every
operation, use pre-flight checks and provide a rollback method.
Real-world users tend to forget files, leave them open in Word/Excel, give
them the wrong name and put them in the wrong place.

On the plus side VB (6 or .net) can do all you that you can imagine (and
more) so it might be worthwhile taking the time to study up on it.

You will need to look at folder/file browsing (to choose your start point),
recursive directory exploration (to populate the list of all files to deal
with), treeviews (to show the structure/files) and filesystem operations (to
do the copying, renaming).

Remember that if it fails in the middle of an operation you will need to
roll back, so copy files rather than move them, then delete the source when
you are happy with the result.

 

[Michael Williams]

Michael, I fail to understand why you want to attack
Cor Ligthert. At the end of the day, what is acheived
by this?

Cor Ligthert has for some time been deliberately annoying people in the
classic VB group by pestering us with his dotnet evangelism at every
opportunity. He even posts code samples in response to VB6 questions that
simply do not work in VB6 because they are VB.Net examples. He is attempting
to disrupt the classic VB group by deliberately and repeatedly annoying the
people who use it, . I've already told him that if he stops annoying me, and
if he stops annoying others on the classic VB group, then I will imediately
stop retaliating. So, the matter is in his hands.

Currently I support both VB6 and VB.Net applications,
and let me assure you, VB.Net is much more powerful
and much . . .

.. . . and you are now doing the same as Ligthert is doing, except that he is
doing it on the classic VB group in a deliberate attempt to disrupt it.
People who use classic VB (VB6 and previous versions) have a right to
continue to do so for as long as they wish and for as long as the
applications they write will actually work on the machines for which they
are targetting them. It is not your position to lecture them on what you
think they should be doing. The people who currently use VB6 will decide for
themselves when they think it is time for them to move, and when they do so
they will consider whatever alternative programming tools they wish to
consider, whether they are a product of Micro$oft or not. Do not attempt to
lecture those people on what you personally think they should do. It is none
of your business.

Mike

 

[Not Really Me]

Hi Scott,
Although some might think this problem quite trivial, I have done
similar things in the past using various methods and I can assure you
that getting it right is quite difficult. You have to idiot-proof
each and every operation, use pre-flight checks and provide a
rollback method. Real-world users tend to forget files, leave them open in
Word/Excel,
give them the wrong name and put them in the wrong place.

On the plus side VB (6 or .net) can do all you that you can imagine
(and more) so it might be worthwhile taking the time to study up on
it.
You will need to look at folder/file browsing (to choose your start
point), recursive directory exploration (to populate the list of all
files to deal with), treeviews (to show the structure/files) and
filesystem operations (to do the copying, renaming).

Remember that if it fails in the middle of an operation you will need
to roll back, so copy files rather than move them, then delete the
source when you are happy with the result.

Thanks for the reply. You're one of the few to actually comment on what I'm
looking to do.
I'm not worried about roll back. This is a relatively simple folder set up
operation, so if it fails I can kill it off and try again. This is all done
manually now. I'm just looking to automate it some.

I probably should just look at the help files in msdn, but a specific
question is, can VB do the copy as an atomic operation? In other words, is
there a copyfile function, or do I have to make my own?

Can I do the rename as part of the same operation? such as copyfile( from,
to )

Scott

 

[Not Really Me]

Scott,

I gave you already my arguments why a VB version later then VB6.
As you want that with the chance that I misunderstand you, I would in
your case first look what the following controls can do for me


OpenFileDialog
SaveFileDialog
FolderBrowserDialog (this one has a bug in 2003 with filenames larger
then I thought 100 characters)

This is simple dragging from the toolbox in a form and the objects
will be made global to the form.

You can however as well do it yourself by using a TreeView and a
ListView The classes that you then can use are the FileInfo and the
DirectoryInfo Class

There even is a sample for that
http://www.microsoft.com/downloads/...4A-881B-4206-AA0B-C2E09DCD1D2F&displaylang=en

I give you a second link, as you write in the search class as well
you have the most change to find it easy on MSDN
http://msdn.microsoft.com/en-us/library/system.io.directoryinfo(VS.85).aspx

Cor

Cor,

Thanks for the original suggestion to repost here. At least I got a couple
of helpful responses. I'd recommend to MS that they kill that other
newgroup, but it would probably just chase the idiots over here.

I was absolutely appalled at the level of flame that took off from my one
post.

Scott

 

[Clive Lumb]

Thanks for the reply. You're one of the few to actually comment on what
I'm looking to do.
I'm not worried about roll back. This is a relatively simple folder set
up operation, so if it fails I can kill it off and try again. This is all
done manually now. I'm just looking to automate it some.

I probably should just look at the help files in msdn, but a specific
question is, can VB do the copy as an atomic operation? In other words,
is there a copyfile function, or do I have to make my own?

Can I do the rename as part of the same operation? such as copyfile(
from, to )

Below is a very simple example - you can do much, much more.
Notably you can use the FileInfo class that does most if it for you
Here is a good starting point
http://articles.techrepublic.com.com/5100-10878_11-6089850.html
Dim FileToCopy As String
Dim NewCopy As String

FileToCopy = "C:\test.txt"
NewCopy = "C:\NewTest.txt"

If System.IO.File.Exists(FileToCopy) = True Then
System.IO.File.Copy(FileToCopy, NewCopy)
MsgBox("File Copied")
End If

 

[Al Reid]

Thanks for the reply. You're one of the few to actually comment on what
I'm looking to do.
I'm not worried about roll back. This is a relatively simple folder set
up operation, so if it fails I can kill it off and try again. This is all
done manually now. I'm just looking to automate it some.

I probably should just look at the help files in msdn, but a specific
question is, can VB do the copy as an atomic operation? In other words,
is there a copyfile function, or do I have to make my own?

Can I do the rename as part of the same operation? such as copyfile(
from, to )

Scott

Scott,

If you decide to program in VB6 use FileCopy. If VB.Net then you can use
FileCopy or System.IO.File.Copy. In either case you can rename the file
while doing the copy operation.

 

[Harry]

Cor Ligthert has for some time been deliberately annoying people in the
classic VB group by pestering us with his dotnet evangelism at every
opportunity. He even posts code samples in response to VB6 questions that
simply do not work in VB6 because they are VB.Net examples. He is
attempting to disrupt the classic VB group by deliberately and repeatedly
annoying the people who use it, . I've already told him that if he stops
annoying me, and if he stops annoying others on the classic VB group, then
I will imediately stop retaliating. So, the matter is in his hands.


. . . and you are now doing the same as Ligthert is doing, except that he
is doing it on the classic VB group in a deliberate attempt to disrupt it.
People who use classic VB (VB6 and previous versions) have a right to
continue to do so for as long as they wish and for as long as the
applications they write will actually work on the machines for which they
are targetting them. It is not your position to lecture them on what you
think they should be doing. The people who currently use VB6 will decide
for themselves when they think it is time for them to move, and when they
do so they will consider whatever alternative programming tools they wish
to consider, whether they are a product of Micro$oft or not. Do not
attempt to lecture those people on what you personally think they should
do. It is none of your business.

Mike

Sorry, Mike. Guess I better leave the lecturing up to you.