Feed to listbox...

[nsp]

Could it be possible to have a feature like feed to listbox from search dialog also available in those form :

• - feed listbox from listfile.
  - feed listbox from clipboard.
  - and finally start TC with a prebuilt file list using command line switch.

[ghisler(Author)]

Yes, that's already on my wish list. The main problem is that such a list may no longer be up to date, e.g. files on the list may have been deleted or renamed in the meantime...

[nsp]

... The main problem is that such a list may no longer be up to date, e.g. files on the list may have been deleted or renamed in the meantime...

This is also the case with lnk files and junction for the system when the source is deleted. For now the same problem can happen with feed to listbox or background task.

The functionality is just to have a plain flat list of full file name like for feed to listbox used to move, delete, copy, view allowing to have %P %N %S %L populated as it should and without copying in the temp folder.... If the source is not there anymore, it is detected by TC if it is a TC operation of by the called program.

Like for virtual panel a missing file icon can be shown when the list is loaded and during each refresh.

[Beano]

Yes, that's already on my wish list. The main problem is that such a list may no longer be up to date, e.g. files on the list may have been deleted or renamed in the meantime...

Just check for file existance when the list is parsed and loaded?

I know that would potentially cause a wait time (depending on the number of files) but I could live with that

Anyway, I would also love to see such a feature in a future version.

[ghisler(Author)]

ust check for file existance when the list is parsed and loaded?

That would be terribly slow with modern virus scanners and/or long lists...

[Beano]

I'm doing a similar thing in a solution I'm developing, and it's not a problem with thousands of files - even with anti-virus software installed.

[ghisler(Author)]

So what do you use to verify the existance? FindFirstfile? GetFileAtributes()?

[Beano]

It's a .NET solution - using system.io.file.exists to check for the file.

I just tried a quick'n'dirty test - made a file list containing almost 1000 existing files (placed on c: drive) and another 2000 non-existing files. Takes less than 2 secons to read the filelist, parse it and test all 3000 files and write the result to a standard listbox.

[ghisler(Author)]

There is no "exists" function in Windows API. Does anyone know what .net calls when "exists" is used?

[Beano]

I don't know what API call is used by system.io.file.exists, but apparently GetFileAttributes should be a fast method. Haven't tried it myself though

[nsp]

There is no "exists" function in Windows API. Does anyone know what .net calls when "exists" is used?

I do not know what .NET is calling but in freepascal i use sysutils.fileexists and in C i use _access io.h,

It seems that FileGetAttribute is efficient function...

[HolgerK]

<OT>
http://www.reflector.net/
Sometimes very usefull if you want to have a look behind the scene

Code: Select all

[SecuritySafeCritical]
public static bool Exists(string path)
{
    bool flag;
    try
    {
        if (path == null)
        {
            return false;
        }
        if (path.Length == 0)
        {
            return false;
        }
        path = Path.GetFullPathInternal(path);
        if ((path.Length > 0) && Path.IsDirectorySeparator(path[path.Length - 1]))
        {
            return false;
        }
        new FileIOPermission(FileIOPermissionAccess.Read, new string[] { path }, false, false).Demand();
        flag = InternalExists(path);
    }
    catch (ArgumentException)
    {
    }
    catch (NotSupportedException)
    {
    }
    catch (SecurityException)
    {
    }
    catch (IOException)
    {
    }
    catch (UnauthorizedAccessException)
    {
    }
    return flag;
}
...
...
...
[SecurityCritical]
internal static bool InternalExists(string path)
{
    Win32Native.WIN32_FILE_ATTRIBUTE_DATA data = new Win32Native.WIN32_FILE_ATTRIBUTE_DATA();
    return (((FillAttributeInfo(path, ref data, false, true) == 0) && (data.fileAttributes != -1)) && ((data.fileAttributes & 0x10) == 0));
}

Edit: Sorry, was a little bit in hurry.

Code: Select all

internal static int FillAttributeInfo(string path, ref Win32Native.WIN32_FILE_ATTRIBUTE_DATA data, bool tryagain, bool returnErrorOnNotFound)
{
    int num = 0;
    if ((Environment.OSInfo == Environment.OSName.Win95) || tryagain)
    {
        Win32Native.WIN32_FIND_DATA win_find_data = new Win32Native.WIN32_FIND_DATA();
        string fileName = path.TrimEnd(new char[] { Path.DirectorySeparatorChar, Path.AltDirectorySeparatorChar });
        int num2 = Win32Native.SetErrorMode(1);
        try
        {
            bool flag = false;
            SafeFindHandle handle = Win32Native.FindFirstFile(fileName, win_find_data);
            try
            {
                if (handle.IsInvalid)
                {
                    flag = true;
                    num = Marshal.GetLastWin32Error();
                    if ((((num == 2) || (num == 3)) || (num == 0x15)) && !returnErrorOnNotFound)
                    {
                        num = 0;
                        data.fileAttributes = -1;
                    }
                    return num;

...

// else OS != win95..
   bool flag2 = false;
    int newMode = Win32Native.SetErrorMode(1);
    try
    {
        flag2 = Win32Native.GetFileAttributesEx(path, 0, ref data);
    }
...

So FindFirstFile in Win95 and GetFileAttributesEx on newer OS.

</OT>

HTH
Holger

[ghisler(Author)]

Thanks for the info! But it's strange that FindClose isn't called, this leaks a search handle on Windows 9x...

[MVV]

Maybe SafeFindHandle type have a destructor? As described here, it is so.

Anyway I think GetFileAttributes is not slower than FindFirstFile/FindClose because it returns less data ammount and doesn't require to open search handle (maybe OS opens it internally though, don't know).

[HolgerK]

But it's strange that FindClose isn't called, this leaks a search handle on Windows 9x...

Don't worry.
I snipped away some lines of code in the quote.
Of course there is a

Code: Select all

           finally
            {
                try
                {
                    handle.Close();
                }
                ...

And even without this: SafeFindHandle is a managed object and at least the garbage collector would call dispose and free the handle behind.

Regards
Holger