New Releases: SRP Editor 3.2 and SRP Utilities 2.1.7
The SRP Editor adds code folding and the SRP Utilities gets a couple minor improvements.
SRP Editor 3.2
The SRP Editor now supports code folding. A lot of work was put into this feature to ensure accurate recognition of BASIC+ code blocks and SRP’s Extended BASIC+ blocks, such as Service…End Service. When you open your code, you’ll see folding markers along the left-hand side.
And when you collapse a fold, you’ll see ellipsis at the end of the line to make it clear that there are hidden lines.
The SRP Editor will fold standard multi-lined code blocks: If statements, Case blocks, Locate statements, Loops, and even block (/*…*/) comments. It will also fold the main program, GoSubs, Services, Events, etc.
The SRP Editor also supports #region…#endregion folding. This new syntax allows you to create custom folding regions so you can better organize your code. Moreover, these regions will appear in the Ctrl+L Label DropDown list so you can quickly navigate to them.
You can expand or collapse all folding points by right-clicking in the margin and selecting the desired action.
There is a caveat to this feature. In order to accurately identify folding points, the SRP Editor now has to fully parse your code when it is first opened. Previously, it only had to parse what was on the screen to colorize it, but you can’t create a folding point without analyzing where that fold will end. As a result, there is an increased delay in opening stored procedures, which is more noticeable when you open several large documents at once, such as during startup.
In fact, since starting up the SRP Editor is taking longer these days as we add new features, we’ve added a small splash screen so you know what’s happening.
If you feel that code folding just isn’t worth the performance cost, you can turn it off in the Options window.
The Options dialog also lets you limit how deep the folding goes. If you set Folding to “1 Deep”, then you will never have a fold within a fold. If you set it to “2 Deep”, then you will have folds with folds, but not folds within folds within folds. You get the idea.
You can download this release today and see how code folding can work for you.
SRP Utilities 2.1.7
The SRP Utilities got a small update today as well.
First, the SRP PreCompiler got an improvement. When you use Extended BASIC+ to create service or event modules, behind the scenes, the precompiler converts statements like GoToService into a bunch of standard BASIC+ statements that ultimate rely on On…GoSub. It came to our attention that On…GoSub is limited to 255 labels. Sadly, going over this limit does not produce a compiler error, so breaching that limit can lead to bugs which are difficult to isolate.
SRP Utilities 2.1.7 works around this limitation by using as many separate On…GoSub statements as needed, wrapping them in a Case statement. In short, just do what you’ve been doing and don’t worry about secret BASIC+ limits anymore.
This release also fixes an oversight in SRP_Json in which object keys were not getting properly escaped.
SRP Utilities 1.2.7 is available for download now. As always, the latest SRP Utilities is included in our SRP Editor installer, so if you install the SRP Editor, you’re all set.
Release Early, Release Often
SRP Computer Solutions, Inc. is adopting the philosophy of release early, release often for many of our products. Follow us on Facebook or Twitter to get notified every time there’s a release.
Given that we are a small community, we have the luxury of quickly providing enhancements and fixes to our customers. Sadly, we’ve not taken full advantage of it. For too long, we’ve let a product languish for weeks in pre-release mode, not wanting to flood our customers with updates.
New Version Numbering
Our first step in correcting course is to change our version numbering schema. We used to use the semantic standard, which was Major.Minor.Patch.RC, where RC stands for Release Candidate. Thus, 2.0.1.1 would really be 2.0.1 RC1, which indicates the first pre-release build of 2.0.1. Once the 2.0.1 is deemed stable for release, it’s version becomes 2.0.1.0. The problem is that 2.0.1.0 ends up being newer and more tested than 2.0.1.11.
Our new version number system uses Major.Minor.Patch.Build. Thus, larger version numbers are always newer than smaller ones. Here’s how we plan to increment our version numbers.
Major
Major increments under the following conditions:
- The product is not entirely backward compatible, i.e., there are breaking changes on the customer’s end. For example, moving from OI 9 to OI 10.
- There are so many significant additions that it feels like a new product. For example, we moved to SRP Editor 3.0 after adding unit testing and code templates, which significantly altered the UI.
- The underlying code base of the product was significantly refactored or entirely rewritten. For example, SRP Utilities didn’t offer many new features in 2.0, but it had been entirely rewritten so it could support 64-bit and OI 10.
Though we will manage expectations, customers should not be surprised if you need make changes in your own software to adopt a major version change.
Minor
Minor increments under the following conditions:
- There are new features. A feature is anything that is an addition to the product rather than an update, such as new components, user interfaces, module, or APIs. For example, a new service module called SRP_Date would be a new feature of SRP Utilities.
- There are a few significant updates or many small updates. An update is anything that adds to existing features. For example, a new service added to SRP_Date called “AddMinutes” would be an update, not a new feature.
Customers should expect new features when they see minor updates.
Patch
Patch increments under the following conditions:
- There are bug fixes.
- There are a few small updates.
- The code was refactored, perhaps for performance gains or platform compatibility reasons.
In general, customers should expect that the higher the patch number, the more stable and vetted the Major.Minor version is.
Build
The Build number might differ from product to product. It might be a date or it might be a number, but larger numbers will always indicate new builds. It increments when there are no logical changes to the product, or we are providing builds for testing. An example would be when an RDK is accidentally shipped with a missing component and needs to be rebuilt. It’s not really a change or fix to the product, just a mistake in the build itself.
Moving Forward
As indicated in the introduction, we’ll be posting to Twitter and Facebook every time there is a release. Sometimes, we’ll post a blog article on the update, especially if it contains a new feature that warrants a deeper explanation. In all other cases, we’ll tweet out the list of changes and a link to the product page.
Recent Releases
Here are the products we’ve released in the past few weeks without having announced on our social platforms. This will catch you up.
SRP ActiveX Controls
4.1.10
- EditTable. Added ClickOption method
4.1.9
- DirectConnect. Fixed bug where OnMessage would sometimes crash
- Schedule. Updated net code to better isolate UI thread from networking thread
4.1.8
- ReportTable. Fixed bug where ColumnHeaderFont would not work for some themes
4.1.7
- Subclass. Fixed bug where subclassing MDICLIENT would crash in OI 10
SRP Editor
3.1.4
- Fixed bug where new or blank record would have an empty margin and produce an error when pressing enter.
3.1.3
- Updated IConv/OConv context menus to better recognize legitimate conversions
- Improved record loading/editing speeds, especially for large records
- Fixed bug where Favorited records would sometimes reopen in Forced Readonly mode
- Fixed bug where Open Record dialog would not highlight correct field when opened
- Fixed bug where License screens would sometimes appear when they shouldn’t
3.1.2
- Updated editor to automatically insert SRP PreCompiler if unpacking syntax is detected (and auto-insert is enabled)
3.1.1
- Added option to disable auto-insertion of SRP PreCompiler
SRP Utilities
2.1.6
- Fixed bug in SRP_Run_Command where output would not go into variable if it was too long
New Releases: SRP Editor 3.1, SRP ActiveX Controls 4.1.6, and SRP Utilities 2.1.5
We have a few new releases to announce today. The SRP Editor does formatting magic, the SRP ActiveX Controls get a new set of clothes, and SRP Utilities gets more date and time support.
Continue readingNew Releases: SRP ActiveX Controls 4.1.5 and SRP Utilities 2.1.1
SRP ActiveX Controls 4.1.5 gets minor fixes and SRP Utilities 2.1.1 gets a major new feature.
Continue readingNew Release: SRP HTTP Framework 4.0.6
Wow…it’s been almost three years to the date since we announced the general availability of the SRP HTTP Framework. Don’t let the time gap fool you. This product has continued to go through ongoing updates and enhancements with new versions coming out on average every 4 months. Our only excuse for not posting additional notices to our blog site is that we’ve remained very busy building and supporting RESTful API solutions for our clients. It has been quite satisfying to see the diverse ways that we have been able to integrate OpenInsight’s flexible data engine, robust business rules language, and universally recognized and respected REST APIs.
New Release: SRP Utilities 2.1
SRP Utilities 2.1 was released today, providing a handful of new services and routines alongside a couple improvements to existing ones.
Continue reading
New Releases: SRP Editor 3.0.3, SRP ActiveX Controls 4.1.4, and SRP Utilities 2.0.6
We have three new releases today. The SRP Editor gives the SRP Table Search utility a little TLC, the SRP ActiveX Controls get a few fixes, and the SRP Utilities get a new feature.
Recent Comments