The Xojo Navigator, currently, has limited native file support when dropping files into it. For example, if you drop an image file into the navigator, you can view and use that image in your code as if it were loaded as a resource.
I am requesting that this feature be expanded to other native file types such as HTML, CSS, Text, etc along with a text editor for said files with syntax highlighting. Xcode and Visual Studio both have this ability and including this ability in Xojo would start to eliminate the need for the “Copy Files” build step.
How? You can already drag HTML, CSS, and text files into the navigator. You can then assign their contents to a string property in your code. These are references to the files on disk, so you can edit those files in any appropriate external editor, and have the changes reflected in your project the next time you build or run from the IDE.
How are you using “Copy Files” steps that the provision of a built-in editor would allow you to avoid using the build automation?
You can? Then please have the navigator display icons and include extensions for those files. Currently, when you do drop in a HTML file, it displays as “file” and not “file.html”, and the icons are ones and zeros. This is a little confusing, considering you can do the same with images and have Xojo actually display the images.
Basically, I would want it to function the same as the CopyFiles step, but have the UI function in the way that other IDEs do. Meaning: you could create your file externally, drag it into the navigator and have Xojo open said file in a editor, if Xojo has an editor for said file type, like you can do in other IDEs.
It would end up breaking projects, as there is already a precedent for this behavior.
As Peter said, you can drag in just about anything. At compile time, those files are “read in” as binary and embedded into your app’s source code.
When you drag in “file.html” it creates an object called “file”. At compile time, that “file” is basically a global method returning the binary. You can safely rename the object if you please, without affecting the file on disk.
They do not get copied into your app’s bundle or resources directory. Their contents are in your compiled source.
And that is the fundamental difference, right? With the data in your compiled application, you cannot change them without re-compiling. If, on the other hand, you use an external file, as with the Copy Files automation step, you can change the file’s contents without rebuilding. Each approach has its own advantages and drawbacks. They serve rather different requirements.
I’m not opposed to Xojo having built-in editors for additional file types, but IMHO, there are other things in the IDE which ought to be FOCUSED on by the developers at the moment.
