Support text-based source code - abylity to use SubVersion, etc.

Hi all,

My feature request is on source code management: to support text-base source code.

WinDev looks like a black-box when doing code. Since the output is only a big-binary-blob then it's impossible to use external source managers. The one provided with WinDev has its limitations and pitfalls. (In fact, this is a nightmare to use it in team work and even when only one coder is working with it. I try not to use it as much as possible.) This is also impossible for two coders to work in the same object then merge the changes.

I would have like a text-base support for the source code so that it becomes very efficient to create forges, share code, and use other tools to manage the source code (that are specifically built for that job.)

This is so simple to implement: BigBinaryBlobToTextSource(), TextSourceToBigBinaryBlob(). Simply recompile the differences. Then leave the coder use the mean he want to manage the source. WinDev uses the binary form be defaut, but if the TextSource feature is "on" it also save as text when a change must be saved. Or simply save as text when asked by the user. Then an agent should detect if the TextSource file has changed (simple) due to a SVN update, etc. If so load back the changes and update the binary representation.

So you loose no speed to debug and can share the text version of the source. So building a real forge. This would also "free" the language. They could even have a free compiler for open-source projects... but it might not be a good idea for their market.

In the Express version, simply remove the feature, but allow such a feature in the complete version. Team work would be much better, and forges and contributions too. One could work off-line for days then come back in push the chages.

Then a project could look at the text version, compare, and update the binary equivalent (recompile) on any change.

This is the most amazing feature I would like to see (since day one with WD11), but in which I've completely lose all hope.

I thought to send a big PDF analysis of the feature to PCSoft as a serious request, but I doubt they would see that as an interesting feature. (I see many advantages, even from a marketing point of view, but...)

Best Regards.

Hi Alexandre,

I agree!

And I would be quite happy for even simpler solutions aiming towards similar goals, like:

- an include command to include source code from a text file, starting from a label and ending to another label: include(sourcefilename,startlabel, endlabel)

- parameterize the name of your favorite text editor in Windev - which could then be called with a hot key of your choice (Control-E?:-) to edit the includefilename nearest the cursor.

Currently (2010, WD14) I have to do a lot of cutting and pasting between external editor(s) and Windev's editor, because Windev's text editing features are not sufficient. Especially lacking in Windev are square text block (or column) operations and the possibility to "paint" any characters (to be selected from a character table) to any possible cursor direction (up, down and left). "Painting" to right already exists in every editor, even Windev's:-). Those who have used the Clarion Professional Developer's code editor CEDT.EXE from the 80's know what I am talking about.

Of course using external plain text files brings some limitations, like the internationalizing of messages should then be made either by switch commands or calls to translation procedures, instead of the embedded secret code hidden somewhere in Windev's endless depth. But I don't see this as a problem, and have already done so since my day one with WD.

regards
Ola
[www.pienoismalli.com]

I would agree. For me it even does not have to go that far but have some functions to implement a kind of RAD for myself would do a lot for the code i am writing. Now i have to click a lot to make a new Class or a method/property for that class. There are as far as i know not even hotkeys for this! So let them start with that. Ill macro the rest until they make it more open.

But on the side of having plain text files. It does not even have to be that complicated. If they serialize every file to a XML file they would already have a plain text file system. It would be slow but it should work in no time.