There is much more digital ink that could be spilled exploring all of the changes and capabilities of the product. In time, we might also contribute to the body of work that already exists. But for now we don’t want to crowd the space with information that is already in print or might already be forthcoming by other sources. Instead, we thought it might be worthwhile to offer a list of our favorite changes from a very specific perspective: productivity. As some of our readers may recall from our first blog post in 2018, productivity is one of our core philosophies. It informs the way we develop applications for our clients and it is a key grid that guides the way we build our tools. Therefore, we are quite happy to share how OpenInsight 10 is achieving these goals. Without further ado…
One of the design intents of the new IDE is to eliminate the need for running multiple external tools when building elements of the application. Without a doubt, OIX’s new IDE has made this possible for virtually all core entities. Still, there are times when multiple IDEs is better (especially for those with multiple monitors) and thankfully OIX provides this as a dropdown menu option:
Now it is possible to have one primary IDE for things like UI and Database entities while maintaining another IDE for code. A nice touch is the use of the new TASKBARID and OVERLAYICON properties to force all instances of the IDE to appear ungrouped and unique in the Windows Taskbar:
Another advantage of having a separate IDE for code is that all the unnecessary panels can be turned off thus providing maximum work space.
Recently Don Bakke at SRP published a very helpful blog entry highlighting just how much more productive it is possible to be in OI X – and he is SO right. Over the years, as more and more properties were added to the Presentation Server, the Form Designer struggled to keep up. So internally the Presentation Server had its list of properties and the Form Designer – being a separate executable – had its own list of properties which wasn’t really ever added to. The knock-on effect from this was that if you wanted to achieve certain things using the new properties you HAD to cut code, and cutting code takes time, it adds to the maintenance burden and it introduces a potential point of failure.
This post is going to highlight the new properties in just the Windows control that remove some of the coding burden from the OpenInsight developer. To make it easy to follow we’ll deal with the properties in the order in which they’re found in the property panel in the Form Designer. When properties are trivial we’ll describe them en masse to save wasting blog space!
Documented in full in Carl's RevDevX blog. Conventionally OpenInsight developers have adapted a naming convention of calling their commuter program by a standardized name (such as the Window name or the Window name with a suffix) so that they can easily identify the program for maintenance reasons. By having a COMMUTERMODULE property the developer can use whatever name they want. For example they could use the same commuter program for a logically related set of Windows. By having just one tried and tested code block used across multiple entities, this is yet another area where OpenInsight helps developers to have fewer lines of code to maintain and the minimum possible potential failure points.