Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

QueryBox Limitations?

May
855
0
Simple task: I want to display a dialog box that shows the existing name of a file along with an input field containing a proposed new name for that file (derived from the contents of said file; my goal is to make what the file contains obvious given the name of the file), and, very surprisingly to me, I absolutely can not get that to work the way that I want it to. There are two problems: 1. The "proposed" new file name is longer than the length of the input field in the dialog box despite the fact that the "length" of said input field has been set to a relatively huge value of 100 (and I could find no length that caused it to work the way I want it to), and 2. Entering any character into the input field in the dialog box causes the existing "proposed" new file name to disappear into the ether, despite the fact that the "/E" (edit?) flag has been specified, meaning that the end-user of said batch file can not "modify" the "proposed" new file name in any way to get the actual "desired" new file name. To be more specific, the code:
Code:
Set ExistingName="%@UnQuote[%1]"
Set ProposedNewName=This will be a quite long date-qualified name.V2009-01-01 To 2011-19-31.txt
QueryBox /Cue="%ProposedNewName" /E /L100 "Rename File " Enter New name for file "%ExistingName": %%NewName
Displays a dialog box whose input field contains the string
PHP:
This will be a quite long date-qualified name.V2009-01-0
and, again, the string can not be "edited" in any way by the end user, it can only be totally replaced. Am I just plain trying to do something that can not be done?
 
Simple task: I want to display a dialog box that shows the existing name of a file along with an input field containing a proposed new name for that file (derived from the contents of said file; my goal is to make what the file contains obvious given the name of the file), and, very surprisingly to me, I absolutely can not get that to work the way that I want it to. There are two problems: 1. The "proposed" new file name is longer than the length of the input field in the dialog box despite the fact that the "length" of said input field has been set to a relatively huge value of 100 (and I could find no length that caused it to work the way I want it to), and 2. Entering any character into the input field in the dialog box causes the existing "proposed" new file name to disappear into the ether, despite the fact that the "/E" (edit?) flag has been specified, meaning that the end-user of said batch file can not "modify" the "proposed" new file name in any way to get the actual "desired" new file name.

Regarding the second question, I think you just want to do a KEYSTACK END before your QUERYBOX.

I'm not sure what you're asking on the first. QUERYBOX's /L sets the maximum length of the string in characters, not the width of the box in pixels; was that what you meant?
 
Regarding the second question, I think you just want to do a KEYSTACK END before your QUERYBOX.

