Jim Dean Sage     Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA  User Profile | I hadn’t realized that it was active in a Strategy. OT is sort of “possessive” about OL routines that are assigned to an external construct such as an active strat or sometimes a FL column. I don’t know the “rules” related to that - it’s idiosyncratic. It doesn’t have to do with the parser or compiler but rather how and where and when OT “grabs a copy” of the routine. That’s all black box to me. The issue afaik is not debugmsg statements - the same kind of “persistence” can occur without them. The practice that I follow is to either rename the OL routine to assure that what I’m using is the latest version, or limit the exposure of the routine re Strats etc so that they can be rebuilt easily during development. Generally, though, I’ve found that just being deliberate about changes, and checking them as I go to make sure they “took“, yields satisfactory results. I’d say that maybe one in every 5000 compiles or so, I see the kind of problem you are talking about. I do a *lot* of compiles. (Ie ctrl-shift-B) Re using another editor - the benefits to using the native OL editor outweigh those of an external one in my opinion. I do make a regular practice of keeping versioned backup files in a separate folder, using cut and paste. I’ve found over the 15 years or so of coding in OLang that it’s very versatile and reliable, after I’d adjusted my procedures and methodology accordingly. Of course, “pure VB.net” is another option using Visual Studio and the API. But given the frustrations you’ve already expressed with the “high level” (but limited) OLang interface, and given the complete lack of any documentation for the API (other than some dated examples), and given that N doesn’t have anyone on staff to support Q’s about it, I’d recommend that you stick with OLang. That’s the path I’ve taken and I’m very satisfied with it. [Edited by Jim Dean on 4/26/2019 10:40 PM] | |
