OML has been a minefield with its instability and it's quirky and widely undocumented features. When you get in you basically gets awestruck by the number of Classes, Events, Methods, Properties, Functions, Commands etc.
"Real" programmers might have got stuck into it and used it but most people find it just one step to far and to complex, and when it mostly ended up corrupting your application beyond repair one took one step back and wrote it off as another "good" attempt.
In 8 we have tried to make the use of OML unnecessary by creating functions that can be used anywhere in the app that do the same. What most people used OML for was to hide and show fields/buttons, push values into fields and change colours so we have added SetState(), SetColor(0, SetFocus(), SetValue() etc. All these functions you can use in ExecDQL() (and ordinary DFW DQL with care), BRL(Field derivations i.e. virtual fields etc) and in OML ;-)
In 8 we have fixed and improved DFW extensively, so suddenly OML too seem to be working as it should. We had mentally written it off, but when working on the sample apps for the upcomming DE8 release, we found some things that only OML can do and that is Events.
The funny thing is that Events or rather the Event model is the problem for people using OML for all the stuff that we now do with functions simply because it feels unnecessary that doing these things need to be controlled by an advanced matrix of events. Why do I have to chose when and how changing the colour of a label should happen?
And why is it so difficult to change the colour on that event: (example).
CreditBox.Fill.Color.Red := 255 .
CreditBox.Fill.Color.Green := 0 .
CreditBox.Fill.Color.Blue := 0 .
CreditBox.Redraw := 1 .
For lines of dot notation code just to set the field background color Red. Then you Have Credibox.Border.Color.Red, CreditBox.Font.Color.Red etc..
Completely illogical to a normal human being, and that is who DataEase was meant to be for.
So now you can use the function SetColor() and set all the colours in one go in one function on a object. The nice thing is that you can of course also use this function in OML...
So now that we have removed all the primary needs for OML, we can look at it with fresh eyes and see if it need to be there at all. In our mind OML as a language should not be there (but it is and will be in Classic for compatibility reasons), but what we need is the events, and now that we can make effective code in OML (DQL) we can simply use its strengths - EVENTS!
The OML editor is a mess and we will look into that but for now we will simply inform you on what works:
Form Object (name of form)
We will list the ones that is usefull first, then the ones that works and then the ones that doesn't work:
This is obviously a very useful event where you can load any code that you always want to be executed before anything else when you open a form. This event is always called and it doesn't matter how you open the form.
Same as OpenForm. Place all clean up code you want to happen when you close a form.
All the mouse and keyboard events.
DeleteRecord and all the record stuff
Got and LostFocus
But in reality what you should take with you from the Form object is OpenForm() and CloseForm() everything else is just meaningless and should be dealt with further down the object tree.
Record Object (Record or Record1)
All the mouse and keyboard events.
Just forget about...All this promise and no delivery.
Field Object (EditBox)
All except ValueRequired() which is meaningless anyway....
Label Object (Text)
All. It will never get focus but you can force the Focus with SetFocus().
Button Object (Button)
Now the good stuff...
OML is not OML... it is ODQL i.e. it is really what DQL was supposed to be in DFW. All this focus on dot notation, classes, methods, properties etc has removed the view from the really useful stuff....
THIS IS SIMPLY DQL!
So you can write a DQL here and execute it on a useful event like Form Open or form Close?
What is not sexy about that?