This may be a difference between macs and windows issue.
Am converting an old experiment written on the mac to a new version that will have to run on windows. Per suggestions in another question I raised, I am now trying to work in Xojo on the Windows laptop.
Executable brought over from Mac (where I have the license) runs (there are other problems that occur on Windows but not Mac that I won’t address here). When I try running the code inside the Windows Xojo, early on it will not open (cannot see) a file that is in the same directory as the source code, even though on the mac that situation works fine. It doesn’t matter if in the code I call it jak.txt and the file is overtly named jak.txt, or if I remove the “.txt” in both places. It cannot see the file, and has an error and quits.
Do we have to do paths differently on Windows? I have been looking for any conversation on this on the forums and also in the language reference, but haven’t found anything that helps so far. I have a feeling that if I hard coded the full path it would see it, but I haven’t tried that yet because our end user (NASA) has told us not to use hard coded path names, last I was told.
On the Mac the debug app is run from where the source code is. On Windows, the debug app runs within an empty folder inside the source code folder which is created at runtime and then erased after you quit the debug app. Which means you cannot copy anything in there to open at runtime. So in essence the debug app runs inside the empty folder and can’t find your jak.txt.
You may want to debug with a definite shellpath to your source code as folderitem so you are sure the app will find your file. Another way would be to build the app and copy jak.txt into the build folder, then use
folderitem = app.ExecutableFile.parent.child(“jak.txt”) to find your file, and execute the build instead of debug.
Try replacing your FolderItems with something like this…
Dim Fitem as FolderItem
#if debugbuild And Not TargetMac then
Fitem = GetFolderItem ("").Parent.Child("file.txt")
#Else
Fitem = GetFolderItem ("").Child ("file.txt")
#EndIf
Thank you, Brian, Michel, and Matthew for helping this Windows neophyte out.
I think the page “Making debugging a bit easier on Windows” is going to be a huge help to me in general. And it helps to know the difference between how Windows and Mac handle running the debugger wrt file names. I’m going to try Michel’s solution first (just for debugging, as I know it works properly with the executable which I can still make on the mac side), just to get past that hurdle and on to the real debugging. I’ll keep Matthew’s solution in mind in case the other doesn’t work. (When it is time to build I’ll fix it back to what works with no directory specified.)
I’m going to have to because I apparently don’t understand the filefolder and path stuff (even though I’ve printed the relevant manual stuff out, and even used code out of the manual to get at it with the absolute path) well enough to proceed yet. So, now to try Matthew’s suggestion. Also the shellpath idea (which I thought was absolute path) didn’t pan out. In any case, coding in what I thought was the absolute path didn’t work (I tried it in a little toy program…file still not found).
Just so it is clear: in the final built product, we cannot use absolute paths. So the text file, and the output files, must reside in the same folder as the executable. On the mac this has never been a problem, whether debugging or using the built executable. (Therefore, I’ve never had a need to learn anything about paths in all the years I’ve been programming my experiments. It’s just worked.) for Windows, the built executable works fine as well, near as I can tell (at least for this part). But I don’t have a license on the laptop, only on my mac, at the moment. (We may or may not buy another license for the PC, depending on if the built executable built on the mac works ok on the PC after I debug on the PC and then copy the XOJO file back to the mac.)
And I need to debug some known problems that are occurring later in the program on the PC (they do not occur on the Mac, and are of a layout/graphical nature and I’m at a loss as to what is going wrong), so I must get past this problem and get this darned file open. I don’t mind writing a little extra code while I’m debugging that gets at this file (e.g., using the full path name that I can then delete when I go to build) but I hope not to write so much extra code in there that it is difficult to remove again when I need to build.
I do greatly appreciate everyone’s interest and suggestions. The simpler the suggestion the better
#if debugbuild And Not TargetMac then
Fitem = app.ExecutableFile.parent.parent.child(“jak.txt”) #Else
Fitem = app.ExecutableFile.parent.child(“jak.txt”) #EndIf[/code]
Not tested on Windows yet, working on Mac at this time;)
Matthew’s code is the correct way to do it. GetFolderItem("") is preferable to app.ExecutableFile.Parent. You could improve it slightly to reduce the overhead in the built executable. One less folderitem operation.
Dim Fitem as FolderItem
#if debugbuild And Not TargetMac then
Fitem = GetFolderItem("").Parent.Child("file.txt")
#Else
Fitem = GetFolderItem("file.txt")
#EndIf
Well, until I solve THIS problem (see next paragraph), I’ll have to put off using the above solutions. (I got this the first time I tried using the #if debugbuild, FWIW. I’ve never used that before, though I knew of the existence of the #if etc. world.)
Cannot connect to the debugger
The debug application cannot connect back to the Realbasic IDE. This is mostly likely due to a software firewall or packet filter not allowing localhost network traffic on ports 13897 or 60554. You should reconfigure your software firewall or packet filter to allow the debug application to connect to REALbasic.
Would you like to retry the connection?
(I have found reference to this problem in the forums, but the solutions proposed there don’t make sense to me…I don’t do anyting with firewalls, and indeed have debugged many times on macs with nary a problem. Looks like this particular problem with even the same port numbers has been going on for years… Will contact my local gurus.)
Don’t forget you can also use a Copy Files Build Step to copy specific files alongside the built application. This can sometimes help when dealing with different path issues on Windows vs. OS X.
Noted. I did not know “” was the equivalent to app.ExecutableFile. I use that code to load my html help file. On the Mac I place it in the bundle, and on Windows I place it next to the executable.
I just took a few minutes to see what is going on with Xojo Windows and folder structure between debug and build.
Matthew’s code is good and will save having to modify code between debug and build. However, the file must be copied into the build folder next to the executable.
Carolyn : during debug, jak.txt should be in the same folder as your app source.
When you create a build, make sure to copy jak.txt into the folder Builds - _xojo_binary_project/Windows before you run the build.
[quote=53259:@Michel Bujardet]Noted. I did not know “” was the equivalent to app.ExecutableFile. I use that code to load my html help file. On the Mac I place it in the bundle, and on Windows I place it next to the executable.
I just took a few minutes to see what is going on with Xojo Windows and folder structure between debug and build.
Matthew’s code is good and will save having to modify code between debug and build. However, the file must be copied into the build folder next to the executable.
Carolyn : during debug, jak.txt should be in the same folder as your app source.
When you create a build, make sure to copy jak.txt into the folder Builds - _xojo_binary_project/Windows before you run the build.[/quote]
Yes, that is exactly where I’ve been placing them. Thanks for helping me be sure I was doing the right thing with that.
Unfortunately, now the firewall error is occurring even when I delete the # code and leave only the code that should execute in a debug, AND I have to leave for the day (not back until Wednesday, and only mac at home so can’t debug there; plus with the holidays coming up my work schedule is even worse the next couple weeks, between kids being home and travel). I’m hoping my local IT folks (they are very good, though mostly work with Mac stuff and with Python these days) will be able to help me on this firewall thing. (It sucks working very part time when one is a programmer and just wants to keep going until it works!)
Again many thanks to everyone helping me work this out. I do appreciate it SO much! – C
Almost. GetFolderItem("") returns the folder the application is in. On Windows, that is also the same as app.ExecutableFile.Parent. On Mac, it’s the folder that contains the bundle. App.ExecutableFile is several folders deeper.
Carolyn, the solution is much simpler than whatever we discussed : add a copyfile build step and copy jak.txt into the App Parent Folder, then make sure to drag the copyfile down in Windows build, under the build wheel. Jak.txt will be copied into the temporary debug folder when you run, and again in the build folder for the release. No more extra coding.
