Tips_todo > Misc > Code Classes
In a word ... DON'T USE THEM (Okay, that was 3 words) Exception: (There's alway one) See "Error Handler" topic in this section.
When I started learning Studio I tried object classes and said to myself, "This is too hard, Code Classes are much easier to work with and call, I'm sticking with code classes". Six months later at my first Omnis Conference, Geir Fjaerli convinced me to use object classes. He was right. "Anything you can do with a code class, you can do better with an object class."
Code classes are a slippery slope that draw you away from object-oriented programming, and back into Omnis Classic style coding. (There is a difference.) Omnis software will admit to you they only included code classes to make it easier for converting from Classis to Studio. I was told the original design of Omnis Studio did not include code classes.
PROBLEMS WITH CODE CLASSES
Code classes don't extend instances. I discovered this when in a code class method I defined a List from a table class using ($definefromsqlclass) and then called a method in the Table class. Everything worked fine until the table class needed the value of a task variable. Oops, it was out of scope!!
Code class can't have private methods, all methods in your code class are public.
As you get deeper into object-oriented programming (OOP) you will discover the importance and beauty of having public vs. private methods.
Public methods start with $
Private methods do not start with $
SUMMARY
Don't use code classes. Use object classes instead. Anything you can do with a code class, you can do with an object class ... better.
If you are coming from Omnis Classic, object classes will seem like a pain at first. But stick with them, it is worth the effort. Object classes will provide more powerful and elegant solutions.I added Craig's Error Handler code to StudioTips so that you can use StudioTips to check for notation errors in any of your libraries.
A menu item has been added to the "Tips" menu to Load/Unload STP' error handler (all libraries.)
If you always have StudioTips open when you are developing, you can use STP' Error Handler to trap errors for you. Feel free to modify the "cErrorHandler" code class to suit your needs. Let me know if you want any enhancements to the StudioTips Error Handler.
I had some problems getting the StudioTips error handler to trap bad notation in other libraries.
Tech Support looked at the problem and recommended adding a "$" prefix to the code class method name. This appears to have fixed the problem.
Normally when you receive a new version of StudioTips, the Tips menu error handler item will read "Load Error Handler", meaning that it is currently "Unloaded". If you select the menu item the error handler will be loaded and the menu item will change to "Unload Error Handler". StudioTips remembers the last "state" of the error handler when you close and reopen StudioTips.
I ran into quite a number of "bug reports" from developers who were using the error handler. Some of these "bugs" were related to notation errors in OMST's code. Tech Support confirmed that there were some notation errors. The solution was to add some exceptions to the error handler in StudioTips.
The Error Handler certainly helps you write "clean" code. If catches you if you try call a method that does not exist.
STUDIOTIPS ERROR HANDLER DEMO
To test the error handler try the following:
1. Tips menu> select Load Error Handler. (If it isn't already loaded.)
2. Tips menu > select Programmer Test Method. This takes you to the "Breakpoint"
3. In the method editor IDE, Stack menu > select "Clear Method Stack".
4. Add code after the breakpoint, so the Programmer Test Method > $event method code reads as follows:
------- START CODE ---------
Consider anything below this line to be your "code scratch pad".
Breakpoint
Do $cinst.$CallMethodThatDoesNotExist()
Quit method ;; This line is for safety to prevent accidental execution of the Programmer Test Method.
------- END CODE ---------
The line "Do $cinst.$CallMethodThatDoesNotExist()" is obviously "Bad Notation"
5. Tips menu > select Programmer Test Method, take you to the "Breakpoint" again.
6. Click the running man icon in the top left corner of the method editor.
7. The Error Handler should trap the "Bad Notation". If it doesn't trap the error close the TIPS library and reopen TIPS. Repeat step 5 & 6. I haven't quite figured out what causes the error handler to miss errors. Sometimes it will catch an error on the first pass, then later when you rerun the code with the same error it occassionaly skips reporting the error a second time.
8. When you hit the error message, read it, then click OK. You will be at a "Breakpoint" in the error handler. Use the "Stack" menu to get back to the "Bad Notation". Select "Tips.mTips/Programmer Test Method/$event" in the Stack menu.
9. This takes you to the offending code. The grey arrow is where you would reenter the method from the Error Handler. The line above the grey arrow is the offending line. In a normal situation you would fix the code, then double-click on the line above the grey arrow, and retest the line.