RBScript opensource site

Back in July, I was wondering aloud how I could help improve RB and whether I should start up and host a testing suite.

Well I had a few abortive attempts at designing the suite and never really came up with a decent spec.

I don't have extensive knowledge of the existing bugs, I don't have consistent access to an Intel Mac and I'm not convinced I could do a good job.

So I was casting around for something I might be able to help with and I came across a few questions about RBScript.

So I decided to set up an opensource site and hope it will make a reasonable contribution to the sum of RBScript knowledge in the RB community.

The site revolves around a subversion repository. I chose this because I make quite a lot of use of TortoiseSVN on Windows and SVN workbench on Linux so I'm reasonably comfortable with it.

I like RBScript and I've used it for a number of personal project, one of which I may tidy up and add to rbscriptjottings but the starting point is new harness project.

This harness will contain a number of RBScript subclasses, some context classes, some RBscript class definitions (some of which should probably be hidden from the RBScript coder) and some sample RBScript code. All this will be organised as mini-projects within the harness program which starts at harness.rbvcp

So far I've dabbled in RBScript subclasses with extensions to

• print methods
• input methods
• error-reporting

I've added contexts which provide

• basic ui (multiple msgbox styles, speak, debuglog)
  
• controlled read/write access to RectControls such as ListBox & ProgressBar
• a reasonable emulation of the RB Date class

Each context currently has its own demo window. I tend to write major class definitions in the constant editor of the appropriate module.

The contexts all need more work but they can all be chained together by making them subclasses of each other and therefore provide access to as much current functionality as is required.

I expect to work on the harness program on and off for quite a while with varying amounts of concentration.

Hopefully, once I've spent a while on it, there will be something for everyone to learn from the site. I've already found out several things I didn't know about the subject at hand.

It is my fervent hope that others will come on board at some stage and add to the RB code and/or to a store of scripts.

The test scripts are in need of lots of rethinking. They tend to be just odd bits of script I used when writing the contexts to make sure they worked. A bit of design effort will need to go into them at some point.

That's one of the advantages of using version control. It's nice and simple to keep making changes without messing things up.

A quick look at the issues list will show that I've got a lot of small things planned for the project. I could easily swamp the list with lots more ideas but I need to see how quickly the current work gets done first.

If anyone has any particular requests or comments, feel free to raise a new issue on the site. Or if you don't have a gmail or google login, leave a comment here.

And of course if you have any contributions to make, please let me know.

A couple of comments before I stop writing:

1. I've used EditFields in the project for backward compatibility and intend to keep them there until Cocoa in RB makes them obsolete.
2. For those who are just curious, I've put a single file (rbp) version of the project at the downloads page. It is the same as the version-control version at the time of writing but I make no promises about keeping it up-to-date. The current source is in the repository.

And so to bed.

Obfuscating

Low-level security is often needed in a compiled app.
Things like hiding a secret string from the casual hacker with a hex-editor.

When the pro edition of RB of allowed me to use IDEScripts, I had a simple script that changed the currently selected code to a series of chr() functions.

Recently, I found a need for a similar facility but I don't have REAL Studio. So I decided to write the beginnings of a standalone app whose purpose is to allow me to generate useful bits of code to paste into the source I am currently developing.

Under these circumstances, I was able to do a slightly more thorough job of hiding the string and making it more difficult for future enhancements to the compiler to optimise my code away.

The general idea is that I give the helper app my password and from it, the code produces a new function with a meaningless name and no reference to the original string.

In the main app, this function uses a MemoryBlock to convert integers in random sequence to a Base64Encoded string representing the password. The function then returns the Base64Decoded version of the string.

I've uploaded the source as part of code.google.com/rbjottings where the whole set of snippets can be downloaded by SVN or you can look at the source for these routines at obfuscateTest Window1 because all the code is contained in that window.

The methods involved are

Function generator _
(inText As String, ByRef functionName As String) As String

Function randomIdentifier _
(minLength As Integer = 6, maxLength As Integer = 10) As String

which are called using code like

dim fName As String
taCode.Text = generator( tfPlainText.Text, fName )
if chkAddcaller.Value Then
taCode.Text = taCode.Text + EndOfLine + EndOfLine + _
"Sub Caller() " +EndOfLine + _
" Dim s as String = " + fName + "()" + EndOfLine + _
"End Sub"
end if

where taCode is a TextArea and tfPlainText is a TextField

Obviously this simple obfuscation is completely useless where real encryption is required.

However, where the aim is merely to hide slightly sensitive information from prying eyes, this will force them to work much harder to find the string.

How can I help improve RB?

When I was developing large apps for other people to use, one of my recurring nightmares was that old bugs, once fixed, would return in a future version and make me look unprofessional.

Consequently, one of my most important tools was an ever-growing suite of test scenarios which I ran my app through before issuing a new release. I also asked my beta testers to run these scenarios where practical.

It seems to me that if my app were a programming language, this sort of suite would be particularly easy to produce.
No doubt RS have an extensive testing suite but they don't make it public for users to test. Also, I sometimes wonder if they share my nightmare.

I keep wondering about starting an open-source project which would host tests of current and previous bugs.

• Have I the time and enthusiasm to produce the original framework?
• Do I know enough about the current bugs?
• Would someone else be more appropriate as the project owner?

Of course, there was Joe Strout's excellent ROTOR which ran several tests that could be automated and which many of us ran on each new beta and release for a while but those tests all seem to pretty much pass these days (except the encoding of external files) and it has fallen out of sight.

My preference now would be for something that runs unit tests where possible but which also includes tests which required user-involvement.
There would be a project (or projects) with windows describing what the user needed to do and what result was being looked for.
This would allow tests to be run on as many platforms as possible by beta testers, new users and anyone who starts using the latest version.

Hopefully, if there were user reports quoting problems found by the testing suite, RS would be able to check it out for themselves.

It seems to me that this would be a more positive step than just producing a list of bugs.

Perhaps I'll manage to get this started at some point. Or perhaps someone else will come up with the idea and the enthusiasm first and run with it.