How do I get recursively adding files to work?

[tzonkov]

I am brand spanking new to C::B so take it easy.

I just installed (from binaries) the Nightly Build (Aug 11) on my XP Pro system. I don't have any of teh standard compilers installed on this system. I went and created a new empty project using the wizard but I am stuck adding files to it. I am trying to do it recursively since there are many files in many directories. The problem I see id the following:

After I select the directory to add recursively from C::B gives me a dialog box "Multiple Selection" which is empty. I assume I should see a list of all the files under the directory I selected.

Am I missing something? I hope there is a solution to this, from the site this looks like a realy decent and fast IDE.

[edit] I have also tried a couple of older nightly builds as well as RC2. All seem to run into the same problem. I am assuming it's a problem with my XP "configuration" since nobody else is complaining. I am open to ideas. Is there some XP service that needs to be running for this to work?[/edit]

Alex

[tzonkov]

OK. I tried it on another XP machine, and it works just fine.

Anyone out there know which XP services needs to be running for the recursive file add to work?

Thanks

[Pecan]

OK. I tried it on another XP machine, and it works just fine.

Anyone out there know which XP services needs to be running for the recursive file add to work?

Thanks

Isn't that a msvcrt.dll function to enumerate the files in a directory. I.e., findfirst, findnext functions?

Check that dll. Has another dll replaced it? Has a policy been set that disallows directory or file enumeration? Is the directory or files marked hidden. Are .cpp .h files  owned by another process? Are they hidden by a policy?

Do any other programs on your system have the problem?

Just guessing....

[tzonkov]

Ok I went and got a fresh build from our IT department today to see if it fixes this problem.  Basically it's the closes thing to re-installing windows for me since this is a work laptop.

I still do not see the file list get populated. I checked msvcrt.dll and it is on this system. I have not seen similar problems with any other applications. This is getting to be very frustrating.

Any other ideas?

Thanks.

[Pecan]

I still do not see the file list get populated.
Any other ideas?

Have you tried clicking on "Wildcard Select" in the Multiple Select dialoge to see if the file type is set correctly?

[tzonkov]

There is nothing selected in "Wildcard Select".

I don't see any files listed when I first select the directory. I have verified that this works on other XP installations. But I need to make it work on this one, since this is my main development system.

Thanks for the ideas, any more? I am hoping the person who wrote this feature might be able to help...

Alex

[mandrav]

The only thing that alters the actual files list, is this piece of code:

Code (cpp) Select Expand


    while (i < array.GetCount())
    {
        // discard directories, as well as some well known SCMs control folders ;)
        // also discard C::B project files
        if (wxDirExists(array[i]) ||
            array[i].Contains(_T("\\.svn\\")) ||
            array[i].Contains(_T("/.svn/")) ||
            array[i].Contains(_T("\\CVS\\")) ||
            array[i].Contains(_T("/CVS/")) ||
            array[i].Lower().Matches(_T("*.cbp")))
        {
            array.RemoveAt(i);
        }
        else
            ++i;


As you can see, some items are discarded from the list. C::B project files, directories and files that reside under paths like /CVS/ or /.svn/.

Is your directory structure something like this?

[tzonkov]

Yes my directory structure is all under c:\CVS

That explains the blank file list dialog... what are my options?

[takeshimiya]

Yes my directory structure is all under c:\CVS

That explains the blank file list dialog... what are my options?

C:\cvs (lowercase) or c:\CBS ?

EDIT: I think this shall not be hard-coded.

[tzonkov]

I figured I can change the directory name and get it to work. I guess I can add a request to remove that harcoded filter. Since there is the wildcard filter, the hardcoded list of ommissions should not be needed any longer. Amy I correct in assuming this?

By the way thanks for the clarification and solution....

Alex

[mandrav]

I figured I can change the directory name and get it to work. I guess I can add a request to remove that harcoded filter. Since there is the wildcard filter, the hardcoded list of ommissions should not be needed any longer. Amy I correct in assuming this?

No. Using a directory named "CVS" is bad practice. You should avoid that at all costs. It can make cvs (the program) behave badly. If you still want to use it, rename it to something else like "CVS_files", for example...

[mandrav]

EDIT: I think this shall not be hard-coded.

This will always be hardcoded, Takeshi.
These are well known directories used by well-known SCMs (at least in the open source world). If you want, disable this filtering code and try adding multiple files from a directory which is under revision control by either svn or cvs (especially the last). You 'll be thankful C::B hides it from you all this time...

What should be added though, is a warning text in the multiple select dialog stating the fact that some files were ignored for that reason.

[takeshimiya]

EDIT: I think this shall not be hard-coded.

This will always be hardcoded, Takeshi.
These are well known directories used by well-known SCMs (at least in the open source world). If you want, disable this filtering code and try adding multiple files from a directory which is under revision control by either svn or cvs (especially the last). You 'll be thankful C::B hides it from you all this time...

I was thinking in another (way more) possibilities for not necessaringly hardcoding them, such as ".bazaar", ".anyothercontrolsystem", "_svn", ".obj", and well, you can imagine a lot more.

What should be added though, is a warning text in the multiple select dialog stating the fact that some files were ignored for that reason.

They would continue to be hard-coded, but at least it would be transparent for the user.

In general I don't consider good (but handy when time is scarce, altrough it doesn't pays in the end) hard-coding these kind of values (paths, filenames, wildcards, etc) as they change a lot in a lot of different systems.


EDIT: The point was, that with not hardcoding them, we eliminate all future possible requests for "hey please add support for x path which I use often and would like to see hidden as .svn" and "hey please remove support for CVS since in my scripts relies on it".
Well everything's fine when one can change them at runtime, but when it requieres recompilation it can become a pain, since you don't have always the code at hand.

[mandrav]

The point was, that with not hardcoding them, we eliminate all future possible requests for "hey please add support for x path which I use often and would like to see hidden as .svn" and "hey please remove support for CVS since in my scripts relies on it".

I think you 're missing the point here.
We do filter these specific values because they are very well-known. There was never the intention to make this configurable.

Maybe you want to make the C::B project/workspace extensions configurable too?

[takeshimiya]

Maybe you want to make the C::B project/workspace extensions configurable too?

Well, not configurable, but in the snippet above I can't see for example ".workspace" being filtered out (that was the point).

OT: I think I can see why the extension ".workspace" is not included, it's well-known, but it's also very common (every program seems to want it associated) so it was safer not to include.

In the snippet I'm missing also the constant for the project files (and workspaces, .layouts, and so on), and some kind of moduladirity (for reusability) like GetProjectExtensions() (including .dsw, .dsp, ...) and GetSCMCommonPaths().

But, that moduladirity is not really needed (here, in this case) if they can be either configurable, or scriptable.