TC 7.03 DnD to tool bar uses DOS names

[bekkra]

Hi,

I've recently ( at least since 7.03 final ) noticed that dropping a file name to a user tool on the tool bar results in short names ( a.k.a DOS names or aliases ) in the argument list to the tools. The problem is then that the tool uses file names with reduced information, which makes file name processing cumbersome or impossible. On top of this, TC behaves differently when dropping file names to the shell, as opposed to when thits internal toolbar is used.

To reproduce the behaviour:

Using
Windows XP x32 (any version)
Windows Vista x32
Windows Vista x64
Windows scripting host >=5.6 ( XP is usually 5.6, unless the update has been installed )

1) Add an argument catcher to the toolbar. The following code will do:

Code: Select all

<job id="ToolArgument">
	<script language="VBScript">
		arg = WScript.Arguments(0)
		If InStr ( arg, "~" ) Then
			result="File name alias"
		Else
			result="Proper file name"
		End If
		CreateObject("WScript.Shell").Popup result & " was supplied" & vbCrLf & arg, 12, "DnD tool argument test", vbOKOnly
	</script>
</job>

2) Use any file with long name ( longer than the 8.3 ) in any part of the full path to the file

3) See that the file name provided to the tool ( in case the script ) is actually the short alias

You can verify that the system itself handles this properly by:

4) Add a shortcut to the script to the desktop

5) Drag and drop the same file as in the above test and see the proper result.

The expected behaviour is that TC should use the long file names as the shell does.

Last tested on:
Vista x64 SP1
+-- WSH 5.7
+-- TC 7.03 final

Verified on
XP SP2
+-- WSH 5.6
+-- TC 7.03 final

//

[Clo]

2bekkra

Hello ! Welcome aboard !

• What about THIS ? Please scroll to the “Parameters” paragraph…

 Kind regards
Claude
Clo

[bekkra]

Thank you for your response.

I am a long time mostly satisfied TC user. I wish better speed in the updates, but that's always easy to cry for

Your suggestion lead to an interesting page. I have an immediate comment: provide a means to access the parameter information from the toolbar button dialog.

The information was, although useful, not directly useful. I have tried several combinations, mostly with the %P%S coding. I have found some kind of inconsistency in TC.

I have tried a configuration with:
command=script.wsf
parameters=%P%S

To begin with; my problem can be resolved by altering the way I am calling my app. Instead of drag and drop, I can use the "operate with the currently selected file(s)". So a successful operation is

1) select the long file name
2) click the toolbar button

Go ahead, try it.

Dropping the same file name on the button results in the earlier behaviour, regardless the parameters in the button command ! Notably, the question mark hack for the command line prompt was not used under DnD. This seems as a minor inconsistency.

Thanks to yout link, I can now use my button, although not perfectly as I would have wished.

I still advise you to fix the incosistency between clicking and dropping

Thank you.

//

[white]

See [BUG] Drag&Drop to a button transfers 8.3 filename...

I still advise you to fix the incosistency between clicking and dropping

2Clo: It looks like he thinks you are the author of Total Commander.

[icfu]

I've recently ( at least since 7.03 final ) noticed that dropping a file name to a user tool on the tool bar results in short names ( a.k.a DOS names or aliases ) in the argument list to the tools.

This happens when you are using parameters in command section:
http://www.ghisler.ch/board/viewtopic.php?t=18015

According to the author in this case the Windows function to detect 16-bit/32-bit status will fail:
http://www.ghisler.ch/board/viewtopic.php?p=141296#141296

I hope that it will be fixed in TC 7.5, 'cause it extremely sucks to have applications treated as 16-bit in 2008. There should be no automatic detection if it cannot be guaranteed that it works flawlessly.

Icfu

[karlchen]

According to the author in this case the Windows function to detect 16-bit/32-bit status will fail:
http://www.ghisler.ch/board/viewtopic.php?p=141296#141296

I hope that it will be fixed in TC 7.5, 'cause it extremely sucks to have applications treated as 16-bit in 2008. There should be no automatic detection if it cannot be guaranteed that it works flawlessly.

Icfu

Agreed! => cf. here, if you like.

Karl

[icfu]

Zwei Doofe, ein Gedanke!

Icfu

[bekkra]

Heh, with the word "you" I addressed "those who are monitoring the bug reports to fix them".

Anyway, I concur; the problem should be fixed; and yes, it might be time to drop the 16-bit legacy. We *are* moving to the next generation, where 32-bit might be considered as legacy.

TC/16-bit as of now should be good enough for sites that are forced to legacy OSes. Many of those stay where they are because of old hardware or because more recent operating systems are simply expensive. ( Vista, *cough* ).

32-bit software has been around since about '92; sixteen years of compatibility should be enough.

Thanks for the additions to this thread, guys.

//

[StatusQuo]

2bekkra

32-bit software has been around since about '92; sixteen years of compatibility should be enough.

I disagree here - because simply reverting the existing behaviour would be enough to fix the problem IMO,
as suggested by karlchen in the above linked thread.