I'm not sure what you're asking on the first. QUERYBOX's /L sets the maximum length of the string in characters, not the width of the box in pixels; was that what you meant?
Charles, "KEYSTACK END" (which I was not doing) only makes things far worse! When I use it, when the dialog box first comes up the input field is empty, although something briefly flashes (too quickly for me to see what it is) in the input field, and again when I click either the "OK" or "Cancel" button (although this time it "flashes" long enough for me to actually momentarily see what's in the input field, and it's seems to be what would I hope it would be, not that that does any good). And I am expecting the width of the box to be in characters, not pixels! (Although as I indicated in the posting that started this thread, it doesn't matter at all what I expected the "units" to be because it absolutely doesn't matter what value I use for "/L" - "/L1" gives me exactly the same results as does "/L100". And finally, the fact that the input field "clears out" as soon as I hit a key in it was not addressed in your response. Below is the exact contents of the test script (because as you can see it is very short and so there are absolutely no "mysteries" other than the ones I am asking about):
Code:
@Echo Off
SetLocal
Set ExistingName="%@UnQuote[%1]"
Set ProposedNewName=This will be a quite long name date-qualified.V2009-01-01 To 2011-19-31.txt
QueryBox /Cue="%ProposedNewName" /E /L100 "Rename File " Enter New name for file "%ExistingName": %%NewName
EndLocal
Quit 0
But thank you for your input!
 
Try this:

Code:
@Echo Off
SetLocal
Set ExistingName="%@UnQuote[%1]"
Set NewName=This will be a quite long name date-qualified.V2009-01-01 To 2011-19-31.txt
QueryBox /E /L100 "Rename File" Enter New name for file %ExistingName: %%NewName
echo %NewName
 
Try this:

Code:
@Echo Off
SetLocal
Set ExistingName="%@UnQuote[%1]"
Set NewName=This will be a quite long name date-qualified.V2009-01-01 To 2011-19-31.txt
QueryBox /E /L100 "Rename File" Enter New name for file %ExistingName: %%NewName
echo %NewName
Dave, thank you! You are, of course, absolutely correct! Somehow I didn't think (for whatever reason) that initially setting the variable would work, so I didn't even try it, whereas I thought that "/Cue" would do the job, but upon both trying your solution and reading the documentation more carefully I see that I was wrong. ("Reading documentation" is a bit of a problem for me because of my bad eyesight.) However, the (relatively minor) problem that "/L" does not seem to work at all still remains...
 
Charles, "KEYSTACK END" (which I was not doing) only makes things far worse! When I use it, when the dialog box first comes up the input field is empty, although something briefly flashes (too quickly for me to see what it is) in the input field, and again when I click either the "OK" or "Cancel" button (although this time it "flashes" long enough for me to actually momentarily see what's in the input field, and it's seems to be what would I hope it would be, not that that does any good).

What happens if, instead of doing the KEYSTACK, you simply press the End key on your keyboard when the dialog comes up?

And I am expecting the width of the box to be in characters, not pixels!

That option sets the maximum length of the string you can enter, not the size of the dialog box. I don't know of any way to change the size of the dialog.
 
What happens if, instead of doing the KEYSTACK, you simply press the End key on your keyboard when the dialog comes up?
That works, but it solves a "problem" that I really no longer have.
That option sets the maximum length of the string you can enter, not the size of the dialog box. I don't know of any way to change the size of the dialog.
Well, that explains it!!! While the way it works was completely sensible (once I knew it), it isn't how I expected to work!
 
At the end of the day mathewsdw the file name with other long winded
file names will look the same as a bunch of
8.3 file names in the same folder. making them long has no useful
purpose. File descriptions are alot more useful.

"describe" Rex's answer to long winded file names. displays them as
comments in explore if turned on.
 
At the end of the day mathewsdw the file name with other long winded
file names will look the same as a bunch of
8.3 file names in the same folder. making them long has no useful
purpose. File descriptions are alot more useful.

"describe" Rex's answer to long winded file names. displays them as
comments in explore if turned on.
Simply personal preference here, I absolutely do not like that "solution" for a whole number of reasons. (I have absolutely no problem with them being there for those who want to use them, but I don't, or to say it another way as I've already implied, I want my file names to immediately at first glance tell me what the contents of those files are with as little "interpretation" as possible.) I will also add that it has been literally years since I have used 8.3 file names, and I absolutely detested them when they were the only option available. I have one general principle that guides all of my computer-related issues as much as possible - obvious without a lot of "thought". (Rather than "what you see is what you get", "you get what you see".)
 
From: David Marcus
| Originally Posted by Kachupp
|| making them long has no useful purpose. File descriptions are alot more useful.
|
| I doubt you will convince many people of that.

There are two statements quoted. I disagree with the first - long names can be useful. I agree with the 2nd - descriptions are more useful than long names. Suppose you copied files from one file system to another, where the source system uses characters in file names not allowed by the target. The description can contain the real name on the source. Or a file extension on one system is used to indicate scripts, while on the other system it indicates executable binary files. .COM is a good example - script in VMS, executable in FAT/VFAT/NTFS. The description can contain the original name, and other information, e.g., source file times, that may be necessary for restoring the files to the original system. It all depends on your usage.
--
Steve
 
I agree with the 2nd - descriptions are more useful than long names...
Perhaps you meant to say, descriptions can also be useful. If they were really more useful, then you would prefer to use 8.3 names with descriptions rather than long names without descriptions. Is that really true?

How are you associating descriptions to files so that they remain associated when you move the file between different operating systems?

I never use descriptions, but I use long names all the time.
 
From: David Marcus
| From: Steve Fabian
|| I agree with the 2nd - descriptions are more useful than long names...
|
| Perhaps you meant to say, descriptions can also be useful. If they
| were really more useful, then you would prefer to use 8.3 names with
| descriptions rather than long names without descriptions. Is that
| really true?

When dealing with an environment where filename completion is not available, sure I prefer short names! On WinXP this happens often.

| How are you associating descriptions to files so that they remain
| associated when you move the file between different operating
| systems?

Luckily, though I had moved many files from other OSs to the MS world, I currently need not worry about that issue. All two of my systems are WinXP.

| I never use descriptions, but I use long names all the time.

That's your privilege. Different strokes for different folks.
--
Steve
 
Long winded filenames drive me nuts. LOL I'm talking 100 plus character
names.
nice 25 length names don't bother me.

i.e.. "Captain Kirk over acts on early star trek movie.avi" lol which
one, I can handle those
I can't handle useless long winded names for silly doc's, excel, cadd
files and pdf's.

If I need too write long winded stuff, I write it to a stream name of
the file not visible in explorer but transferable
to any platform.


> -----Original Message-----
> From: David Marcus
> ---Quote (Originally by Kachupp)---
> making them long has no useful
> purpose. File descriptions are alot more useful.
> ---End Quote---
> I doubt you will convince many people of that.
 
I doubt you will convince many people of that.
Said with a sense of humor, I couldn't possibly care less. I am the only person who will ever be looking at those file names (and if I am dead, nobody else would care). And I can't resist adding that I'm a very fast typist (my high-school typing instructor told me that I was the fastest he had ever seen), so these long names are absolutely no hardship at all. And, as I have mentioned in the past, I have critically bad memory at this point in time and being able to easily determine exactly what a file contains based on its name is absolutely essential for me. (I will also note that I'm sorry I haven't gotten back to you sooner on this subject, not that this response is necessarily all that important, but my DSL modem died and it's taken me until now to be able to connect to the internet again.)
 
From: David Marcus
| Originally Posted by Kachupp
|| making them long has no useful purpose. File descriptions are alot more useful.
|
| I doubt you will convince many people of that.

There are two statements quoted. I disagree with the first - long names can be useful. I agree with the 2nd - descriptions are more useful than long names. Suppose you copied files from one file system to another, where the source system uses characters in file names not allowed by the target. The description can contain the real name on the source. Or a file extension on one system is used to indicate scripts, while on the other system it indicates executable binary files. .COM is a good example - script in VMS, executable in FAT/VFAT/NTFS. The description can contain the original name, and other information, e.g., source file times, that may be necessary for restoring the files to the original system. It all depends on your usage.
--
Steve
Steve, I don't disagree at all with your points. However, the files in question are strictly for me (and no one else) and will absolutely never, under any circumstances, be stored on anything other than a Windows 7 (or possibly above in the future) file system. And as far as "characters in file names not allowed by the target", goes, I do not use anything other than alphanumeric characters and periods in these file names (and, very rarely, dashes and/or underscores), so that's not an issue either. (And, as I have mentioned in other postings in this thread, I'm sorry I haven't gotten back to you sooner, but my DSL modem died and it's taken me until now to be able to connect to the internet again.)
 
My comment was in reply to Kachupp saying that long file names had no useful purpose and file descriptions were more useful than long file names. So, I wasn't disagreeing with you.
Dave, thank you for the clarification and I am sorry that I didn't realize that.
 
Back
Top