Page 1 of 2

class level variables as an alternative to pheap

Posted: Mon Sep 11, 2006 9:17 pm
by Luke
One thing I've found difficult with NeoTicker is getting used to their variable persistence between bars. They currently use something called heap. Each heap item must be accessed from an array by an index. I suppose it isn't that difficult to use but I don't like how all the heap references look in my code. In C# we have the option to just use class level variables.

Brief comments on variable scope:
Scope determines the lifetime of a variable. Variables that are class level will persist (stay alive/not get garbage collected) as long as the class does. What defines the variable scope is where in the object hierarchy they are declared.

Code: Select all

[System.Security.SuppressUnmanagedCodeSecurity]
public class NeoTickerClass
//this is the global/main class. This object with live until the chart is closed or disabled
{
string GlobalClassString = "anything";
//class level variable. Can be used as a substitute for pheap

double IIDLIndicator.IDLCallEx(NTIndicatorObjects NTIndicatorObjects)
{
   string MethodLevelString = "anything";
   //this variable will die after every bar excecution, it will not retain it's value
   // and is not a pheap alternative

   if (Itself.FirstCall)
      {
      GlobalClassString = Params.get_Items("paramname"). Str;
      //Make sure you reset this in the first call
      //this will retain it's scope throughout the lifetime of the      ndicator/
      //between bars. It acts as a pheap as oposed to heap as it does not reset itself if changed

   }
}

There is an important issue to be aware of when using this alternative to pheap. You must remember to reset the value in the FirstCall and even remove previous items from Arrays. I had an issue when I stored an array collection. When I modified the parameters and pressed "Apply" my new items were added to the array but the previous items not removed. I now make sure to clear the array in the FirstCall section.

Posted: Wed Sep 13, 2006 8:57 am
by michal.kreslik
Luke,

I also prefer to solve programming tasks in Neo by using standard tools and concepts whenever it is possible than relying on Neo's built-in IDL tools.

Sometimes it's not only a matter of convenience, but of a strictly predictable behavior.

Michal

Posted: Wed Sep 13, 2006 12:49 pm
by Luke
michal.kreslik wrote:Luke,

I also prefer to solve programming tasks in Neo by using standard tools and concepts whenever it is possible than relying on Neo's built-in IDL tools.

Sometimes it's not only a matter of convenience, but of a strictly predictable behavior.

Michal


And the biggest advantage of this method it that it allows you to persist any variable type including custom classes and reference them easily as local variables.

Posted: Wed Sep 13, 2006 3:59 pm
by michal.kreslik
Indeed, the question raises: when it's advantageous to use heap/pheap/whateverheap in Neo over the standard way of working with data in C#?

Posted: Wed Sep 13, 2006 4:27 pm
by Luke
michal.kreslik wrote:Indeed, the question raises: when it's advantageous to use heap/pheap/whateverheap in Neo over the standard way of working with data in C#?


This method cannot replace gheap as gheap persists across all charts. It does not mimic standard heap so this method is really only a replacement for pheap. However, I find pheap to be by far the most commonly used of the 3.

Posted: Wed Sep 13, 2006 8:57 pm
by michal.kreslik
OK. I only make operations in IDL indicators that intercommunicate with one chart only, so I have not yet had any need to store values accross more window types (charts, quotes etc.), although it's probable this need will arise one day for me.

But I'm positive some minor process treament in C# would make this possible even without gheap.

Posted: Tue Oct 31, 2006 11:01 pm
by Luke
I must admit that at the time I started this thread my understanding of this subject was incomplete. There are further issues with using application level variables, namely that they will cause conflicts among multiple charts as all the variables are shared between them. I think that Michal has actually made several posts regarding this but I managed to overlook them until now. Using variable arrays with GUIDs is a possible solution. I will post on this subject again later.

Posted: Wed Nov 01, 2006 7:30 am
by michal.kreslik
Luke,

as I stated above, in my opinion heap objects in Neo are redundant as all the tasks assosiated with them can be done with the help of common C# objects. And with common C# objects, there's more control over what you're doing.

Michal

Posted: Thu Nov 09, 2006 5:05 am
by aspTrader
Luke wrote:I must admit that at the time I started this thread my understanding of this subject was incomplete. There are further issues with using application level variables, namely that they will cause conflicts among multiple charts as all the variables are shared between them. I think that Michal has actually made several posts regarding this but I managed to overlook them until now. Using variable arrays with GUIDs is a possible solution. I will post on this subject again later.

Hi guys,

I've been working on this issue as well in Delphi. Merlin has developed framework for Delphi to deal with it. I think all the concepts in that framework would work well in C# too.

The Unique Identifier of an indicator instance can be stored in several different ways...

At any rate, just letting you know that there are folks working the same issue Delphi.

Posted: Wed May 16, 2007 4:12 am
by Luke
Delphi is not allowed here. This is a C# forum ;)