Build Step Copy Files To Subdirectory fails

General
1

Suppose I have a web app project called MyWebApp and it lives in a folder called MyWebApp.

I create a CopyFiles1 Build Step and drag it to Linux icon, and then drag it one more time to the just under the Build Gear icon there. Now I drag a single SQLite file to that files references pane. I then chose to have this work only with Debug. I then fill in the Subdirectory field as “MyWebApp.debug” without the quotes. Destination field still has App Parent Folder.

When choosing to Run this from the iDE, the SQLite file is not copied to the MyWebApp.debug folder.

What am I doing wrong? I want to stop referencing files via “If DebugBuild …” and do it with a Build Copy Files Step instead.

2

Does the same thing happen when you press “Build” instead of “Run”? :slight_smile:

3

If I change the CopyFiles1 entry to do Both instead of Only Debug, and hit Build instead of Run, the sqlite file shows up in the Build in the intended Subdirectory but fails to show in that Subdirectory on my hard drive.

4

I’m now getting around all my various “If DebugBuild …” lines in various methods by just using a global function that returns a FolderItem when fed fileName As String, assuming the given file that needs to be accessed during Debug is in the same folder as the app project:

If Not DebugBuild Then Return GetFolderItem(fileName) Else Return GetFolderItem(_ GetFolderItem("").Parent.NativePath + "/" + fileName, FolderItem.PathTypeShell _ ) End If

5

Make sure when you’re using compiler directives and pragmas that you prefix them with “#” and only when using the compiler directives does End If become #endif.

I assume you’re on Windows? Using the above GetFolderItem("")… wouldn’t work properly in the 2nd part of the else statement on Mac (or Linux), giving the incorrect directory…actually, resulting in a NilObjectException :slight_smile:

If you replace both GetFolderItems with the single following line (literally delete from if to end if…all of it :-))…

Return App.ExecutableFile.Parent.Child(fileName)

You can eliminate the entire if/else/endif condition altogether, but will need to make sure your sqlite file ends up where it needs to be. The above line, no matter what, whether runtime, debug-time, always will result in the path that the executable resides within.

If you decide to stick to the original code… it should look a little more like:

[code]
Dim fileName as String = “myfile.sqlite”

#If Not DebugBuild or TargetMacOS or TargetLinux Then
'All OS’s except Windows, have the debug and final build, created in a non-debug subdirectory.
Return GetFolderItem(fileName)
#Else
'Only Windows debugs are created within a subdirectory
Return GetFolderItem("").Parent.Child(fileName)
#EndIf

'the Parent.Child takes care of the +"" + NativePath :slight_smile:
'and the code should run on Windows, Mac, and Linux without flaw. [/code]

Would you possibly be able to make a demo using only the offending code, so that the community has something to load into Xojo and take a look at to be able to diagnose exactly where the issue exists?

We’ll get you up and running :slight_smile:

6

Thanks, Matthew. The code I posted works fine on the Mac, even with this line:

Return GetFolderItem(_ GetFolderItem("").Parent.NativePath + "/" + fileName, FolderItem.PathTypeShell _ )

But I have changed the entire function to this, based on your comment:

#If Not DebugBuild Then Return GetFolderItem(fileName) #Else Return GetFolderItem("").Parent.Child(fileName) #EndIf

That 4th line is obviously better than what I originally posted.

However, is it really important to prefix those lines with ‘#’? What’s the side-effect of not doing that? Is it basically saying, don’t put the Else clause in the code when building because the built executable is not going to be run in Debug mode?

7

Perhaps I wasn’t clear about the code above. I wrote it so that when running the app in Debug, it will look up one level in the folder structure to find the needed extra files, so I don’t have to have those files copied to the Debug folder.

8

You were clear.

The method that Matt suggested will actually cut down on what’s actually compiled and could make your app run faster.

Having looked at this, I’d bet that the problem is the debug “extension”. Try using an underscore or a dash instead of a period before the word debug in the name.

“MyWebApp_debug” instead of “MyWebApp.debug”

9

Just tried both “MyWebApp_debug” and “MyWebApp-debug”, but had the same results. I’m happy with just using the GetLocalFile() function I outlined above whenever I need the app to find needed files. At least I’m no longer coding “If DebugBuild …” every time a method needs to access such a file, like a database file or a BKS Shorts report form.

10

** By prefixing with the ‘#’, before the code is actually compiled, the statement is evaluated by a preprocessor, and anything that doesn’t match the condition is completely eliminated from the compilation. If you were to have say:

#if TargetWindows then 'Implement a Windows System API Declare #elseif TargetMacOS then 'Implement a Mac System API Declare #elseif TargetLinux 'Implement a Linux System API Declare #endif

and were to leave off the ‘#’, the compiler would prompt an error when it attempted to compile for the target platforms, which ever aren’t the ‘current development machine.’

Directives prefixed with a ‘#’ are only seen by the Xojo ‘Pre-compiler,’ and action is taken before it is passed to the actual compiler. Say for instance the above pseudocode was compiled for Windows… out of all the code above, the compiler would only see:

'Implement a Windows System API Declare.

If compiling for Mac, the compiler would only see

'Implement a Mac System  API Declare

and so on.

When running code in the Xojo IDE, and you have breaks turned on for exceptions… say there’s a function that the code always breaks at (maybe a timer), and you really don’t need the code to ever break there, because you know there are no exceptions…

You can add:

#pragma BreakOnExceptions False

to your code, and anything below that code, will not be stopped at.

You can also add #pragma BreakOnExceptions True immediately after a line that you know you don’t ever need to break at; that way, you can debug any other possible bugs which might exist within a particular method, apart from where the ‘unnecessary’ break, that we suppressed, occurs.

You can also use pragmas directives to optimize your code a great deal, especially when dealing with processor intensive functions, any all sorts of cases (nilobject checking, bounds checking, etc.)

Learn all about them here: http://developer.xojo.com/pragma-directives

11

Wonderful reply, Matthew. Very clear and complete. Thanks so much.