Tips_classictostudio > Classic to Studio
There are many differing opinions on how to make the move from Omnis Classic to Omnis Studio. The documentation in this section provides suggestions and tips for moving from Omnis Classic to Omnis Studio.
If you have never used Omnis Classic, the information in this section is of no value to you.
My personal opinion is that you should rewrite your application in Omnis Studio rather than convert your Omnis Classic application to Omnis Studio.
Omnis Studio is an object-oriented programming development tool. If you convert an Omnis Classic app to Omnis Studio using the converter tool you will end up with non object-oriented code inside of an object-oriented programming development tool.
Also, if you aren't already using SQL, do yourself a favor and move to SQL at the same time.Back in 1999 I was faced with the decision of whether or not to convert my existing Omnis Classic app to Omnis Studio. I tried using the Classic converter tool which Omnis Studio provided, but I ended up with all my (ugly) Omnis Classic code inside Omnis Studio and was faced with fixing, debugging, and supporting old legacy code. I thought long and hard about it and in my heart I knew that a rewrite was the right thing to do.
The other issue I faced was that the Omnis Classic app was not using SQL, it was limited to the Omnis data file. A fellow Omnis developer told me to make the move to SQL. Learning SQL took some time, but looking back, switching to SQL was a very important decision. Several years later my Omnis data file had grown to 4 segements and I had to move from to a real RDBMS (FrontBase). Because I had switched to using SQL when I started with Omnis Studio, moving the Omnis data file to FrontBase was very easy to do.Omnis Studio has Omnis Classic roots because Omnis wanted to make it possible for Omnis developers to convert their existing Omnis Classic libraries to Omnis Studio.
There are several non-object-oriented types of classes in Omnis Studio that you should not use.
The hash variables, #F, #S1, #L1, are variables which I used extensively in my old Omnis Classic app.
Don't use hash variables in your Omnis Studio app. Hash variables have global scope. The object-oriented police frown on the use of global variables... for good reason.
If you open two Omnis Studio applications with the same instance of Omnis Studio, or you move your code to a multi-threaded web app, or if Omnis Studio becomes multi-threaded, those global variables are going to give you grief. Trust me, it takes very little time to create a local variable or instance variable, and your code will be stronger for it.
Use the narrowest scope of variable possible for each situation. If you can use a local variable in a method do so.
Avoid using class variables unless you have a good reason for doing so. The only place I use class variables is for remembering user prompt values. If I prompt the user for a date range of records to include in a report I'll use the class variables cDateFrom and cDateTo. If the user decides to reprint the report, when the prompt window reopens the last cDateFrom and cDateTo values that they entered will be displayed because class variables hold their values.In Omnis Classic we could instantly flip from editing a window class to viewing it. This does not hold true in Omnis Studio. You never really see a window class, you only see instances of a window class.
An instance has to live inside of a task. Because there can be multiple tasks, Omnis Studio doesn't know which task to instantiate the window class instance inside of. At first this can be frustrating, but don't fight with it. Get used to the fact that you must open a window class as an instance inside of a task instance.
I always include a menu line in the main menu of any applications I write. Go ahead and select the menu line in the StudioTips menu. You will hit a Breakpoint followed by a Quit method. When you are at the Breakpoint you are inside the tipsBase task instance. If you add the following line of code...
Do $clib.$window.wTipsBrowser.$open('*')
...below the Quit method and double-click on that line to set the point, and then click the button, you will open a second instance of the window. Go ahead and try it.
Using a in a main menu which is opened by your library's Startup_Task $construct method you will be able to instantiate any class (window, report, table, toolbar) within your application's task, and send messages (call public methods), to test code.
Being able to open instances of classes is an important feature of object-oriented programming. Instances allow you to reuse classes and have multiple instances of the same window open with different records in each window.There are a series of Omnis commands that begin with the word Set.
Set current list
Set current session
Set current data file
Set timer method sec
Generally you should avoid Omnis commands that begin with the word Set. The reason is because they are global. As you read previously in the topic, the object-oriented programming police frown on the use of anything global. Even if you get away with it, some day these global Set commands will come back to haunt you.
In Omnis Classic if were looping through one list, and inside the loop we would go off an search another list, it was crucial to remember to set the current list at the beginning of each method in a reversible block.
Begin reversible block
Set current list List
End reversible block
The reversible block at the beginning of the method will restore the previous current list at the end of the method. Having to keep track of current list, current data file, is a pain, and the code is fragile.
Omnis Studio is an object-oriented programming development tool so it provides you with non-global ways to loop through lists and do the things you were accustomed to doing with the Omnis Set commands.
For examples, here is how you can loop through a list using Omnis notation.
For List.$line from 1 to List.$linecount step 1
; The current line in the list is incremented each time through the loop.
; You could call 100 other methods which loop thorugh other lists
; and never have to worry about which list is the 'current' list.
End For
In Omnis Classic I was used to writing window classes which were modal. Modal meant that the user was trapped with the window until they finished whatever they were doing and closed the window. The built-in OK, Yes/No, No/Yes, Prompt for Input messages are modal prompts. Writing code using modal prompts is fairly easy. Code execution is halted until the user deals with the prompt, after which code execution continues where it left off.
Modeless windows do not trap the user. The user can bring them to the front, move them to the back, open an other window, run a report, and return to the modeless window whenever they like. Users like modeless windows. Web applications are modeless.
When I switched from Omnis Classic to Omnis Studio I immediately switched to modeless windows, but I still used modal prompts. After 5 years of writing code in Omnis Studio I started writing Omnis Studio web apps (using JavaScript on the client side). As I started to write these web apps I finally saw the importance, and benefits, of writing code that uses modeless prompts. The trick with modeless prompts is that you have to give the modeless prompt a call back method. If and when the user clicks the button on the modeless prompt, the prompt sends a call back message passing along the input parameters.
You have to break your old modal code into two parts (method).
Typically I add the suffix _continue to the call back method. Here is an example.
The object-oriented world makes a distinction between visual class and non-visual classes. The distinction is very important in helping you decide what code and things happen in which classes, and more importantly what doesn't happen in non-visual classes. Non-visual class methods tend to be easier to reuse, so you want to put the majority of your code in non-visual classes.
In Omnis Classic I would put lots of code in menu classes and window classes. These are visual classes.
In Omnis Studio you want to put the majority of your code in object classes. Object classes can be instantiated by all the other visual and non-visual classes that can be instantiated.
If you haven't already done so, go through the Studio 100 series tutorials. Studio 103 gives you some practical hands on experience with visual vs. non-visual classes and writing non-visual code.If you are moving from Omnis Classic to Omnis Studio I encourage you to take a look at StudioWorks. I switched from Omnis Classic to Omnis Studio in 1999 and have been writing applications full time with Omnis Studio ever since. With the StudioWorks framework you take advantage of the collective experience of the StudioWorks developer community. Many of the Omnis Studio developers in the StudioWorks community have been, or are going through, the transition from Omnis Classic to Omnis Studio. An Omnis data file converter has been built to convert non-SQL file slots to SQL tables adding primary keys and foreign keys. There are StudioWorks developers, including myself, who can help you with the transition.
StudioWorks provides you with a pre-built, tested, and debugged set of classes that are ready to go. StudioWorks ships with a StartNewApp set of files that is a ready to go Omnis Studio application. It includes a test database, sign-in window, main menu, main window, error handler, autoconfig list and edit windows, and tons of other features. You create schema classes, add meta-data, declare the window instances, and the StudioWorks framework creates the database tables and generates the windows for you. When you create an application in StudioWorks it automatically supports deployment in multiple languages without changing a single line of code.
StudioWorks will make the move from Omnis Classic to Omnis Studio, object-oriented programming, and SQL much easier to accomplish.
For more information visit www.studioworks-dev.net.