Very strange CommandLine$() bug

Archives Forums/BlitzPlus Bug Reports/Very strange CommandLine$() bug

Stoop Solo(Posted 2011) [#1]
UPDATE:

Launching a compiled executable by dragging a file onto it, or launching it by double-clicking another file associated to the executable in Windows screws up the executable's relative path info. The path and filename is passed onto the ComandLine$() function, but all relative file access within the executable will fail.

This makes it impossible to create a program that has the functionality to automatically open a file via Windows file association.

AutoMidHandle True

;The LoadImage operation will return zero if the compiled exe is launched by clicking
;on another file that Windows associates with it, or by drag/dropping a file onto it.
;If the bitmap's relative path is changed to an absolute path,
;the compiled exe will work when launched as above.

Global testimage = LoadImage ("testbmp-1.bmp")

Graphics 640,480,32,2

Notify CommandLine$()

Repeat

	For f = 0 To 479
		Color 0,0,f Shr 1
		Line 0,f,640,f
	Next

	;if the stipulated conditions in the bug report have been met,
	;the program will crash at the DrawImage line.
	
	DrawImage testimage,320,240
	Flip False
	Delay 50

Until KeyHit(1)


Launching the executable via a Windows shortcut with a command line specified or via a command prompt does not produce this problem, at least not with Win XP.

This is running on:
- Intel Xeon W3530
- 12GB RAM
- Windows 7 Enterprise 64 Bit
- GeForce GTX 260, DirectX 11.0

And on:
- Acer Aspire 5112
- Windows XP SP3

Last edited 2011


Matty(Posted 2011) [#2]
This may sound simple but - have you checked if the handle of the image is non-zero - ie that it actually loaded correctly. If the image did not load then any command relating to the image will fail.


Stoop Solo(Posted 2011) [#3]
I stumbled across this when I was trying to add functionality to an existing program to open a file passed through the command line, so the associated data files could just be double-clicked.

In the above example, if provided a bitmap, the program executes fine; draws image etc. It's only if I drag a file over it to launch it with a command line that the program crashes. As can be seen in the above example, I don't even do anything with the command line data, except for displaying it in a 'notify' window. Even if you comment out the notify it fails, but only in the eventuality I stipulated.

Still, now you have mentioned it, I will check tomorrow if the image handle somehow gets messed around when launched via this way.

Last edited 2011


Stoop Solo(Posted 2011) [#4]
Ah, that's interesting. Good call on checking the file handle, Matty. It's shed more light upon this particular issue.

I just tried this with Windows XP, and the same problem occurs. Even a file in the same location causes the crash. I tried printing the file handle value just after the notify. In the case of just launching the exe, I get a value. If I launch by dragging a file to the exe, the file handle is zero/

If, however, I specify the full path with the name of the bitmap for the LoadImage, rather than a relative path, it works even when a file is dragged to it.

It appears that if a file and path is passed to the exe on launch, it screws with the exe's relative file path. I shall update the original report.

Last edited 2011


Floyd(Posted 2011) [#5]
the executable in Windows screws up the executable's relative path info

Windows is responsible for setting the default path, not BlitzPlus.

You can never depend on a certain default being used because it can be changed as the program is launched, for example when started via a Windows shortcut.

Try creating an exe from the following code. Run it in various ways and observe the results. Create a shortcut. Right-click on the shortcut and select Properties. You can then set the "Start in" default location to any place you want. That's why your program could never assume any particular default path.

The right way to organize this is to put files your program needs in some known location relative to the exe. Then use SystemProperty to find out where the exe resides and use that to get the full path for any "relatively located" files.


Graphics 750, 300, 0,the executable in Windows screws up the executable's relative path info 2

Text 20, 100, " Default path:  " + CurrentDir()
Text 20, 130, "exe location:  " + SystemProperty( "AppDir" )
Text 20, 160, " Command line:  " + CommandLine()

WaitKey



Stoop Solo(Posted 2011) [#6]
Hmm, so this is in fact a Windows... "feature". I mean, I know you can change the working directory of a program by specifying it in a shortcut, but I didn't think it would change simply by passing it a file. That doesn't seem to be a desirable behaviour to me.

Anyhow, after what you said, I was concerned that since the exe and resources in question are packed into a single executable using MoleBox that there would be no way to set a correct path, but it seems pointing the LoadImage to the path of the packed executable works, so the eventuality is handled by MoleBox.

So disregard this "bug", Blitz team. Thanks to Floyd, Matty and MoleBox. Pooh with knobs on to Windows.

Last edited 2011