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!

COMMUTERMODULE
Documented in full in Carl's RevDevX blog.  Conventionally OpenInsight developers have adapted a naming convention of calling their commuter program by a standardised 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

CONTEXTMENU
Historically attaching context menus to anything has been a… non-straightforward procedure. Now that context menus are the same as normal menus it is possible to design them using the Menu Designer and at design time they simply added to the CONTEXTMENU property.





STATUSLINE
Does what is has always done but it is now exposed in the Form Designer.

STYLESHEET
Does what is has always done but it is now exposed in the Form Designer.


MISC
A new property for all controls that just provides a slot for the developer to store stuff at design time and which can easily be accessed and modified at runtime.

TOOLTIP
A new property for all controls that support tooltips. The tooltip designer built into the Form Designer makes it very easy to add tooltips to controls.


Which are then displayed automatically when the user hovers over the control they’re associated with (in this case the Window).




Whilst IOOPTIONS still works, its component parts have been exposed as individual properties self-evidently named. Again, the flexibility to set these at design time removes the need for yet more code!

A couple of new properties have been exposed in here as well.

LOADPREVALWAYS
If this is set to “Yes” then PREV will be loaded on READ as well as WRITE. In other words, default OpenInsight behaviour is to only load the PREV property when a row is written – which only happens if a change has been made. If this is set then PREV will always be loaded (as it is loaded when the previous row is read).

WRITEATRECORD
Documented in full in Carl's RevDevX Blog. This property basically, instructs OpenInsight to write out ALL of ATRECORD not just the controls on the screen. If you didn’t know it did this then we’d recommend reading the article 😊.

When wishing to size a Window to a specific size it could be difficult using the mouse. Now the LEFT, TOP, WIDTH and HEIGHT properties make this a cinch.

INITIALPOSITION
This removes the need for simple centring code, providing you with the nominatively determinative values of “AsDesigned”, “CenterDesktop” or “CenterParent".

TRACKINGSIZE
This is something which we routinely had to code for – to quote the MSDN documentation “The maximum tracking size is the largest window size that can be produced by using the borders to size the window. The minimum tracking size is the smallest window size that can be produced by using the borders to size the window.”. We used this normally to prevent the user from making any changes to the size of the Window – if we’d wanted a different size we’d have designed it that way 😉. By default, this isn’t set, so the user is free to resize the Window as they want. However, we no longer need to use TRACKINGSIZE to prevent this – see later!

VIRTUALSIZE
Intended to be set at runtime by the system when the screen becomes smaller than its intended size.

TRANSLUCENCY
Documented in full in Carl's RevDevX Blog. This simply sets the percentage translucency of the current Window to anything from 0% (completely opaque) to 100% (where’d my Window go?).

SHOWEFFECT
Upon opening a Window, you can now add a bit of theatre to your application. You can now select from the self-explanatory effects of Default, None, Fade, SlideDown, SlideUp, SlideRight, SlideLeft, SlideDownRight, SlideDownLeft, SlideUpRight, SlideUpLeft. As a PowerPoint user I sort of miss chequered et al but…

Note that this won't work on MDI Children or maximised Windows.

HIDEEFFECT
Upon closing a Window you do the same as with SHOWEFFECT. This is actually very handy for emulating popup menus.

Effectively defines the image used by the Window in great detail. But don’t worry most of the time you can just accept the defaults. It’s only if you really want your application to continue looking professional under all DPI conditions that you really have to pay attention to this. It is documented in great detail at   https://revdevx.com/2013/02/07/the-image-api  https://revdevx.com/2014/06/09/the-scaled-event  et al


ACCEPTDROPFILES
A Boolean property indicating whether the Window can have files dropped onto it during a Drag and Drop operation. No more raw style bits to understand and contend with!

CURSOR
Permits the selection of a different cursor for use with this Window when over an editable control. The cursor will be in a file with extension .CUR.

SCROLLMODE
Permits developers to set whether the system pages multi-page windows, or whether it pans them..

SIZINGMODE
Determines whether the user is allowed to resize the Window. If set to “Never” they aren’t allowed. If set to "Always” then they're always allowed. If set to “Default” then the user is allowed if Windows deems it to be appropriate.

TABWITHINPAGE
In multi-page forms, if set to “No”, tabbing off the last control on a page will move to the next page. If set to “Yes” then tabbing off the last control on a page will move to the first prompt on that page.


FRAMESTYLE
This exposes the frame types we were used to in previous versions of OpenInsight. We can have fixed, sizeable or dialog. This doesn’t actually affect the behaviour of the Window, rather it provides the user with a visual clue about the behaviour of the Window. In addition, three new frame styles have been added.

 “None”   No frame at all – good for a panel appearance
 “FixedTool”  Removes the ability to have help/minimise/maximise
 “SizeableTool”  Removes the ability to have help/minimise/maximise

HELPBUTTON
Should a “Help button” be displayed next to the system “Close” button?



Note that this is mutually exclusive with the MAXIMIZEBUTTON and MINIMIZEBUTTON properties.

MAXIMIZEBUTTON/MINIMIZEBUTTON
Whether the Caption should have a Maximize/Minimize button. Note that these are mutually exclusive with the HELPBUTTON property.



SHOWCAPTION/SYSTEMMENU
Exposes these properties both in the User Interface and programmatically.

AUTOCOMPOSITED
CLIPCHILDREN
CLIPSIBLINGS
COMPOSITED

Back in OI 8 the concept of Associated Multi Value (AMV) groups - present in the original Rev C-G - was reintroduced. Basically when designing systems, we, as the developer already know which columns make up an AMV group, so the dictionary was extended to include this information - specifically in columns 36 and 37



One column is defined as being the controlling Multi Value (the "group master") and it (and all other Multi Values in the group) are defined as being part of that group by name. So for example in my CODES table the controlling item CODES looks like this :-

But here is the real beauty of this feature. In X the form designer knows about the group so when painting a new form and selecting the controlling MV I get this prompt


Clicking "Yes" provides me with this entry form


OK, so it's not perfect - the Exclude and Sortkey widths haven't been accounted for correctly BUT it's a vast improvement on the old way of doing things.

There are just so many cute little tweaks in X that are making my life so much easier. I haven't had so much fun in ages!