It is the almost (explained below) prefect tool for me to use to locate files with names that are too long so I can shorten the names. For my purposes, too long is path+file name => 190 characters. When I find them, I edit them down to a length that is below 190 characters.

Unfortunately, PFrank has Max Path Len = 256, and some of the path+file names I am working with are > 256 (max. 275 right now, 300 to allow a little) characters. Thus, I must use another tool (Bulk Rename Utility) to find files having path+file names > 256. A shame since PFrank is better in every other way than BRU.

Is it possible that you could increase PFrank's Max Path Length?
Alternative idea: while scanning, could you write a list of path+file names > 256 out to a log file. At the end of the scan give a message saying some files longer than 256 files were skipped, the names of these files were written to log file .... Do you want to open the log file now? Or any other way that makes sense.

Another idea, to help edit long file names, would be this. When I click on the New Name cell, pop out an edit box that would give me a larger area to work in where I could see the whole filename (not pathname) that I am editing. Since Max file name is 256, the box should display that much without having to scroll.

I was never able to create files with paths greater than 256 characters on XP hence I thought it was impossible for anyone else to have files that long.
Since you obviously have super long pathnames, then of course I'll increase the max filter lengths to 512.
This will be in the next release. If a beta is available before then I'll let you know but I am in the middle of a major enhancement so I can't give you a beta today).

FYI - you can use the custom creator to truncate the names.
If you don't truncate with the creator an error will appear for the long name which you can then manually edit. Before editing, you can drag the right side of the new name column to widen it. Try that and then let me know if you still need a separate popup to edit long filenames.

I was never able to create files with paths greater than 256 characters on XP hence I thought it was impossible for anyone else to have files that long.
Since you obviously have super long pathnames, then of course I'll increase the max filter lengths to 512.
This will be in the next release. If a beta is available before then I'll let you know but I am in the middle of a major enhancement so I can't give you a beta today).

Thank you so much! I will look forward to the next release.

I am using Windows XP. When these unacceptably long file names are copied to another computer it can make that computer so sick that it requires a fresh install of the OS. This has happened to me and it was VERY painful, especially as it happened several times before I figured it out. Some apps and processes can handle these extra long path+file names and others cannot.

admin wrote:

FYI - you can use the custom creator to truncate the names.
If you don't truncate with the creator an error will appear for the long name which you can then manually edit. Before editing, you can drag the right side of the new name column to widen it. Try that and then let me know if you still need a separate popup to edit long filenames.

Actually, after thinking about it more, I no longer think I need a separate popup file name editing box, for the reasons explained below. However, I think I could use a new context menu item, as I'll explain below.

Sometimes I edit/shorten the path+file name by editing the file name, but other times I edit the folder name, or edit the name of the parent folder, or even reduce the depth of folders being used. Or a combination of these.

So that I can do the above, to shorten the names on the (PFrank) Detailed Information window I follow the steps below.

THOUGHTS. To replace the above, could you add a context menu item called Explore, or Open containing folder (or whatever)?

However, if people make changes outside of PFrank, as I do, it will invalidate the Detailed Info window. A simple, perhaps best, way to handle this would be to simply close the Detailed Info window when the user chooses the Explore option. This would be the equivalent to what I now do manually. Or perhaps the Detailed Info window could have a refresh option, but that means the user needs to know they need to use it.

The best way to go might be to provide a popup that lets you edit the entire newname path. Then you don't need a refresh.
Let me think about this one.

OK. But, please know that I am quite content and happy with PFrank, AS IS, with the exception of needing the longer max. pathname length. I REALLY don't mind doing the 'Set Clipboard to...'/paste/edit/close routine, as I then have total freedom to make changes in Windows Explorer.

Howver, there is one thing that could use just a wee fix. I didn't mention in my initial post, so I'll put it here...

The BACKSPACE is needed to delete the special character (a square) that appears at the end of the line. If I don't delete it, I get an error message when I press OK.

THOUGHT: Could you delete the square character at the end of the line, or is it needed for some other purpose? The other 'Set Clipboard to...' options that I tested have the same square character at the end of the line.

I tried to reproduce the problem with the extra character on the clipboard copy but could not.
This might be a system related problem. Please try the clipboard copy again and then send me the PFrank.log file that is located in the 'Application Data\PFrank" folder (for XP systems); that file has debug and system config data that might indicate what's happening.

Sounds good. I think you could do a popup for filename as this seems like it would be straightforward to implement, and would be a feature that would improve the user interface. I agree on holding off on entire path, as this seems like it would introduce complexity that doesn't seems justified to me, at this point at least.

admin wrote:

I tried to reproduce the problem with the extra character on the clipboard copy but could not.
This might be a system related problem.

Please try the clipboard copy again and then send me the PFrank.log file that is located in the 'Application Data\PFrank" folder (for XP systems); that file has debug and system config data that might indicate what's happening.

I did the above and e-mailed the following attachments to your yahoo e-mail account:
- PFrank.log
- PFrank - Bug Report...png - a screenshot showing the PFrank with windows Run box, see square character at end of line pasted into run box.

If there is anything else I can do from this end, please advise.
Lilla

Thanks for the email. I didn't see anything in the log that would point to a problem except perhaps the system is XP SP3 (I am using SP2 - I refuse for now to change to SP3 since I heard there were problems with it).

