I have the following code in the DoubleClick event of a listbox.
var theItem as FolderItem
theItem = new FolderItem(me.SelectedRowValue, FolderItem.PathModes.Native)
The string in
me.SelectedRowValue is a path to a file. The path is a correct native path.
When I run the code, however, the constructed FolderItem
theItem is created with a path that appears to be relative to the application. In other words the path of the created folderItem is the path to the application, plus a space, plus the native path to the file.
/Users/JohnDoe/Documents/Tools/Xojo Projects/ /Users/JohnDoe/Documents/Tools/DATA_SETS/Files/test-file.jpg
Why might that be? I’ve done this before but I’ve never seen this behavior.
What am I overlooking?
Where does it apear to have the wrong value?
When I set a break point and inspect the FolderItem in the debugger I get the native path that I pasted in my original post above.
(Also, when I double click the listbox entry the file’s parent folder doesn’t open.)
How do the item paths end up in the Listbox? Can we see the code for that?
That was the explanation for this effect I was searching for! Thanks much cause it drove me nuts. I was working around but somehow I believed that I made it wrong somehow! Made my day
When I get back to my workstation I can share it, but it’s simply the string native path of the folderitem of the file in question.
This is what I thought it might be. Did you know you can store the actual
FolderItem in RowTag or CellTag? It’s much easier to pass the object around than the string. I am curious where the extra space comes from though.
@Tim_Parnell yeah, it was that extra space at the beginning of the string.
I am getting the path string by parsing the results of terminal utilities output. I failed to notice that there was a space at the beginning of thee result.
String.TrimLeft took care of it.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.