Search | User Listing Vidsite | Calendars | Quotes
Home Page ->  Optimizing OmniVest -> Development Discussions -> View ThreadLogon (or Register, or Join TradeTight)

You are logged in as a limited-access Guest.To join TradeTight, first read the info in the Organization & Content room, then click the link above. 

2 Cor 9:8 (NET) ... And God is able to make all grace overflow to you so that because you have enough of everything in every way at all times, you will overflow in every good work.

Why use OLang instead of dotNet SDK?
Jump to page : 1
Now viewing page 1 [50 msgs/pg]
Jump to room :
Posted 9/7/2019 7:46 AM (#9698)
Subject: Why use OLang instead of dotNet SDK?


Posts: 3922
USA: GA, Lawrenceville
I do a LOT of development work for other people ... and usually, I distribute it as a DLL. There are some obvious reasons for this:
1) the DLL hides the sourcecode so that all of my hard work and creativity isn't "borrowed"
2) it allows me (via nifty code I've developed) to provide very flexible licensing control
3) since the DLL can't be user-modified (unlike OLang), I can confidently provide support for it
4) there are some calc-efficiencies I can implement via the DLL that can't be done in OLang

This begs the question: why bother with OLang at all? Why not just write straight dotNet as a DLL and skip around these limitations? There are (at least) seven reasons:

1) it is *much* easier to test-as-you-code from OLang ... one keystroke recompiles and boom the chart changes, rather than needing to compile VB, copy with proper name to SDK folder, shut down OT and wait a long while for it to restart ... then see an issue and repeat.

2) the OLang parser *forces* the programmer not to "cheat" (accidentally or on purpose) by using information from the "future" for a calculation ... when coding a DLL directly from dotNet, it's easy to do that ... which makes DLL's questionable if not developed in the manner that I use.

3) although OLang does not have Trace or Breakpoint, etc tools, I've found that OLang's debugmsg() feature, and the MsgBox() option, provide fully-sufficient debugging tools ... much easier to use than the dotNet suite for the same stop/restart OT reasons described above.

4) the OLang Editor automatically parses out certain reserved words that are *unique* to the OT environment and colors them red ... as well as identifying (most) language words as blue and comments as green ... it also has a handy menu on the right showing (most) all the function calls and methods available - in dotNet, you need to use crib sheets.

5) aside from some ancient examples that N provides as the *only* documentation, the dotNet API coding within the SDK is *totally unsupported* by N staff (or by other users on the forum, for that matter) ... including all the API "hooks" that are out there, without any explanation or caveats.

6) generally, dotNet code requires a lot of extra superstructure than OLang code ... not always true, but annoyingly common ... that is, you can do most tasks in OLang with a *lot* fewer lines of code than would be required in dotNet.

7) it's just *easier* to work with the syntax of OLang ... yes, it's more limited than the tens of thousands of dotNet constructs and classes and methods etc ... but hey, for an old fart like me, it's a lot less to remember ... unless I'm working on some obscure non-supported feature like file manipulation, I never need to google MSDN for OLang coding.

Occasionally I get asked (or derided) for using OLang rather than dotNet ... hopefully those considerations will help any of you who are wondering about diving into direct dotNet coding, or are on the fence about it.
Top of the page Bottom of the page
Jump to page : 1
Now viewing page 1 [50 msgs/pg]
( E-mail a Link | Printer Version | Search Room )

Owner of site: Jim Dean -- Forum content is confidential, and may not be distributed without written permission.