I tried again but was unable to reproduce the problem.

One last thing for you to try is to right click on the preview list and choose "Show Hex Codes"; then see if there are any unprintable characters.

I didn't see anything in the log that would point to a problem except perhaps the system is XP SP3 (I am using SP2 - I refuse for now to change to SP3 since I heard there were problems with it).

I tried again but was unable to reproduce the problem.

I understand. I have read of problems with SP3 also, and perhaps this is one of them. Regardless, at some point (if not already), as I'm sure you are aware, SP3 will become (or has become) the new normal.

admin wrote:

One last thing for you to try is to right click on the preview list and choose "Show Hex Codes"; then see if there are any unprintable characters.

I see no unprintable characters.

I sent 2 new attachments to your Yahoo e-mail address. Notice that this time, to simplify things, my example uses...
c:\program files\pfrank\logo.ico

I had a look at the code and I think I know what's happening.
I add a newline character at the end of each row that is copied to the clipboard; this is done because multiple lines can be copied to the clipboard and it makes the most sense if each row is on it's own line.
I'll bet that the SP3 run window doesn't display the newline character at the end of the line like SP2. I wonder if the same problem shows up with Vista.
Anyhow, If I remove the newline when only one row is copied to the clipboard and provide this functionality in a debug load, would you be able to verify that it works on your system?
I am quite busy at the moment but I could have a debug load to you in a couple of weeks if that is OK.

Or maybe you could see what happens if you don't delete the square character in the run window and see if the operation you want to run still works? If the run command still works, then maybe I don't have to change anything.

I had a look at the code and I think I know what's happening.
I add a newline character at the end of each row that is copied to the clipboard; this is done because multiple lines can be copied to the clipboard and it makes the most sense if each row is on it's own line.
I'll bet that the SP3 run window doesn't display the newline character at the end of the line like SP2. I wonder if the same problem shows up with Vista.

SUGGESTION, I believe if you replace NEWLINE with RETURN all will work as desired. Continue to put a RETURN after each row, even when there is only one row, just as you are doing now.

I figured this out after I pasted some lines from PFrank's Copy to Clipboard... into OpenOffice.org's Writer where newline and return character/s are displayed as formatting characters.

admin wrote:

Anyhow, If I remove the newline when only one row is copied to the clipboard and provide this functionality in a debug load, would you be able to verify that it works on your system?
I am quite busy at the moment but I could have a debug load to you in a couple of weeks if that is OK.

Yes, I would be happy to test this for you.

admin wrote:

Or maybe you could see what happens if you don't delete the square character in the run window and see if the operation you want to run still works? If the run command still works, then maybe I don't have to change anything.

After the paste, the run window shows:
c:\program files\pfrank\License.txt<square>

If I click OK in Run window, without first deleting the square character, I get this message...

Message title: c:\program
Message icon: White X in red circle.
Message: Windows cannot find 'c:\program'. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search.

On the other hand, if I simply delete the square character first, and then click OK in Run window, License.txt opens in Notepad, as expected.

Please understand, deleting the square character each time is a small matter to me, it does not keep me from using PFrank. I can easily live with this until the next release.

Peter, thank you. I downloaded the program and conducted three tests. I documented each test in a separate e-mail sent to your yahoo email address. Some of the tests include problem and suggested solution.

and the newline is not longer included in a one row copy to the clipboard. Let me know if it works.

It works, but... the inconsistent end of line treatment will likely be problematic in other situations. I'm thinking this can be easily fixed (as shown in my e-mails), unless there is something I'm not aware of.

Another thought/observation. I notice that PFrank appears in the context menu when I r-click on Recycle Bin. To me, this seems excessive / clutter. Food for thought.

Thank you for your very excellect work. I hope my testing and feeback helps.

Peter, I want you to feel free to use my suggestions if they make sense to you, and to ignore any that don't, and to postpone implementing if you have other priorities. In an earlier life I was a programmer and systems analyst, so I have an appreciation for the complexities you are dealing with.

I think for now I am going to leave the clipboard copy with the newline removed for a one row copy.
I tried your suggestion of using a carriage return character instead of a newline and found that it made no difference with Word docs but it did not work well with Xemacs; therefore I don't think I can make everyone happy with any decision I make.
In the future I could add a configurable option to let users decide which termination character they would like but I'll hold off for now unless it becomes a big issue.

I'll investigate what's going on with the recycle bin context menu - I agree that the PFrank entry should not be there.

I think for now I am going to leave the clipboard copy with the newline removed for a one row copy.

OK.

admin wrote:

I tried your suggestion of using a carriage return character instead of a newline and found that it made no difference with Word docs but it did not work well with Xemacs; therefore I don't think I can make everyone happy with any decision I make.

For the record, in my Paste to document test I was using OpenOffice.org v2.4.1 (this is the latest version) Writer (counterpart to Microsoft Word). I also use Microsoft Office XP (2002).

admin wrote:

In the future I could add a configurable option to let users decide which termination character they would like but I'll hold off for now unless it becomes a big issue.

I like this idea a lot. I would favor making the default the RETURN character as that works with Microsoft Word, and OpenOffice.org, and I expect most apps.

admin wrote:

I'll investigate what's going on with the recycle bin context menu - I agree that the PFrank entry should not be there.