Page 2 of 2
Re: XY to retain Variables on adress paths.
Posted: 22 Jul 2010 15:47
by admin
PS: I see a chance for a general option "Do no auto-change the address bar contents after triggering them." I could live well with this, maybe it even should be like this.
Entering/selecting
%tmp% would stay
%tmp% (instead of turning to [your temp path])
Entering/selecting
::goto "c:"; would stay
::goto "c:"; (instead of turning to C:\)
etc.
Interesting?
PS: I just saw you are now talking about tabs. Sharpen your vision: what do you really want?
Re: XY to retain Variables on adress paths.
Posted: 22 Jul 2010 15:48
by TheQwerty
admin wrote:Too much work.
Is that also the response to:
TheQwerty wrote:EDIT2: That said, why couldn't this tweak be expanded to use Environment variables as well?
Re: XY to retain Variables on adress paths.
Posted: 22 Jul 2010 15:52
by nas8e9
Stefan wrote:nas8e9 wrote:
I'm confused: Windows defines %TEMP% and %TMP% as separate variables
instead of concatenating %USERPROFILE% or %LOCALAPPDATA% with strings.
That should mean that changing %TMP% to something outside %USERPROFILE% or %ALLUSERSPROFILE%
should still result in %TMP% returning the right folder?
%temp% and %tmp% pointing both to
C:\Documents and Settings\<UserName>\Local Settings\Temp\
%UserProfile%\Local Settings\Temp\
or
C:\Users\<UserName>\AppData\Local\Temp
%UserProfile%\AppData\Local\Temp
You can do "set TMP=C:\myTemp"
and then %tmp% points to " the right folder"
"C:\myTemp" , but not to "%UserProfile%\....\Temp\" anymore.
Please note that %temp%/%tmp% came from an time where there wasn't any "user profile folders".
And back in that days %temp% and %tmp% pointed to different dirs.
HTH to clarify a bit
As confusing threads (to more than one participant
) goes, this one takes the cake this week certainly...
My confusion was with the apparent assumption by the OP that %TEMP% and %TMP% are somehow dependent upon two other environment variables. Having been around myself since DOS 3.3, I thought that unlikely
. I'm not sure why both %TMP% and %TEMP% were introduced, presumably by Microsoft?
Thank you anyway for the explanation!
Re: XY to retain Variables on adress paths.
Posted: 22 Jul 2010 15:55
by SkyFrontier
Admin:
Entering/selecting %tmp% would stay %tmp% (instead of turning to [your temp path])
Entering/selecting ::goto "c:"; would stay ::goto "c:"; (instead of turning to C:\)
etc.
Yeah, you got it!
Tabs are a different matter being solved by the new tick boxes approach (scripters, HELP! lol).
Keeping variables on adress bar is a few clicks less than what I currently have to do. Mouse wheel unable to scroll down adress bar history is a thing that I hardly believe, but... can live with that, if %tmp% (or whatever) simply stays there. Auto-triggering on startup looking for the new real locations would be better, but it is an acceptable workaround, for sure.
*THANKS MUCH!!!*, in other words.
Re: XY to retain Variables on adress paths.
Posted: 22 Jul 2010 16:05
by TheQwerty
I think it would be a mistake to keep the variables in the address bar... My thought was that the desired affect is to avoid location not found when starting XY (portably) on different machine.
If Machine A has %tmp%=C:\temp, and B has %tmp%=D:\temp
Opening "%tmp%" in XY on Machine A and then going to Machine B currently shows location not available since "C:\temp" cannot be found.
Ideally, XY would store the tab paths using the environment variables that were entered by the user (but still display the resolved path in AB, IMO), so that when the user goes to Machine B XY would open to "%tmp%" instead of "C:\temp" and thus correctly end up at "D:\temp".
I wouldn't think it would be difficult to extend the existing tweak to do this as well, but then I don't know what Don is doing behind the scenes.
Re: XY to retain Variables on adress paths.
Posted: 22 Jul 2010 16:10
by admin
TheQwerty wrote:admin wrote:Too much work.
Is that also the response to:
TheQwerty wrote:EDIT2: That said, why couldn't this tweak be expanded to use Environment variables as well?
Relative paths can be resolved in both directions easily. Not so with env vars. I just did some experiments with a different way, and it could work but there are some problems left. No time now for this. Maybe later if more demand shows up.
Re: XY to retain Variables on adress paths.
Posted: 22 Jul 2010 22:13
by TheQwerty
I'm not sure where to continue the discussion on this since Don started posting in this old thread..
http://www.xyplorer.com/xyfc/viewtopic.php?f=5&t=4634
But I like this one better.
1) Address bar keeping displayed variable. I may be alone but I'd like a tweak to restore the old behavior.
2) The portable paths are almost useful.. but I think you need to take it a step further. Keeping the portable version of the location should work more like locking the home zone,. So I can lock it to <xypath> and it will continue to use <xypath> if I browse into it's children, but if I attempt to go above it or outside of that branch it goes to the absolute path.
Re: XY to retain Variables on adress paths.
Posted: 22 Jul 2010 23:21
by SkyFrontier
Querty:
1) Address bar keeping displayed variable. I may be alone but I'd like a tweak to restore the old behavior.
You're not alone, pal. I'd love to actually SEE right on top of the address bar (sorey for the typo on thread's title, fellas!) what is leading me there. But I think that the solution presented may have the only (fastest?) way to circumvent a technical limitation. And I prefer a half-way solution that an entire problem to live with...
-of course if Don could bring us an on-the-face solution would be better, but I'm more than happy with what we achieved today - almost full portability regarding folders and system variables!
-...I'd vote now for full support to more windows standard variables, such %mydocs% and something like that.
-is it possible to have auto-completion suggestions for variables and XY commands popping under the address bar as we currently have type-ahead for locations, Don? As the (thank you!!!) increasing number of possiblities given to and thru XY, I think that could help a bit for us that one day or another have to quickly enter such stuff without having to scroll down documentation of any type!
-in a hipotetical scenario where say machine X have c:\temp and d:\temp and machine Y have d:\temp and e:\temp, both intended to be sync'ed, is it possible to have a secondary control on what will be displayed by "?:\temp", for example....
being "2" a statement to point always to the second folder if > 1 of same named folder is found?
Thanks much, owe you a beer (or whatever you like to drink!) over here!
...hope this really contributes for the cause, also! A PORTABLE file manager any way you may think of it! GREAT!
Re: XY to retain Variables on adress paths.
Posted: 23 Jul 2010 07:14
by admin
SkyFrontier wrote:Querty:
1) Address bar keeping displayed variable. I may be alone but I'd like a tweak to restore the old behavior.
You're not alone, pal. I'd love to actually SEE right on top of the address bar (sorey for the typo on thread's title, fellas!) what is leading me there. But I think that the solution presented may have the only (fastest?) way to circumvent a technical limitation. And I prefer a half-way solution that an entire problem to live with...
Huh, don't understand...
Conc. the other ideas: not possible or not interested (yet). I'll wait for more feedback first. I find the new portable tabs thrilling + revolutionary + intuitive as they are now.
@TheQwerty: Why you don't like the new AB behavior?
Re: XY to retain Variables on adress paths.
Posted: 23 Jul 2010 11:25
by SkyFrontier
Admin:
Huh, don't understand...
In my case, I'd like (prefer?) continuing to see a %temp% (whatever) variable being displayed by address bar even after jumping to other panel/tab and going back where the original variable was being visible.
Reason: the tree and the destination location (thru tab header) already tell me where I am. It would be good to see HOW I get there and IF I'll stay there after restarting XYplorer.
Re: XY to retain Variables on adress paths.
Posted: 23 Jul 2010 11:35
by admin
SkyFrontier wrote:Admin:
Huh, don't understand...
In my case, I'd like (prefer?) continuing to see a %temp% (whatever) variable being displayed by address bar even after jumping to other panel/tab and going back where the original variable was being visible.
Reason: the tree and the destination location (thru tab header) already tell me where I am. It would be good to see HOW I get there and IF I'll stay there after restarting XYplorer.
I see. No, that's not possible.
Re: XY to retain Variables on adress paths.
Posted: 23 Jul 2010 12:01
by SkyFrontier
Thank you! anyway, Donald.
What you currently gave us is a great improvement already and in a real world scenario I may be able to achieve similar effect just by giving TABS a suggestive name such (guess what...?) "%TEMP%!
, which is another great XY feature for portability reasons.
Hope you bump on the other ideas one day or another. Now I know you do - time's a master.
Re: XY to retain Variables on adress paths.
Posted: 23 Jul 2010 12:19
by admin
TheQwerty wrote:2) The portable paths are almost useful.. but I think you need to take it a step further. Keeping the portable version of the location should work more like locking the home zone,. So I can lock it to <xypath> and it will continue to use <xypath> if I browse into it's children, but if I attempt to go above it or outside of that branch it goes to the absolute path.
Good idea and interesting coding excercise. I think I made it.
Re: XY to retain Variables on adress paths.
Posted: 23 Jul 2010 14:18
by TheQwerty
admin wrote:@TheQwerty: Why you don't like the new AB behavior?
I think I preferred seeing the resolved addresses... but leave it as is and I'll request the tweak again later if this doesn't grow on me.
I think it'll take - at least as long as Escape expands the location in the address bar.
Re: XY to retain Variables on adress paths.
Posted: 23 Jul 2010 14:23
by admin
TheQwerty wrote:I think it'll take - at least as long as Escape expands the location in the address bar.
Hey, cool, I did not even know it does.