Relative path problem


I have the following code to execute a batch file in the project folder next to my app executable.

Dim sh As New Shell

dim f as folderitem = GetFolderItem(“C:\Users\KentG\Desktop\GnuPlotTry\XoJoCmd.bat” , Folderitem.PathTypeShell)

The project runs the batch file fine (after building it of course). The problem is that the path to the batch file is an absolute path. I need the relative path so that the batch file will run wherever the app executeable is located.

I have tried xojo documentation, and other link possibilities with no success. Does anyone have a solution?

Thanks all

relative to what? where is this BAT going to be “relative” to the app?

maybe “GETFOLDER(”").child(“xojocmd.bat”)

I meant to say:

I always run my apps from the project folder. I would like the batch file to be located next to the app executable .

maybe “GETFOLDER(”").child(“xojocmd.bat”)

I am sorry, to clarify, the project folder could be located anywhere on the computer, and not in a fixed location.

not sure what you point is…
You said the BAT file will be in the same folder right?
Have your READ the documentation about the command I gave you?
If you are not willing to put a little effort into looking into suggestions provided, then what do you expect us to do for you?

I assume your snippet returns a folder item. If it does, it doesn’t compile, and if not a folder item, what is it? xojo can’t find any item called GETFOLDER.

Perhaps you meant GETFOLDERITEM?

Don’t assume anything… research it… Good Luck… I’m moving on now

Excellent very sarcastic non reply, There is no Xojo documentation on simply ‘GETFOLDER’, that I can locate. Show it to us, your documentation is for all of us, not just me. You simply gave a ‘no useable information’ reply with, evidently, no research done on your part first.

If you are not willing to put a little effort into looking into documentation before you provide a reply to us, then we can’t use your reply to assist us.

Next time, provide at least a valid snippet for us to start with. In the mean time, “research it first… Good Luck… I’m moving on now”.

Yes… I have little tolerance for those who wish to be spoon fed…
I attempted to help you with an “off the top of my head” solution…
Yet YOUR response was indignant, and basically rude…
From the information I provided, you did find the right command, and hopefully learned something…

But Mr. Jarvis… don’t be expecting future help from me… I will be applying my knowledge and expertise to those who are willing to invest in their own education… have a nice life

We got no help from you…

I think that you have already discovered this for yourself, but just to clarify.


That method (when you pass in an empty string) will return a FolderItem that represents the parent folder of the executable file, or the parent folder of the project file if you are running it in the debugger.
From there you can use .child(“nameofmyfile”) to retrieve a file that is located in the same folder as the executable.

Thank you. I will give it a try.

Thanks, Jared. That works perfectly!

Those looking for help should be willing to read the documentation as well.

Better to put stuff like this into the Application Data folder, so that you can get at it even if the Application is moved.


unless of course the batch file is ALSO expecting to find things relative to it, in which case ignore this.


Yes, the batch file needs another file next to it. The batch file calls GnuPlot with a GnuPlot command file that opens a plot data file, and plots the data. It is now working wherever the folder is located.

I was using ChartVue.

The Chartview plot is just beautiful, but for scientific and mathematics plotting, the horizontal gridlines only(?) and lack of minor x and y gridlines(?) in ChartView do not allow for closely reading x and y values with any accuracy.

GnuPlot is totally flexible in every way, draws a very nice labeled accurate plot, is constantly updated, and costs nothing.

For me, there has been a lack of customer support for ChartView. So far they have been unresponsive.