Well, it IS possible. Just save it as an XML Project. Studio will export a single XML file containing all code. I know it isn't an ideal solution, but that's what ya get with RS.

I only wish Real Studio / Xojo was more "professional" with these sections of the IDE. For example, in every other IDE available, each form gets it's own code file where all actions and events are stored. The same is for when you create a class file. There's a whole code file ready for your code. None of this adding methods, properties, events etc.

Hi,I remember seeing on these forums, a post about exporting a project's code to a text file somehow, but I have searched the forums and can't seem to find it.

Could someone please advise me if this is still possible, and if so how.

Thank you all, in advance.

If you're running Windows, one way to export a project's code to a text file is to use File --> Print, having first installed a "Generic / Text Only" printer to your computer.

It's not really a physical printer. It simply allows a Windows user the freedom to "print" to a disk FILE. The "file" it prints is plain text ("text only"), which means that it's not anything fancy like PDF, but in this situation PDF (in my opinion) is over-kiil (and over-long) when all you ordnarily want is plain text.

I suspect there is something similar to "Generic / Text Only" that can be done on Linux or a Mac, but I do not (yet) have any real experience with those two platforms.

One option that can be used on any platform, however, is (as someone has already mentioned) to save the project as an XML file. That is a very powerful approach, but it has two significant complications if all you want is export a project's source code to a text file: (1) it intermingles the source code with other information related to the project (but probably unrelated to your posted purpose), and (2) and it contains no information on indentation of the source code.

Both limitations, however, can be easily overcome, but let me explain them a bit first. First, you may not have thought about it, but RB programs really have two parts. On one of its menus, RB calls the two parts "Edit Source Code" and "Edit Window." Even though we often think only of the source code, what is not source code is equally important to the project. You couldn't have the project without it.

If you want to extract the source code from the XML file, it's not difficult to do. You can easily write a short program of half a dozen lines to do that. All the program has to do is to discard entirely the lines that do not begin with "<Source Line> and then from the remaining lines discard "<Source Line>" at the beginning and "</Source Line>" at the end.

What's left is the source code. One problem: you do not have the indenting that you ordinarily expect. You have to do the indenting yourself OR you can use a program someone else has written to extract the source code AND to add the appropriate indenting.

Such a program (free with free source code) is my CodeHelper, which you can get at http://traver.org/ch/ch115.rbp. In addition to extracting and formatting source code and allowing you to save it as a text file on disk, it does a lot more, since it doesn't look only at (source) code, but takes advantage of other information in the XML file, i.e., "Window" information in addition to "Source Code" information.

If you are ONLY interested in exporting a project's code to a text file, you don't need something like CodeHelper. It's a lot easier to just use File --> Print to a "Generic / Text Only" Printer (or its equivalent) to "print" a text file on disk. But with CodeHelper you can analyze or modify that part of your program which is NOT in the source code, and which is equally important to the source code.

The question is, Why do you want this? When I first started with RB, I worked out a mechanism to get all the code in a single file. It's what I was used to seeing and I thought it would be useful. After a few short months, I got acclimated to the IDE and I quickly abandoned the idea. Having all the code in one big file was too unwieldy and overwhelming. I really like the way the IDE presents the code. You can focus on one thing at a time.

I'm not saying the request isn't valid, but anymore, the only reason I see for a textual representation of the code is for version control.

There is no particular reason I wanted the code as a single text file - apart from the fact that I thought I could simply study the code at a glance and see if any code could be rewritten more efficiently.

The question is, Why do you want this? When I first started with RB, I worked out a mechanism to get all the code in a single file. It's what I was used to seeing and I thought it would be useful. After a few short months, I got acclimated to the IDE and I quickly abandoned the idea. Having all the code in one big file was too unwieldy and overwhelming. I really like the way the IDE presents the code. You can focus on one thing at a time.

I'm not saying the request isn't valid, but anymore, the only reason I see for a textual representation of the code is for version control.

Tim,

I agree with you. I also like the way the IDE presents the code. It divides code and related information into various categories, AND in the IDE each of the categories (including event handlers, menu handers, user-defined methods,...) is in alphabetical order. The XML format also uses several separate categories, BUT it does NOT put them into alphabetical order. (If you want each category to be in alphabetical order, you have to put it in order yourself.) Nor does the printout of the source code put each of the categories in alphabetical order.

When you print out source code from the IDE and when you save the Project as an XML file, my guess is that there is an order: it's just not alphabetical. My guess is that functions and subs, for example, appear in the order in which they were created or modified.

When you are looking for a particular method, you thus have to use Search (which at least is better than looking at a non-alphabetical collection of items). BUT you DO have items placed in alphabetical order within the IDE itself, which can save a lot of time when a Project contains hundreds of functions and subs.

My purpose in this note addressed to you, however, relates to your statement that "the only reason I see for a textual representation of the code is for version control."

To me, the main advantage of a textual representation of the code is that it is human-readable. Look at a Source code file (or even an XML format file). It makes sense (although, admittedly, an XML file is more difficult to follow). (We probably agree here.)

And here is my question (and it is a question and not a disagreement; I just want to know what you mean). What does "version control" have to do with "textual representation"? When I save a Project in VCP format, I don't get "text." I get a bunch of files that Windows doesn't even know to open, much less to show me meaningful text. As I understand it, I need some additional program (e.g., Subversion or Git or SmartGit?) to get meaningful textual information when I save something in VCP format.

Is your point that in itself VCP format lacks human-readable "textual representation" and needs something separate to get that? Or are you saying something else entirely? (Probably the latter and I'm just not following.)

If I don't understand, it's not your fault. I've just never really understood "version control" or how to use it.

That may not be the best solution for those using Windows. Now, I don't use PDF because (1) when it checked PDF cost extra money for Windows and (2) PDF was a larger file with (in this situation) no advantage I could see over, say, printing from the IDE to "Generic / Text Only/." (But things do change, and I haven't really kept up-to-date on this.)

Install a printer driver like PDFCreator (or any of the others - there are lots)Then print your project - select that printer driver & away you go - a PDF and you have not "converted" the project at all.

Thanks for the recommendation. It looks like CNET agrees with you. Here's what they had to say in a review published just last month (April 2013):

Quote:

"Tools for creating PDF documents tend to fall somewhere between do-it-all packages with big names (and price tags to match) and freeware stripped down to the basics. But simple is good, which is why PDF tools that install themselves as print drivers may be our favorite of all. That's how PDFCreator from Pdforge works, though that's not all it does.... [T]he standard installation ... includes some optional downloads .... We chose all the extras and opted to add the tool to context menus as well as the Print menu. If you can print a document, you can use this tool. The steps are the same, with a screen full of fields to let us easily add Title, Author, Keywords, and more. You can also edit a document's Creation and Modify dates or instantly add the current date and time. Once you're finished, you can save, print, or e-mail your newly created PDF. PDFCreator creates more than PDFs, though, with the option to convert and save files in 13 formats, including bitmap, PostScript, and others. PDFCreator is easy to use yet creates high-quality PDFs and many other document types from the Print command or shell menu for free. If that sounds like a recommendation, it is.